Node.js
Monthly
Command injection in the simple-git Node.js library (versions 3.15.0 through 4.0.0) allows remote, unauthenticated attackers to execute arbitrary shell commands under the identity of the Node.js process when a host application forwards attacker-controlled values into SimpleGitOptions.config or inline -c arguments and later runs git interpret-trailers, because the default blockUnsafeOperationsPlugin does not flag trailer.<token>.cmd (or trailer.<token>.command) as unsafe configuration. This is CWE-78 (OS command injection), rated 9.2 under CVSS v4.0 by the reporter and independently assessed as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H; exploitation is contingent on the application actually passing untrusted config into simple-git, so apps using only hard-coded/trusted configuration are not exposed and no privilege escalation beyond the Node process is possible. A vendor-released patch is available in simple-git 4.0.1, which introduces the allowUnsafeCommandBinaries category; there is no public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Command injection in simple-git, the Node.js library for running git commands and published on npm, affects all releases before 4.0.0 and allows unauthenticated remote attackers to execute arbitrary commands whenever a consuming application forwards attacker-influenced values into a git push argument list. The library's default blockUnsafeOperationsPlugin matches dangerous options by literal spelling only, so unambiguous Git long-option abbreviations such as --receive-p, --receive-pa and --exe bypass detection, are expanded by Git itself, and reach --receive-pack on a local or file remote where the injected command runs. Publicly available exploit code exists (a published gist plus the detailed upstream advisory proof of concept), but there is no CISA KEV confirmation of active exploitation; EPSS is 0.36% (28th percentile) and SSVC marks the issue Exploitation: none, Automatable: no, because three consumer-specific preconditions must coincide.
Untrusted git configuration includes reachable through simple-git before 4.0.0 let an attacker execute arbitrary commands with the privileges of the Node.js process. The default blockUnsafeOperationsPlugin failed to classify include.path inside customArgs passed to git.clone(), and the initial remediation also missed includeIf.<condition>.path, so a loaded config file could set an executable option such as core.sshCommand that Git runs during the clone. Exploitation is unauthenticated (CVSS:3.1/AV:N/AC:H/PR:N/UI:N, base 8.1) but requires both attacker-influenced customArgs reaching git.clone() and an attacker-controlled file already readable by the Node.js process; no public exploit was identified at time of analysis and the issue is fixed in simple-git 4.0.0.
Privilege escalation in the Electron framework lets a <webview> guest grant itself Node.js integration inside its Web Workers even when the embedding (embedder) application has Node integration turned off, so untrusted guest content can obtain a more privileged JavaScript execution context than the host application intended to allow. Affected releases are npm/electron before 41.10.6, 42.x before 42.9.2, 43.x before 43.4.1, and 44.0.0-alpha.x before 44.0.0-beta.5 (CPE cpe:2.3:a:electron:electron). Exploitation is not automatic: the independent assessment requires a non-default deployment where the app enables the <webview> tag, runs the embedder unsandboxed with nodeIntegration disabled, and loads attacker-controllable content into the guest - applications that never enable <webview>, keep the embedder sandboxed, or only load trusted first-party content are unaffected. There is no public exploit identified at time of analysis (CISA SSVC: Exploitation none, Automatable no, Technical Impact total) and EPSS is low at 0.45% (37th percentile), although the underlying privilege boundary is a total-compromise class issue where it applies; the NVD-style vector scores 9.8, while our independent assessment reflects the higher attack complexity and changed scope (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) imposed by those preconditions.
Denial of service in Socket.IO Cluster Engine versions before 0.1.1 allows unauthenticated remote attackers to crash Node.js processes in clustered Socket.IO deployments by supplying crafted session IDs such as __proto__ or constructor. Only applications using @socket.io/cluster-engine are affected, and the flaw requires network reachability to the Socket.IO endpoint but no credentials or user interaction; the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H with base 7.5. No public exploit identified at time of analysis, and the issue is fixed in 0.1.1.
Broken access control in Nginx Proxy Manager through 2.16.0 lets a non-administrative user who has been granted 'manage' permissions over one or more hosts write arbitrary nginx directives into the advanced_config field, which the backend renders verbatim into the generated proxy host configuration. Because directives such as alias can be injected, an attacker can serve files from arbitrary paths or manipulate routing for the hosts they are assigned, changing the content (C:H) and, to a lesser degree, the integrity of what the proxy returns (I:L), though this is confined to that user's assigned hosts and no victim interaction is required. Exploitation requires an authenticated account with delegated manage rights (PR:L, AV:N), so single-admin deployments are not exposed to a lower-privileged attacker; there is no public exploit code identified and no confirmed active exploitation at time of analysis, and the issue is rated 7.1 on the CVSS 4.0 vector supplied alongside the advisory. An upstream fix exists (PR #5908) that gates advanced_config changes behind an isAdmin check, but no tagged patched release has been independently confirmed.
Missing rate limiting on the authentication API of Nginx Proxy Manager through 2.16.0 allows unauthenticated remote attackers to submit unlimited password guesses to POST /api/tokens and then unlimited TOTP guesses to POST /api/tokens/2fa, ultimately obtaining a valid session and full administrative control of the instance. No public exploit code was identified at time of analysis and the CVE is not in CISA KEV, but the weakness is directly reachable by anyone who can talk to the admin interface, which is commonly internet-exposed on self-hosted deployments. Successful compromise is probabilistic rather than certain: it depends on the target account using a weak or previously-breached password and, where 2FA is enabled, on additionally guessing a rotating six-digit code, which is why our assessed CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is more conservative than the published 9.1 CVSS 4.0 score.
An unauthenticated remote attacker can lock up an Angular server-side rendering process by submitting HTML that contains an unterminated DOCTYPE declaration with trailing whitespace (for example `<!DOCTYPE html `), which drives the bundled domino HTML parser into an infinite synchronous loop that pins a CPU core at 100% and stalls the Node.js event loop, silently dropping all concurrent and subsequent requests. Only SSR deployments that run @angular/platform-server and feed attacker-controlled markup into server-side DOM parsing - via `[innerHTML]`, interpolation into rendered HTML, `insertAdjacentHTML`, `outerHTML`, or server-side sanitization - are reachable; the vulnerable version ranges are <=19.2.25, 20.0.0 through 20.3.30, 21.0.0 through 21.2.22, and 22.0.0 through 22.1.5. The trigger payload is trivial to construct, but no public exploit code has been observed circulating and the issue is not listed in CISA KEV, so the practical risk is a function of whether the application actually routes untrusted HTML through domino on the server.
A remote, unauthenticated denial-of-service condition in the NestJS (Nest) microservices framework lets an attacker crash a service on demand by sending a single message whose 'pattern' field is a deeply nested object. Only deployments using the TCP transport (ServerTCP) or the RabbitMQ transport (ServerRMQ) are exposed, because those paths pass a client-controlled, non-string pattern into JSON.stringify to compute the handler lookup key; sufficient nesting throws 'RangeError: Maximum call stack size exceeded', and the unhandled promise rejection terminates the Node.js process under default behavior. Affected versions are prior to 11.2.4 and prior to 12.0.2; the CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects pure availability loss with no confidentiality or integrity impact, and no public exploit has been identified at time of analysis. Risk is highest where the raw TCP port or consumed RabbitMQ queue/exchange is reachable by untrusted parties, since these are typically internal service-to-service surfaces.
Deeply nested brace patterns cause unbounded recursion in the npm brace-expansion library, exhausting the native stack and terminating the Node.js process (CWE-400). All versions prior to 1.1.20, 2.1.6, 3.0.8 and 5.0.11 are affected, and the trigger is remote and unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) whenever an application passes attacker-controlled input into expand()/expand_() - directly or transitively through minimatch or glob. A payload of roughly 3,100 stacked '{' followed by 'a,b' and matching '}' (about 6KB) is sufficient, and because the stack is consumed before any output is generated, neither the max nor maxLength output bounds prevent the crash; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though its availability-only impact and deep embedding in the JavaScript toolchain make it relevant to any service that expands untrusted glob or path patterns.
Stack exhaustion in the npm library brace-expansion (all versions prior to 1.1.19, 2.1.5, 3.0.7, and 5.0.10) lets a crafted brace pattern terminate the Node.js process, a process-terminating denial of service. The flaw is reachable by remote, unauthenticated attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) whenever an application passes attacker-controlled strings into expand(), most commonly indirectly through minimatch or glob pattern matching of user-supplied glob or filter expressions. No public exploit code has been identified and the issue is not listed in CISA KEV, but the consuming application must expose a path to brace expansion for the bug to be reachable, so the practical risk depends entirely on how the library is embedded.
Improper authentication in @grpc/grpc-js causes servers to surface unauthorized TLS peer certificates as valid authentication context when requireClientCertificate is set to false, letting applications that consume that context for access control treat an untrusted client as authorized. Affected releases are those before 1.13.6 and before 1.14.5; @grpc/grpc-js-xds can reach the same condition when RBAC authentication is enabled. The vector is network-reachable with no privileges or user interaction required (AV:N/PR:N/UI:N), though high attack complexity (AC:H) reflects that a specific mTLS configuration and application reliance on getAuthContext are prerequisites; no public exploit has been identified at time of analysis, and vendor patches exist in 1.13.6 and 1.14.5.
Prototype-pollution gadget in the Axios promise-based HTTP client for Node.js and the browser lets a separate, pre-existing prototype-pollution flaw in the same JavaScript process steer how ToFormData serializes outgoing request bodies in Axios 0.28.0 through 0.33.x and 1.15.1 through 1.19.x. Inherited dots, indexes, metaTokens, maxDepth, visitor, or Blob values planted on Object.prototype silently rename or reinterpret serialized fields, or make requests fail outright via a polluted maxDepth; a polluted visitor only executes when the attacker already possesses a stronger function-injection primitive, so Axios adds no new code-execution capability on its own. Remote unauthenticated exploitation is inert without that chained second bug, and no public exploit identified at time of analysis, with no confirmed actively exploited (CISA KEV) status; vendor-released patches ship in 0.34.0 and 1.20.0.
Redirect-policy bypass in Axios 1.17.0 up to (but not including) 1.20.0 causes the fetch adapter to follow HTTP 3xx redirects even when the application explicitly sets maxRedirects: 0, so a redirect-blocking control that developers rely on as a security boundary is silently ignored. The flaw is a confused-deputy issue (CWE-441): an attacker positioned to control a redirect response from a server the application calls can push the request to internal responses or state-changing internal endpoints that should have been unreachable. Exploitation requires three simultaneous conditions - use of the fetch adapter (not the default http/xhr adapters), an explicit maxRedirects: 0 setting used as a security control, and an attacker-influenced redirect target - and per the independent assessment it is unauthenticated (CVSS PR:N) with only a single additional precondition (AT:P), yielding no direct impact on the axios host (VC/VI/VA:N) but high confidentiality and integrity impact on the subsequent internal systems reached (SC:H/SI:H). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Denial of service in the Axios HTTP client affects Node.js deployments running versions 1.15.0 through 1.19.x, where a crafted redirect Location hostname triggers quadratic regular-expression backtracking inside the proxy-bypass check and blocks the Node.js event loop. Successful exploitation requires an unusually specific combination - HTTP_PROXY/HTTPS_PROXY set, a non-empty NO_PROXY/no_proxy value, redirect following enabled, and requests reaching an attacker-influenced server that can return the malicious redirect - so exposure is narrow, and the reverse-trust nature of the attack means the adversary must control or compromise the redirect target rather than simply send a request to the victim. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) for CVE-2026-101906; the high vendor CVSS 4.0 score of 8.2 largely reflects the VA:H availability weighting rather than ease of exploitation, as reflected in our independent assessment of CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H.
Credential and response tampering in Axios's Node HTTP adapter (lib/adapters/http.js) affects versions 1.15.2 through 1.19.x when a separate, same-process prototype-pollution flaw plants a function on Object.prototype.createConnection: because the adapter supplies request options without an own createConnection property, Node resolves and invokes the inherited function as the socket factory, redirecting the transport to an attacker-controlled endpoint that receives request headers and bodies (including credentials) and returns forged responses while the requested URL still appears legitimate. This is a confused-deputy gadget rather than a self-contained flaw - it is inert without a co-resident pollution primitive that can write a function onto Object.prototype, which is why the vendor CVSS 4.0 vector carries AT:P and why our independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) treats exploitation as contingent on that chain. The issue is fixed in Axios 1.20.0; there is confirmed actively exploited (CISA KEV) status absent and no public exploit code identified at time of analysis.
Axios 1.16.1 through 1.19.x can be driven into catastrophic regular-expression backtracking through its data-URI parser, letting an unauthenticated remote attacker stall the Node.js event loop and cause a denial of service. The trigger is an attacker-controlled, malformed RFC 2397 data URL containing many slash characters on both sides of the media-type separator and no comma, which the fromDataURI / DATA_URL_PATTERN logic must exhaustively re-split before rejecting; because the parse is synchronous, the whole single-threaded process is blocked. Exploitation requires that the application actually route untrusted input into Axios's data: parsing path, so services that only make ordinary HTTP requests are not exposed; there is no confidentiality or integrity impact, authentication is not required, and no public exploit identified at time of analysis. Severity is rated 8.2 under the supplied CVSS 4.0 vector, while our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) treats it as availability-only and high-complexity given the deployment prerequisite, and the vendor-released patch is Axios 1.20.0.
Axios versions 1.13.0 through 1.19.x can crash a Node.js process because the HTTP/2 adapter installs no error handler on a ClientHttp2Session created for a request made with httpVersion: 2, so a session-level 'error' event emitted during session initialization or reuse escapes normal Promise rejection handling and becomes an uncaught exception that terminates the process, producing a denial of service. Only applications that explicitly opt into HTTP/2 are affected; the browser build and the default HTTP/1.x path are not, and the attacker must additionally be able to induce a genuine HTTP/2 session error (for example via a peer or intermediary), which is why the independent assessment rates this as high complexity rather than trivially triggerable. Impact is availability-only - no data exposure, no code execution, and no privilege requirement (unauthenticated). No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing).
Axios versions 1.13.0 through 1.19.x on Node.js can silently bypass a configured HTTP(S) proxy or a caller-supplied DNS lookup policy for requests that opt into HTTP/2, because the HTTP/2 adapter calls http2.connect() without consistently applying config.proxy, environment-derived proxy settings, or config.lookup before the connection is established. This is a defense-in-depth control bypass (CWE-918, SSRF-adjacent): confidentiality and integrity impacts fall on the systems the bypassed egress or DNS control was meant to protect, not on the local vulnerable host, and exploitation is gated by non-default configuration - the application must explicitly set httpVersion: 2 and must actually depend on the proxy or lookup policy as a security boundary. Unauthenticated remote reachability is indicated by the CVSS vectors, but practical risk is moderate given the narrow affected version band and the opt-in requirement; no public exploit identified at time of analysis.
Archive extraction in the Node.js decompress package allows a crafted archive containing chained symlink entries to resolve file writes outside the intended output directory, because the default decompress(input, output) API relies on lexical path containment checks that the kernel's symlink resolution can bypass. This affects @xhmikosr/decompress before 10.2.2 and before 11.1.4, and the separately maintained but unmaintained kevva/decompress package through 4.2.1, which remains unpatched. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N, 9.1) indicates unauthenticated remote triggering with high confidentiality and integrity impact; writing outside output can overwrite startup scripts or configuration and escalate to remote code execution, and the flaw is a bypass of the incomplete hardening previously applied for CVE-2026-53486. Exploitation requires the consuming application to extract an attacker-influenced archive on a non-Windows platform (Windows emulates symlinks via hardlinks and does not follow the affected path), and no public exploit code was identified at time of analysis, though the upstream fix ships a regression test that documents the escape technique.
Path traversal in the Rust-based pacquet package-manager component shipped inside pnpm allows a crafted lockfile to create symlinks and directories outside the project or node_modules boundary during installation. Only pnpm npm-package versions 12.0.0-alpha.0 through 12.0.0-alpha.4 that bundle pacquet are affected, and exploitation requires the victim to explicitly run an install with --trust-lockfile or a frozen lockfile against an attacker-supplied lockfile, so the trust flag that bypasses re-resolution is the enabling condition rather than a remotely reachable flaw. Impact is integrity-focused (CVSS 7.1, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L), and no public exploit code was identified at time of analysis.
Environment-variable secrets such as NPM_TOKEN or GITHUB_TOKEN can be exfiltrated from a developer's machine by pnpm 11.0.0 through 11.10.x and 10.7.0 through 10.34.4, which expand ${VAR} placeholders in the httpProxy, httpsProxy and noProxy settings read from a repository-controlled pnpm-workspace.yaml. An attacker who controls only that manifest - a public repo, a fork, or a supply-chain pull request - can cause a victim who merely clones the repository and runs a command such as pnpm install to expand secrets into an attacker-controlled proxy hostname or userinfo, routing install traffic and the associated DNS lookups through the attacker's host; exfiltration occurs during configuration loading, before any lifecycle script runs. No authentication or pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is required (CVSS PR:N), but the attack depends on user interaction because the victim must voluntarily clone the repository and invoke pnpm in a secret-bearing environment; publicly available proof-of-concept code exists, and no confirmed active exploitation (CISA KEV) has been reported.
Parse Server deployments running versions 9.0.0 through 9.10.1-alpha.9 or 8.0.2 through 8.6.90 that enable code-based social login adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo) fail to re-verify provider credentials when authentication data is submitted alongside a username and password on the login endpoint. An authenticated attacker holding a low-privileged account can therefore attach an arbitrary, unverified external provider identity to their own account - or pre-claim the provider ID of a victim who has not yet linked that provider, so the victim's later legitimate provider sign-in lands on the attacker's account. Exploitation is conditional: it requires a non-default adapter to be configured and a valid authenticated session, and the pre-hijack variant additionally requires the targeted victim to complete a legitimate provider login. No public exploit code or confirmed active exploitation was identified at time of analysis, and the assessed risk is a genuine but conditional authentication flaw rather than a mass-exploitation threat.
Denial of service in vm2 sandboxes before 3.12.2 allows an untrusted script running via VM.run to terminate the host Node.js process. The BaseHandler construct trap returns Reflect.construct's result without calling markHostPromiseHandled() the way the adjacent apply trap does, so if an embedder exposes a constructable host function whose constructor returns a resident rejected Promise, invoking it with `new` and discarding the result lets the rejection cross the sandbox bridge unhandled; under Node's default strict unhandled-rejection policy this is promoted to a process-terminating uncaught exception. The bug is unauthenticated in the sense that the attacker only needs to submit script code (PR:N/UI:N), but exploitation is conditional: it requires a specific embedder integration exposing such a constructable Promise-returning host constructor, which is the AT:P precondition and is not vm2 default behavior; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Stack exhaustion in Nodemailer before 10.0.2 allows unauthenticated remote attackers to crash an affected Node.js process by supplying a deeply nested JSON array in a recipient field (to, cc, or bcc) that the library flattens recursively until the call stack is exhausted. The flaw is only reachable through a host application that accepts externally controlled recipient input and passes it into Nodemailer message options without validating or bounding array nesting depth, so real-world impact is a recoverable denial of service with no data exposure or code execution. No KEV listing, EPSS signal, or public exploit code was identified at time of analysis, and the vendor has released a patched version (10.0.2); the issue is tracked as EUVD-2026-87675 and GHSA-8vvx-rff5-p5rq.
Denial of service in Nodemailer versions before 10.0.6 lets remote, unauthenticated attackers stall the Node.js event loop for tens of seconds by supplying crafted email address or header values that trigger quadratic backtracking in the addressparser free-text fallback regex. The flaw is only reachable when an application routes attacker-controllable strings into nodemailer's address parsing - user-supplied recipient or sender fields, contact-form addresses, or inbound headers - and the impact is availability only, with no crash, code execution, or data exposure since the affected process simply stops responding while the single-threaded event loop is blocked. No public exploit code has been identified at time of analysis, and upgrading to nodemailer 10.0.6 fully remediates the issue.
Arbitrary file read in Hugo v0.161.0 through v0.165.0 allows an attacker who can contribute content to a Hugo project - for example by opening a pull request - to commit a symlink such as assets/css/x.css pointing to /etc/passwd alongside a PostCSS plugin that reads it, causing any file readable by the build process to be disclosed and potentially published into the generated site. The flaw is remotely triggerable by unauthenticated attackers per the reported vector (PR:N), but in practice it only bites projects that actually invoke Node.js-based asset pipelines (css.PostCSS, css.TailwindCSS, js.Babel) under the default security configuration, and only when the attacker-supplied content is really built - automated CI or deploy-preview builds satisfy this with no human interaction, while review-then-merge workflows require a maintainer to build the change. Impact is confidentiality-only: there is no code execution or write primitive, and no public exploit identified at time of analysis; projects that never call the Node.js tools are unaffected.
Cross-tenant information disclosure in Budibase Server before 3.45.0 allows an authenticated low-privilege user to read another tenant's application metadata and source code by supplying a victim tenant's app ID to the GET /api/applications/:appId/appPackage endpoint, which omits an ownership check. Successful exploitation exposes navigation structure, role names, internal screen URLs, embedded JavaScript snippets, and user identifiers belonging to the victim application. No public exploit code was identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); real-world risk is concentrated in multi-tenant hosted or shared self-hosted deployments where untrusted tenants coexist, while single-tenant deployments sharply limit impact.
Budibase Server before 3.45.0 fails to redact plaintext datasource credentials before broadcasting external table updates to the Builder collaboration websocket room, allowing anyone already holding Builder-level access to a workspace to passively capture database passwords and API keys whenever a collaborator saves or deletes a table on an external datasource. The exposure is confidentiality-dominant (CVSS 4.0 base 7.0; VC:H/VI:L/VA:N) and requires the privileged Builder role (PR:H) - it is not reachable by unauthenticated users or by low-privilege consumers of published apps. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; a vendor patch is available in 3.45.0.
Authenticated privilege escalation in Budibase Server before 3.45.0 lets a low-privileged 'builder' account grant itself administrative roles in other workspaces. The flaw resides in the POST /api/global/groups/:groupId/apps endpoint, which fails to validate per-app authorization, allowing a builder who only has rights in one workspace to rewrite user-group role mappings for applications outside their own tenant boundary. Because the CVSS vector requires PR:L and no user interaction, exploitation is limited to authenticated builders, and a single-workspace or single-tenant instance offers no cross-boundary target; the raw 8.6 score therefore overstates the immediate threat even though the underlying authorization defect and its escalation impact are genuine. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, though a vendor patch is available in 3.45.0.
Broken workspace-level authorization in the Budibase server component before 3.45.0 allows an authenticated user holding builder access to a single workspace to enumerate chat identity link records belonging to every other workspace in the same tenant via a GET request to /api/chat-links. Exploitation discloses user IDs and external chat service identifiers for workspaces the builder is not permitted to access, but is read-only with no integrity or availability impact and no cross-tenant reach. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the real-world exposure is an insider or multi-workspace-tenant risk rather than an internet-wide threat.
Unauthenticated account takeover of pending invited users in Budibase Server (@budibase/server) versions 3.41.0 through 3.45.0, caused by an authentication bypass in the OIDC/SSO login path. In sso.authenticate, when no existing user matches the incoming SSO subject, the server resolves pending invites using only the IdP-asserted email address, skipping both invite-code validation and the email_verified check (which guards only the existing-account lookup), so anyone who can register at a trusted IdP and claim a victim's invited email - even with email_verified=false - consumes the invite and inherits its privileges, including builder and admin.global roles. Impact scales with the outstanding invite: an admin.global invite yields full tenant compromise (all apps, datasources with production credentials, automations) and the invite is consumed, denying onboarding to the legitimate invitee. Exploitation requires OIDC/SSO configured against a trusted IdP and an unclaimed pending invite matching the asserted email, per the vendor's AT:P attack-requirement modifier; no public exploit code or confirmed active exploitation was identified at time of analysis, and CVSS 4.0 rates this 9.2 with a CVSS 3.1 equivalent of AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
Remote code execution via arbitrary file write affects Budibase Server versions before 3.45.0. An authenticated attacker holding the BUILDER role can upload a crafted ZIP to the PWA icon upload endpoint that exploits missing symlink validation during extraction, using leaf symlink entries followed by duplicate file entries to overwrite arbitrary files as root. This allows root-level code execution; no public exploit code has been identified at time of analysis, and the vulnerability is not reported as actively exploited.
Authenticated users holding the builder role in Budibase Server deployments before 3.45.0 can read arbitrary files from the host by submitting an OpenAPI/Swagger specification containing file:// external references to the data-source import endpoint, because the import validator never disables external JSON reference ($ref) resolution. Disclosed files include .env content and other configuration material holding JWT signing secrets, API keys and database credentials, so a read-only confidentiality bug can chain into full session forgery and downstream access to connected systems. Both the NVD-style CVSS 4.0 vector and our independent CVSS 3.1 assessment (6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) require a valid builder-level account; there is no public exploit code identified at time of analysis and the CVE is not in CISA KEV, so exposure is bounded by how loosely builder accounts are provisioned - severe in shared or multi-tenant instances, lower in single-tenant deployments where builder seats are tightly held.
Stored cross-site scripting in SiYuan versions 3.7.0 through 3.8.3 (fixed in 3.8.4) allows an authenticated user with write access to a shared workspace to plant JavaScript inside a database field description that is later rendered unescaped into an aria-label attribute of gallery and kanban (Attribute View) layouts. When the victim views that board in the SiYuan Electron desktop app - where nodeIntegration is enabled by default - the injected script reaches Node.js child_process APIs and can execute arbitrary commands with the victim's privileges, escalating a rendering flaw into full local code execution. Exploitation is access-gated: it requires an authenticated writer, the victim rendering the poisoned view, and the desktop Electron build, so real-world reach is narrower than the 8.6 CVSS 4.0 headline; no public exploit code or confirmed active exploitation was identified at time of analysis.
SiYuan versions before 3.8.4 contain a cross-site scripting (XSS) flaw that allows attribute injection into gutter-button markup when a victim pastes attacker-controlled plain-text Markdown containing a Kramdown inline attribute list (IAL); on the Electron desktop build with Node integration enabled and context isolation disabled, this escalates to remote code execution with renderer Node.js privileges. Exploitation is unauthenticated (PR:N) but requires user interaction-the victim must paste the crafted Markdown and then focus the affected gutter control. No public exploit code has been identified at time of analysis, and the vendor has released a patch in v3.8.4.
Parse Server LiveQuery, the platform's real-time subscription component, can leak field values that the REST API properly withholds, affecting releases from 9.0.0 up to (but not including) 9.10.1-alpha.8 and all versions below 8.6.89. An authenticated subscriber (CVSS vectors for this issue specify PR:L, i.e. authenticated) can receive redacted-eligible field values and even use a masked field as a subscription filter, because LiveQuery evaluates the class-level protectedFields permission against an incompletely resolved caller identity: subscriber roles are never resolved, and when a subscription omits its own session token the payload is redacted against an anonymous identity even though the underlying read was authorized as the connected user. Only classes with LiveQuery enabled that define protectedFields under a role: group, the authenticated group, or a per-user group are exposed; masks defined under the public (*) group behave correctly, and only the specific masked fields are disclosed rather than arbitrary data, so this is a genuine but access-gated disclosure issue rather than an urgent one. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, and vendor-released patches (9.10.1-alpha.8 and 8.6.89) are available.
Unauthenticated remote attackers can delete every device registration in a Parse Server application - or any attacker-chosen subset - by submitting non-string (object) values in installation/device-token fields that are used to build the deduplication query without type validation. The only prerequisite is knowledge of the public application ID, which is intentionally distributed inside client apps; no account, session token, master key, or user interaction is required, and the destructive cleanup runs with elevated privileges before class-level permissions are evaluated. Parse Server versions prior to 8.6.90 and 9.0.0 through 9.10.1-alpha.9 are affected in the default configuration that exposes the REST API to clients and uses push notifications, and because deleted registrations cannot be recovered server-side, push delivery halts until every client re-registers; no public exploit identified at time of analysis, and the vendor-released patch is 8.6.90 or 9.10.1-alpha.9.
Privilege escalation in the Capgo Backend npm package (@capgo/backend) before 12.127.5 allows an authenticated attacker who already holds the org_admin role (priority rank 90) to demote org_super_admin role bindings (rank 95) down to a lower-privileged role such as org_member (rank 75) through the PATCH /private/role_bindings/:binding_id endpoint. Because the handler fails to verify the rank of the role currently bound to the target - and the prevent_last_super_admin_binding_delete safeguard fires only BEFORE DELETE, not on UPDATE - the attacker can strip every super administrator from the organization, leaving it without a super admin and enabling further governance/integrity abuse. Authentication with high privileges is required (CVSS vector PR:H), scope is limited to the attacker's own organization, and no public exploit has been identified at time of analysis; this is a bounded privileged-insider authorization defect rather than a remote unauthenticated compromise.
Improper authorization in Capgo App before 12.128.12 allows an authenticated organization member to mint a non-expiring, app-scoped API key even when the owning organization has enabled require_apikey_expiration and configured a max_apikey_expiration_days limit. The POST /apikey handler resolves the target app from the supplied app_id but omits the owning organization from the list passed to validateExpirationAgainstOrgPolicies when org_id, limited_to_orgs, and expires_at are absent, so the validation returns early and the expiration policy is silently skipped. Exploitation requires a valid org account with permission to create app-scoped keys and an organization that actually has the policy configured; the only privilege gained is indefinite key lifetime, and no public exploit code was identified at time of analysis. The vendor fixed the issue in version 12.128.12.
Capgo's Supabase backend bundle-promotion API allows an authenticated API key holder with app-level channel.promote_bundle to bypass explicit per-channel deny overrides and promote a bundle to a channel they were denied, updating public.channels.version. This affects Capgo (Cap-go/capgo.app) deployments, confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and likely earlier versions; no vendor-released patch was known at publication. The flaw only has impact when an administrator has configured a per-channel allow or deny override on the target channel_id, and no public exploit identified at time of analysis; the vendor/VulnCheck CVSS 4.0 base score is 7.2.
Capgo's direct exposure of the public.org_users table through Supabase PostgREST lets an authenticated user who already holds admin rights in an organization bypass the invitation and role-assignment workflow entirely, inserting or updating org_users rows to add any existing public.users account as an active member with user_right="admin". The vulnerable row-level security policies only enforce public.check_min_rights('admin', ...), so they skip the pending-invitation check in tmp_users, the /private/accept_invitation token flow, and the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. Per this assessment the practical impact is a moderate authorization flaw (PR:L, C:L/I:H/A:N) rather than a near-critical event; all versions are affected, no public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (it is not in CISA KEV).
Unauthenticated retrieval of deleted over-the-air update bundles from capgo.app through version 12.129.0 is possible via the public file read endpoint, which fails to check an artifact's deletion status before serving it; a cache hit additionally triggers restoration of the deleted object back into R2 storage. Any party holding a previously issued cached bundle URL can read content the operator believed was deleted, and the secondary restoration side effect re-persists that content. Exploitation requires a valid, previously recorded cached URL for a since-deleted and cached bundle - attackers cannot mint access from nothing - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis. Risk is driven by the precondition of a leaked or harvested cache URL, the vendor (VulnCheck) rating this CVSS 4.0 8.7 with high confidentiality impact, while our own assessment scores it lower (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) because the dependent-on-a-valid-cached-URL and cached-then-deleted preconditions materially limit realistic exposure.
Authenticated principals who hold an app-scoped upload/write/all API key with upload+ rights - or any user granted write+ rights on a target app - can poison Capgo's OTA update manifest so that client devices receive attacker-controlled download URLs. The bypass works because the on_version_update async worker runs with the Supabase service-role client and implicitly trusts the manifest field of an app_versions row whose storage_provider is 'r2-direct', a configuration excluded from the bundle content-lock check; the worker then writes attacker-supplied file_name, file_hash and s3_path values into public.manifest, and once a channel points at the crafted version the /updates endpoint serves the injected record as a client-facing download_url. All versions are affected, no vendor patch was available at time of publication, and no public exploit code has been identified at time of analysis.
An authenticated holder of an app-limited write API key on Capgo (capgo.app) can abuse the PUT /app/:id endpoint's user-controlled `icon` field to make a privileged service-role worker rewrite a private storage object belonging to another tenant, such as an organization logo, that the API key cannot read or write directly under Supabase Storage RLS. The flaw is a cross-tenant authorization bypass (CWE-639 / confused deputy) rather than remote code execution: the attacker cannot read the targeted object, cannot supply arbitrary replacement content beyond the referenced object being re-uploaded with cleaned metadata, and must already possess a scoped write API key for at least one app on the instance. Our independent assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N and considers the vendor's 8.7 (PR:N) rating materially overstated; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated administrators on Capgo (capgo.app) can grant channel-scoped permissions to non-member users because the platform fails to validate that principals in channel_permission_overrides belong to the organization (CWE-862). Attackers with app or org admin privileges can insert override rows with arbitrary external user UUIDs, enabling those external users to exercise permissions such as channel.promote_bundle and push over-the-air bundles to a channel. Exploitation requires an existing admin account; no public exploit code has been identified at time of analysis, and the vendor's CVSS 4.0 score of 8.7 appears generous given the high privilege prerequisite and the limited confidentiality and integrity impact assessed as moderate priority.
Privilege escalation in Capgo (capgo.app) before 12.267.1 allows a principal holding the apikey_manager role to rotate a higher-privileged same-owner sibling API key - such as an org_super_admin key - via the API key rotation PUT endpoint and retrieve the replacement plaintext secret, giving the attacker the credentials of the stronger principal. Exploitation is authenticated: the attacker must already possess or have compromised an apikey_manager key, and a more privileged sibling key under the same owner must exist, which limits exposure to organizations that delegate key-management duties to lower-trust roles. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; a vendor fix is available in 12.267.1.
Privilege escalation in the Capgo capgo.app backend (versions ≤ 12.261.0) lets an authenticated user who holds only the apikey_manager organization role mint API keys bound to higher-privileged deploy roles (app_developer, app_uploader, channel_developer, channel_uploader). Those keys can in turn be used to push arbitrary over-the-air JavaScript updates to every end user of the organization's apps, giving an insider or delegated-role holder unauthorized write access to production app content. Exploitation requires a valid JWT session and the apikey_manager role (authenticated, no user interaction), no public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; at advisory publication no patched version was available.
Missing authorization in Flowise through 3.1.4 allows any authenticated low-privilege user or holder of a valid API key to read or delete document-store upsert history records belonging to other users or workspaces by supplying a known chatflowId or record UUIDs. The chatflowId is exposed in public /chatbot/<chatflowId> share links, materially lowering the barrier, but the independent assessment limits practical impact to high confidentiality and low integrity with no availability impact and no code execution. No public exploit was identified at time of analysis, and no vendor-released patch is available.
Cross-tenant credential theft in Flowise through 3.1.4 allows an authenticated user on a multi-workspace instance to make the server decrypt and use another workspace's OpenAI or ElevenLabs API key by supplying that workspace's credential UUID to affected endpoints. The flaw is CWE-639 (Authorization Bypass Through User-Controlled Key), requires a valid account plus knowledge of the target credential UUID, and independent assessment treats it as a genuine but moderate-priority cross-tenant access-control issue rather than a headline emergency. The supplied CVSS:4.0 score is 7.6; no vendor-released patch was identified at the time of publication, and no public exploit was identified at time of analysis.
Authorization bypass in Flowise through 3.1.4 exposes the BullMQ (Bull-Board) admin dashboard to any authenticated user - including the lowest-privileged member of any tenant - when the server is started with MODE=queue and ENABLE_BULLMQ_DASHBOARD=true outside cloud mode. Because the /admin/queues mount is guarded only by verifyTokenForBullMQDashboard, which validates the JWT but performs no role, permission, or workspace/organization scoping, an attacker can read every queue and job payload instance-wide - chat inputs, overrideConfig objects that may carry credentials and prompts, chatflow.flowData graph definitions with custom function source code, chatIds, files, and the originating orgId/workspaceId - and can invoke write actions such as retry, remove, promote, and clean across tenants. Exposure is configuration-dependent (default single-process and cloud deployments are not affected) and no public exploit code has been identified at time of analysis.
Account takeover in Flowise through 3.1.4 allows unauthenticated attackers to impersonate any existing user by claiming that user's email at any configured SSO provider. This authentication bypass (CWE-287) occurs because the application resolves users solely by email without storing provider or subject identifier bindings, enabling cross-provider or local-password claim of identities. Exploitation requires SSO to be enabled and knowledge of a victim's email, but no public exploit code has been identified at time of analysis.
Authentication bypass in Flowise 3.1.4 and earlier running in Enterprise/platform mode with SSO enabled allows an attacker who can authenticate at any configured SSO provider while asserting a pending invitee's email address as the email claim to hijack that invitation, flipping the target account and its organization membership to ACTIVE without ever possessing the emailed invitation token. Our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L (vendor CVSS 4.0 base 9.2), reflecting full confidentiality and integrity impact with high attack complexity driven by the need for a matching SSO identity; the practical limiting factor is the trust and email-verification behavior of the configured SSO provider, and exploitation is constrained to the invitation's validity window (24 hours by default). No public exploit code has been identified at time of analysis, and at the time of the advisory no patched version was available.
Flowise through 3.1.4 omits route-level RBAC enforcement on its chat message endpoints, so an authenticated holder of a low-privileged API key that lacks the required flow permissions can read chat histories, prompts and model responses, and can delete chat messages, via the GET and DELETE chat message routes. The flaw is real but moderate priority: it requires a valid under-privileged API key (CVSS vector PR:L, i.e. authenticated) and mainly matters in multi-user or multi-tenant deployments that issue keys to lower-trust parties - single-operator setups where one trusted party holds all keys face negligible practical risk. Impact is confined to confidentiality and integrity of chat data (no code execution, no availability loss); no public exploit code and no confirmed active exploitation were identified at time of analysis.
Coordinated abuse reporting in the self-hosted ClawHub application/backend lets four distinct ordinary authenticated accounts push any visible skill to moderationStatus: hidden with no moderator in the loop, silently removing it from the catalog - and official/vendor-published skills are not exempt. Because the reporter quota only counts reports filed against currently-visible targets, the same four accounts can recycle the trick against additional skills, so the effect is repeatable catalog suppression rather than a one-off. Exploitation requires only ordinary authenticated users (CVSS vector PR:L, no moderator or admin role) and coordinated multi-account control; no public exploit code and no confirmed active exploitation (CISA KEV) have been identified at time of analysis. The vendor CVSS 4.0 score of 8.7 (VC:H/VI:H/VA:H) is more severe than the independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, which correctly bounds the impact to catalog visibility (no data read, no code execution); affected deployments are self-hosted ClawHub at or before revision cbfee7343ddc867316dd9b3de6fa8856730f9f41, while the npm CLI and OpenClaw runtime are separate products and are not affected.
Missing authorization enforcement in ClawHub's public skills:generateChangelogPreview action lets any signed-in caller preview the prior version of a skill they are not authorized to access, disclosing up to 8,000 characters of quarantined or otherwise restricted skill content per request. The issue is rated 7.1 (CVSS 4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N; independent CVSS 3.1 assessment 7.1 with confidentiality impact only) and requires nothing more than a valid ClawHub account - no user interaction, special network position, or non-default configuration - while impact is limited to reading content, with no integrity or availability effect. No public exploit code has been identified at time of analysis; the hosted clawhub.ai service was remediated by the 2026-09-11 deployment of revision 8c2de6c506bb, so realistic residual exposure is confined to self-hosted deployments built from revisions at or after cbfee7343ddc867316dd9b3de6fa8856730f9f41 and before that fix.
OpenClaw (npm package openclaw) before 2026.7.1 misbinds Signal approval reactions to the wrong message, so a reaction an approver places on ordinary outbound text can be interpreted as approving or denying a structured host-action request that happens to be pending in the same conversation. Exploitation requires an authenticated participant acting as approver (PR:L), deliberate user interaction via a reaction (UI:P), and precise timing where unrelated outbound messages and a pending approval coexist (AC:H, AT:P), which is why the CVSS 4.0 base score is 7.5 rather than critical. The flaw does not grant any party new authority and does not change the legitimacy of correctly identified approvers; impact is bounded by whatever host actions the OpenClaw process is authorized to perform for the specific pending request. Vendor-released patch: 2026.7.1; no public exploit identified at time of analysis and the issue is not in CISA KEV.
A time-of-check time-of-use race condition in OpenClaw's OpenShell local mirror filesystem mutation operations (remove, mkdir, rename) before 2026.7.1 allows an authenticated local attacker to escape the sandbox and delete, create, or rename host filesystem paths outside the intended mirror root with the permissions of the OpenClaw process user. Exploitation requires winning a narrow timing race between the sandbox path-safety check and the actual operation, which is a non-trivial precondition, but it does not require the operator to have granted host filesystem access outside the sandbox, so default deployments are affected. No public exploit code or active exploitation has been identified at time of analysis; the vendor has released a fix in version 2026.7.1.
OpenClaw deployments before 2026.7.1 contain an authorization-bypass flaw in the browser tool that lets a sandboxed session reach a paired host node's browser actions even when allowHostControl=false is set, so an attacker who can steer sandboxed agent input (e.g., via untrusted content or prompt injection) can inspect or manipulate the connected browser profile and its authenticated state. The issue affects remote, low-privilege, unauthenticated-at-the-network sandbox input paths (CVSS 8.7, vector PR:L/UI:N), and there is no public exploit identified at time of analysis; risk is concentrated in deployments that actually pair a host browser and feed untrusted content into the sandbox.
Authorization bypass in OpenClaw (npm package 'openclaw') before 2026.7.1 lets a low-privilege, write-scoped caller reach browser-control functionality through the node.invoke code path even though the equivalent direct browser.request path correctly enforces administrator scope. The issue only affects Gateway deployments that honor caller identity and narrower operator scopes, and it requires the attacker to already hold a valid write-scoped credential plus access to a connected browser-capable node; deployments using OpenClaw's shared-secret token or password trusted-operator model are not affected. A successful exploit allows the caller to inspect pages, navigate tabs, and interact with browser-visible applications without the configured admin requirement, with realized impact bounded by the target browser profile and its signed-in state; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authorization bypass in the npm package `openclaw` (OpenClaw) before version 2026.7.1 allows an already-authorized non-owner channel sender who holds channel command access to approve or deny Claude Code permission prompts that were meant for the owner, causing the pending action to proceed without owner consent. The severity of any given exploitation is bounded by what the specific Claude Code run requested - the attacker can only green-light capabilities the host run had already queued, so impact ranges from low-risk operations up to high-impact host actions depending on context. No public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited; the vendor-released fix is version 2026.7.1.
Channel read allowlist bypass in the OpenClaw channel plugins @openclaw/msteams, @openclaw/feishu, @openclaw/matrix, and @openclaw/googlechat before 2026.8.1 lets a low-privilege sender or a steered/prompt-injected agent pull messages, reactions, pins, member lists, and related metadata out of channels and rooms that the operator's read policy was intended to exclude. Exploitation is unauthenticated at the network layer but requires an existing low-privilege channel read capability (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and it only matters where a restrictive read allowlist is actually configured - default open policies expose nothing new. Exposure is further bounded by the permissions held by the connected bot account, and no public exploit code or confirmed active exploitation has been identified at time of analysis; the vendor fixed the issue in 2026.8.1.
OpenClaw (npm package 'openclaw') before 2026.7.1 lets an actor who can steer a tool-enabled agent create a persistent cron job that runs attacker-chosen commands with the privileges of the OpenClaw process user. A mixed-case payload 'kind' value slips past the agent-facing shell-execution guard and later normalizes into a command job, targeting the model-facing cron tool only. The vendor scores this 8.7 (High) on CVSS 4.0 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) and the vendor-released patch is 2026.7.1; no public exploit identified at time of analysis.
Authorization bypass in OpenClaw before 2026.7.1 allows a write-scoped caller in identity-bearing Gateway deployments to spoof another sender's identifier in message.action requests and invoke a channel action under that requester identity, reaching operations the channel adapter would have denied to the real caller. Exploitation requires a valid low-privilege (write-scoped) credential, an authentication mode that honors caller identity (shared-secret token and password callers are explicitly out of scope), and at least one enabled channel action that relies on requester identity; practical impact is bounded by the enabled channel, the action invoked, and the target account's permissions. No public exploit code or CISA KEV confirmation was identified at time of analysis, and the vendor-released fix is version 2026.7.1.
OpenClaw Gateway before 2026.7.1 fails to restrict owner-only infrastructure tools exposed through the chat.send endpoint, allowing an authenticated write-scoped non-owner caller to cause the agent to invoke owner-only configuration or scheduling operations, including persistent state changes. This privilege escalation (CWE-269) affects Gateway deployments using authentication modes that honor caller identity and narrower operator scopes, and where agent tool policies include the `gateway` and `cron` tools; shared-secret token and password callers are treated as fully trusted and are out of scope. No public exploit code identified at time of analysis; the vendor CVSS 4.0 score is 7.2 with integrity impact dominant.
Server-side request forgery in OpenClaw (npm package 'openclaw') before 2026.8.1 lets an attacker who can influence DNS for an already-allowlisted hostname bypass the trusted-host destination validation and reach a service bound only to loopback, disclosing that service's response. Exploitation is highly conditional and high-complexity: the fetch must go through the trusted-host DNS recheck path, the hostname must already be on the trusted-host allowlist, the attacker must be able to make it resolve to an unspecified address (0.0.0.0 or ::), and a loopback-bound service must actually exist and return useful data - impact is confidentiality-only. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor shipped a fix in 2026.8.1.
OpenClaw npm package versions 2026.3.28 through 2026.8.0 can be coerced into executing attacker-supplied Python code when an operator opens OpenClaw against an untrusted workspace whose .env file sets CLOUDSDK_PYTHON_ARGS and then runs the Gmail setup flow. The poisoned value is inherited by the gcloud launcher, which forwards it as arguments to the trusted Python interpreter, giving the attacker code execution with the OpenClaw host user's permissions - enough to read credentials, modify files, or spawn further processes. The issue is rated 8.5 (CVSS 4.0 AV:L/AC:L/AT:N/PR:N/UI:P; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and is fully local and interaction-dependent: the malicious workspace content must already be present and the operator must both launch OpenClaw on it and actively trigger Gmail setup, so it cannot be fired remotely or unattended; no public exploit code was identified at time of analysis. Version 2026.8.1 fixes the flaw.
Server-side request forgery in OpenClaw (npm package 'openclaw') versions 2026.4.5 through before 2026.8.1 lets an attacker who controls an approved remote Chrome DevTools Protocol (CDP) hostname, or its DNS answers, use DNS rebinding to steer the Gateway into connecting to SSRF-denied destinations such as loopback, private, link-local, or cloud metadata addresses. The flaw is a check-then-use (TOCTOU) gap: the Gateway validates and pins DNS at configuration time, but the raw WebSocket and Playwright transports independently re-resolve the hostname when the connection is actually made, discarding the pin. Per the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) exploitation is unauthenticated but requires a non-default, operator-configured hostname-based remote CDP endpoint plus a successful rebinding race, so impact is bounded by the internal services reachable from the Gateway host; no public exploit is identified at time of analysis and CISA KEV does not list this issue.
Command-execution approval bypass in the OpenClaw agent runtime (npm package 'openclaw') versions 2026.3.22 up to but not including 2026.8.1 lets an attacker piggyback on a previously approved command wrapper to run arbitrary commands with the OpenClaw process's host privileges, without triggering a new approval prompt; the vendor rates this 8.6 and our independent assessment places it at CVSS 3.1 8.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) because exploitation is gated by two preconditions. An authenticated operator must first have allowlisted or permanently approved a specific wrapper invocation, and that wrapper (a transparent shell carrier, or an opaque utility such as a process monitor, tracer, namespace tool, or proxy wrapper) must resolve on the host; a later agent turn can then substitute an arbitrary inner command in the wrapper's arguments and have it executed under the host privileges of the OpenClaw process. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), and the issue is fully remediated by upgrading to 2026.8.1.
Authorization bypass in OpenClaw before 2026.8.1 lets an attacker reuse an already-approved executable with different arguments, so commands execute without a new approval prompt. The root of the flaw is that 'Allow Always' approvals granted for an exact command are persisted on macOS and Linux as path-only grants, meaning any later invocation of that same binary silently inherits the earlier approval. Exploitation is conditionally gated: an operator must first have granted Allow Always for at least one command, and the attacker must then steer the agent into invoking that binary with attacker-chosen arguments (typically via prompt or content injection), which is reflected in the high attack complexity and user-interaction metrics of the assessed vector rather than a pre-auth internet-facing entry point. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Command injection in OpenClaw versions before 2026.8.1 lets an attacker who can supply command input to an agent turn slip hidden commands past the exec allowlist: escaped newlines desynchronize the allowlist parser, which validates only the visible portion of the input while the appended command executes without the expected authorization prompt. Successful exploitation yields full code execution on the host (VC:H/VI:H/VA:H, CVSS 4.0 base 8.6; independently assessed as CVSS 3.1 8.8 AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H), though it requires the operator to be actively driving the affected agent turn (UI:P) and the attacker to already hold a low-privilege position on the command-input surface (PR:L). No public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but the allowlist-bypass nature of the bug means any environment relying on the exec allowlist as its execution boundary should treat this as high priority.
Resource exhaustion in the OpenClaw Gateway listener affects every OpenClaw release before 2026.8.1 and lets unauthenticated remote attackers open WebSocket upgrade requests that retain response sockets without matching connection semantics; repeated malformed upgrade requests drain listener capacity until the service becomes unavailable (CVSS 4.0 8.7, availability-only; independent assessment rates A:H with PR:N/UI:N). Because those requests sidestep the product's WebSocket pre-auth connection budget, the built-in connection limiting does not throttle the flood, and the only prerequisites are network reachability to the Gateway listener - no credentials and no user interaction. No public exploit code has been identified at time of analysis, and impact is confined to availability, with no data disclosure or code execution reported.
Authorization bypass in OpenClaw versions before 2026.8.1 lets an authenticated, low-privileged sender who is permitted to invoke skill commands reach owner-only tools and owner-reserved server credentials, because skill tool dispatch does not propagate the sender's owner status into the tool authorization decision. Exploitation requires only the PR:L prerequisite defined by the CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N, base 8.7) - no owner credentials and no user interaction - and yields high confidentiality and integrity impact with limited availability impact, so the practical exposure is confined to multi-sender or multi-tenant OpenClaw deployments in which non-owner principals have been granted skill-command access; single-owner or no-external-sender deployments are not exposed. No public exploit identified at time of analysis, and this CVE is not reported as confirmed actively exploited (CISA KEV); a vendor security advisory (GHSA-7cp7-87pj-p32v) and a VulnCheck advisory are available, and the fixed release is 2026.8.1.
Server-side request forgery in OpenClaw Gateway (npm-distributed, versions 2026.7.1 through 2026.8.0) lets an authenticated, write-scoped caller abuse Synology Chat attachment delivery: the Gateway validates a single DNS lookup for a supplied file URL but then hands the original hostname to the Synology NAS, which resolves it independently and can be steered to a private or policy-denied resource whose contents are returned to the addressed conversation. Reaching that outcome requires remote URL attachment forwarding to be enabled, the Gateway to accept a remotely-influenced hostname, and the attacker to win a DNS rebinding race against the NAS's own resolution, so practical impact hinges on NAS routing, resolver behavior, and whether a useful response exists at the private destination; no public exploit code has been identified at time of analysis. The vendor CVSS 4.0 rating is 7.1 (HIGH), but our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, arguing for a lower real-world priority given the non-default feature-specific pathway, the PR:L authentication requirement, and the narrow affected window that is closed by upgrading to 2026.8.1.
OpenClaw before 2026.8.1 fails to enforce per-chat tool policies for Codex app-server runtime tools, allowing an authenticated participant (PR:L) in a lower-trust conversation to bypass a tools.allow allowlist and reach native shell, process, file, and patch tools. The vendor-assigned CVSS 4.0 score is 8.7, and the practical impact depends on the Codex runtime's host permissions and sandbox configuration; the issue is fixed in 2026.8.1. No public exploit identified at time of analysis.
Authorization bypass in the @openclaw/voice-call package before version 2026.8.1 lets a remote caller who is admitted by the configured inbound-call policy (open, pairing, or allowlist) drive the agent's owner-only tools, because the caller's identity and non-owner status are not propagated on classic inbound voice calls. The owner-only tool filter therefore fails open, allowing data reads, file modification, command execution, or control of connected services depending on how the agent is provisioned. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (CVSS 4.0 base 8.7), and no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments with inbound calling disabled, or whose allowlist excludes the attacker, are not affected.
OpenClaw (npm package 'openclaw') versions before 2026.8.1 leak deterministic hashes computed over the original, unredacted configuration inside responses to redacted configuration requests, so a caller who can invoke operations such as config.get can perform offline password-candidate testing instead of going through the rate-limited Gateway authentication endpoint. Exploitation is conditional: the attacker must already hold an authenticated, low-privileged session able to retrieve the redacted config, the Gateway password must have low entropy, and the remaining non-redacted configuration values must be reconstructable enough to compute candidate hashes - high-entropy passwords defeat the attack entirely and secret references are not exposed by the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis, and recovery of the password would grant the documented shared-secret operator authority, which explains the High confidentiality, integrity and availability impact rating.
Authorization bypass in OpenClaw's Matrix integration (@openclaw/matrix) allows an authenticated Matrix participant to inherit another account's authority when their user identifier collides after case/Unicode folding. Versions 2026.2.2 through 2026.8.0 lowercase the complete Matrix user ID - including the case-sensitive server-name portion and historical localparts - before deriving the OpenClaw authorization identity, so an attacker controlling a protocol-valid, fold-equivalent identifier (display-name matching is not required) can gain allowlist, owner-command, exec-approval, or plugin-approval rights configured for the privileged account. The vendor rates this CVSS 7.7 with high confidentiality, integrity, and availability impact; real-world risk is moderate and gated by the attacker needing a valid authenticated Matrix account plus a registrable colliding identifier, and no public exploit identified at time of analysis.
Incorrect authorization in OpenClaw Feishu before 2026.8.1 allows an authenticated attacker who can already invoke the agent's model tool operations to act through a default account that the operator has disabled, because the account-selection logic never checks the disabled flag before using that account's still-stored Feishu credentials. Successful exploitation lets the attacker read or modify Feishu resources under a revoked identity, yielding high confidentiality and integrity impact (CVSS 4.0 base 7.6; assessed CVSS 3.1 7.6 with AV:N/AC:H/PR:L/UI:N/C:H/I:H/A:N by our analysis). Exploitation is conditional and non-default: it requires a multi-account configuration where the default account is disabled yet its credentials remain valid, plus pre-existing low-privilege access to the OpenClaw agent, so it is not reachable by an anonymous remote attacker against a default install; no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Local file disclosure in OpenClaw (npm package 'openclaw') before 2026.8.1 allows an authenticated, already-admitted requester to read arbitrary known local host files even when that sender's identity has been explicitly denied filesystem read tools through the global or per-agent toolsBySender policy. The bypass occurs because outbound attachment handling - via a final-response media directive or a message attachment - does not re-apply the originating sender's policy, so a denied sender can still have a known local file read and returned to an admitted requester whose agent turn never included the read tool. Exploitation requires the attacker to already be admitted to the agent, to know or derive a useful host path, and to reach a delivery flow that accepts local attachments; impact is read-only disclosure of file contents with no integrity or availability effect, and no public exploit code has been identified at time of analysis.
Sensitive local file disclosure in OpenClaw before 2026.8.1 lets a low-privileged caller (PR:L per the CVSS vector, not fully anonymous) smuggle an unvalidated absolute host path past sandbox path validation by supplying structured message attachments that carry multiple 'source' fields, hiding the disallowed path behind an allowed attachment source. When the Telegram delivery channel is configured and active, the agent then reads the referenced host file and relays it out through that channel, giving the attacker high-confidentiality read access to files that policy would otherwise reject. There is no code execution, file modification, or denial of service; EPSS and KEV data are not provided, and no public exploit code has been identified at time of analysis. The vendor has released a fix, and exploitation requires both a message-submission-capable attacker and an OpenClaw deployment that uses Telegram delivery.
Privilege escalation in the OpenClaw npm package (versions >= 2026.4.5 and < 2026.8.1) allows a restricted external sender to have its session-derived text persisted into shared session memory and later replayed to an unattended background 'dreaming' agent that holds broader file and command privileges, producing actions beyond the authority of the original turn. The flaw is only reachable in deployments where session-memory capture and the dreaming agent are both enabled and the background agent is provisioned with more capability than the originating turn, and the exploit chain additionally depends on the content being selected for later processing and then actually followed by the model. No public exploit identified at time of analysis; vendor has released a fix in OpenClaw 2026.8.1, and the vendor-assigned CVSS 4.0 score is 7.7.
Authenticated non-owner senders can abuse the generic channel-tool path in the @openclaw/whatsapp plugin (npm, versions before 2026.8.1) to force a WhatsApp login for a configured Gateway account, issuing a fresh QR code that disconnects the existing session and causes loss of availability; integrity impact is limited because full account relinking still requires the attacker to physically scan the returned QR code with another phone. The flaw is a missing authorization check on an owner-only tool boundary (CWE-862) rather than a bypass of WhatsApp transport authentication, and it requires PR:L - an attacker who has already been admitted to a channel and can steer the agent. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released a fix in version 2026.8.1.
An authenticated attacker with low privileges can exploit an authorization bypass in the @openclaw/slack npm package (versions before 2026.8.1) to download file contents from Slack conversations outside their permitted scope, resulting in cross-boundary data disclosure. The flaw is an IDOR-class (CWE-639) issue where the conversation-authorization check fails open when a file lacks the share metadata normally used to prove conversation membership. No public exploit code or active exploitation has been identified, and the issue does not bypass Slack's own authentication or allow file enumeration. Vendor patch 2026.8.1 is available.
Directory-context bypass in OpenClaw before 2026.8.1 allows authenticated attackers with user interaction to reuse an 'allow-always' exec approval to execute the same command against unreviewed files or repositories, escaping the original approved working directory. Exploitation requires a pre-existing 'allow-always' approval and the ability to influence agent behavior; it is not exploitable on a default installation with no standing approvals. No public exploit identified at time of analysis.
Authorization scope widening in OpenClaw before 2026.8.1 allows an authenticated low-privilege sender to reuse a standing 'allow-always' file-transfer approval and reach file paths or nodes that the operator never reviewed, resulting in unauthorized file read and write (C:H/I:H, no availability impact) within whatever the agent's file-transfer capability can touch. Exploitation is conditional: it requires a previously granted allow-always approval, an already-admitted sender who can steer the agent (PR:L/UI:P), and successful abuse of glob metacharacter interpretation or node display-name reuse to resolve the grant to sibling paths or a different node (AC:H/AT:P), so it is not reliably automatable and there is no prior grant to widen otherwise. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited; a vendor patch is available in OpenClaw 2026.8.1.
Information disclosure in Actual Sync Server versions prior to 26.7.0 allows an authenticated user (CVSS PR:L) to bypass the plugin CORS proxy allowlist and cause the server to attach its configured ACTUAL_GITHUB_TOKEN to GitHub API requests outside the permitted repository, exposing private GitHub resources that the token can reach. The flaw is a prefix-matching error: the allowlist check accepts any GitHub API path beginning with /repos/{owner}/{repo}, so sibling repositories sharing an allowlisted repository's name prefix pass validation. Exploitation is config-gated - it requires the operator to have set ACTUAL_GITHUB_TOKEN and to have at least one allowlisted public plugin repository - and impact is bounded by whatever permissions that token holds; no public exploit code was identified at time of analysis, and the vendor has released a fix in 26.7.0.
Brute-force attacks against the POST /api/auth login endpoint in Flame through 2.4.0 let remote, unauthenticated attackers submit unlimited password guesses because the endpoint implements no rate limiting, attempt counters, delays, or lockouts. A successful guess yields full administrator access and the ability to modify application configuration. Exploitation requires network reachability to the instance and is only practical against weak or default-style admin passwords - a long, high-entropy password makes guessing impractical (reflected in AC:H/AT:P), and no public exploit code has been identified at time of analysis; instances behind a VPN, an authenticating reverse proxy, or on isolated LANs are not remotely reachable.
Transactions built through a remote StorageClient in @bsv/wallet-toolbox 1.1.47 through 2.3.3, @bsv/wallet-toolbox-client 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile 1.3.21 through 2.3.3 can be silently redirected by a malicious or compromised storage provider, which returns output locking scripts the wallet signs without confirming they match the caller's request. Because the provider can substitute a recipient script or append an attacker-controlled output funded by shrinking change, the wallet broadcasts a transaction paying the attacker while the application and user interface still display the intended recipient; the integrity impact is high with no confidentiality or availability effect, and no authentication against the victim wallet is required (CVSS 4.0 8.7, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Exploitation requires the application to use a remote StorageClient backend the attacker controls and the user to initiate a transaction through it - local-storage applications and those that independently verify outputs are unaffected; no public exploit code has been identified at time of analysis and the issue is patched in 2.4.0.
Denial of service in NodeRedis redis-parser through 3.0.0 lets a hostile or hijacked Redis endpoint crash the Node.js client process by returning a crafted RESP multi-bulk header whose declared length exceeds 2^32-1, triggering an uncaught RangeError during parsing. The flaw is reachable by unauthenticated remote attackers (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N) but its impact is strictly availability (VA:H) - no confidentiality, integrity, or scope impact - so a malicious server, a compromised legitimate Redis instance, or an on-path injector in the RESP response stream can only take down the parsing process. Rated 8.7 (HIGH) by CVSS 4.0, with no public exploit identified at time of analysis and no confirmed vendor-released patch, though the issue is publicly tracked upstream.
Command injection in the simple-git Node.js library (versions 3.15.0 through 4.0.0) allows remote, unauthenticated attackers to execute arbitrary shell commands under the identity of the Node.js process when a host application forwards attacker-controlled values into SimpleGitOptions.config or inline -c arguments and later runs git interpret-trailers, because the default blockUnsafeOperationsPlugin does not flag trailer.<token>.cmd (or trailer.<token>.command) as unsafe configuration. This is CWE-78 (OS command injection), rated 9.2 under CVSS v4.0 by the reporter and independently assessed as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H; exploitation is contingent on the application actually passing untrusted config into simple-git, so apps using only hard-coded/trusted configuration are not exposed and no privilege escalation beyond the Node process is possible. A vendor-released patch is available in simple-git 4.0.1, which introduces the allowUnsafeCommandBinaries category; there is no public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Command injection in simple-git, the Node.js library for running git commands and published on npm, affects all releases before 4.0.0 and allows unauthenticated remote attackers to execute arbitrary commands whenever a consuming application forwards attacker-influenced values into a git push argument list. The library's default blockUnsafeOperationsPlugin matches dangerous options by literal spelling only, so unambiguous Git long-option abbreviations such as --receive-p, --receive-pa and --exe bypass detection, are expanded by Git itself, and reach --receive-pack on a local or file remote where the injected command runs. Publicly available exploit code exists (a published gist plus the detailed upstream advisory proof of concept), but there is no CISA KEV confirmation of active exploitation; EPSS is 0.36% (28th percentile) and SSVC marks the issue Exploitation: none, Automatable: no, because three consumer-specific preconditions must coincide.
Untrusted git configuration includes reachable through simple-git before 4.0.0 let an attacker execute arbitrary commands with the privileges of the Node.js process. The default blockUnsafeOperationsPlugin failed to classify include.path inside customArgs passed to git.clone(), and the initial remediation also missed includeIf.<condition>.path, so a loaded config file could set an executable option such as core.sshCommand that Git runs during the clone. Exploitation is unauthenticated (CVSS:3.1/AV:N/AC:H/PR:N/UI:N, base 8.1) but requires both attacker-influenced customArgs reaching git.clone() and an attacker-controlled file already readable by the Node.js process; no public exploit was identified at time of analysis and the issue is fixed in simple-git 4.0.0.
Privilege escalation in the Electron framework lets a <webview> guest grant itself Node.js integration inside its Web Workers even when the embedding (embedder) application has Node integration turned off, so untrusted guest content can obtain a more privileged JavaScript execution context than the host application intended to allow. Affected releases are npm/electron before 41.10.6, 42.x before 42.9.2, 43.x before 43.4.1, and 44.0.0-alpha.x before 44.0.0-beta.5 (CPE cpe:2.3:a:electron:electron). Exploitation is not automatic: the independent assessment requires a non-default deployment where the app enables the <webview> tag, runs the embedder unsandboxed with nodeIntegration disabled, and loads attacker-controllable content into the guest - applications that never enable <webview>, keep the embedder sandboxed, or only load trusted first-party content are unaffected. There is no public exploit identified at time of analysis (CISA SSVC: Exploitation none, Automatable no, Technical Impact total) and EPSS is low at 0.45% (37th percentile), although the underlying privilege boundary is a total-compromise class issue where it applies; the NVD-style vector scores 9.8, while our independent assessment reflects the higher attack complexity and changed scope (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) imposed by those preconditions.
Denial of service in Socket.IO Cluster Engine versions before 0.1.1 allows unauthenticated remote attackers to crash Node.js processes in clustered Socket.IO deployments by supplying crafted session IDs such as __proto__ or constructor. Only applications using @socket.io/cluster-engine are affected, and the flaw requires network reachability to the Socket.IO endpoint but no credentials or user interaction; the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H with base 7.5. No public exploit identified at time of analysis, and the issue is fixed in 0.1.1.
Broken access control in Nginx Proxy Manager through 2.16.0 lets a non-administrative user who has been granted 'manage' permissions over one or more hosts write arbitrary nginx directives into the advanced_config field, which the backend renders verbatim into the generated proxy host configuration. Because directives such as alias can be injected, an attacker can serve files from arbitrary paths or manipulate routing for the hosts they are assigned, changing the content (C:H) and, to a lesser degree, the integrity of what the proxy returns (I:L), though this is confined to that user's assigned hosts and no victim interaction is required. Exploitation requires an authenticated account with delegated manage rights (PR:L, AV:N), so single-admin deployments are not exposed to a lower-privileged attacker; there is no public exploit code identified and no confirmed active exploitation at time of analysis, and the issue is rated 7.1 on the CVSS 4.0 vector supplied alongside the advisory. An upstream fix exists (PR #5908) that gates advanced_config changes behind an isAdmin check, but no tagged patched release has been independently confirmed.
Missing rate limiting on the authentication API of Nginx Proxy Manager through 2.16.0 allows unauthenticated remote attackers to submit unlimited password guesses to POST /api/tokens and then unlimited TOTP guesses to POST /api/tokens/2fa, ultimately obtaining a valid session and full administrative control of the instance. No public exploit code was identified at time of analysis and the CVE is not in CISA KEV, but the weakness is directly reachable by anyone who can talk to the admin interface, which is commonly internet-exposed on self-hosted deployments. Successful compromise is probabilistic rather than certain: it depends on the target account using a weak or previously-breached password and, where 2FA is enabled, on additionally guessing a rotating six-digit code, which is why our assessed CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) is more conservative than the published 9.1 CVSS 4.0 score.
An unauthenticated remote attacker can lock up an Angular server-side rendering process by submitting HTML that contains an unterminated DOCTYPE declaration with trailing whitespace (for example `<!DOCTYPE html `), which drives the bundled domino HTML parser into an infinite synchronous loop that pins a CPU core at 100% and stalls the Node.js event loop, silently dropping all concurrent and subsequent requests. Only SSR deployments that run @angular/platform-server and feed attacker-controlled markup into server-side DOM parsing - via `[innerHTML]`, interpolation into rendered HTML, `insertAdjacentHTML`, `outerHTML`, or server-side sanitization - are reachable; the vulnerable version ranges are <=19.2.25, 20.0.0 through 20.3.30, 21.0.0 through 21.2.22, and 22.0.0 through 22.1.5. The trigger payload is trivial to construct, but no public exploit code has been observed circulating and the issue is not listed in CISA KEV, so the practical risk is a function of whether the application actually routes untrusted HTML through domino on the server.
A remote, unauthenticated denial-of-service condition in the NestJS (Nest) microservices framework lets an attacker crash a service on demand by sending a single message whose 'pattern' field is a deeply nested object. Only deployments using the TCP transport (ServerTCP) or the RabbitMQ transport (ServerRMQ) are exposed, because those paths pass a client-controlled, non-string pattern into JSON.stringify to compute the handler lookup key; sufficient nesting throws 'RangeError: Maximum call stack size exceeded', and the unhandled promise rejection terminates the Node.js process under default behavior. Affected versions are prior to 11.2.4 and prior to 12.0.2; the CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects pure availability loss with no confidentiality or integrity impact, and no public exploit has been identified at time of analysis. Risk is highest where the raw TCP port or consumed RabbitMQ queue/exchange is reachable by untrusted parties, since these are typically internal service-to-service surfaces.
Deeply nested brace patterns cause unbounded recursion in the npm brace-expansion library, exhausting the native stack and terminating the Node.js process (CWE-400). All versions prior to 1.1.20, 2.1.6, 3.0.8 and 5.0.11 are affected, and the trigger is remote and unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) whenever an application passes attacker-controlled input into expand()/expand_() - directly or transitively through minimatch or glob. A payload of roughly 3,100 stacked '{' followed by 'a,b' and matching '}' (about 6KB) is sufficient, and because the stack is consumed before any output is generated, neither the max nor maxLength output bounds prevent the crash; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though its availability-only impact and deep embedding in the JavaScript toolchain make it relevant to any service that expands untrusted glob or path patterns.
Stack exhaustion in the npm library brace-expansion (all versions prior to 1.1.19, 2.1.5, 3.0.7, and 5.0.10) lets a crafted brace pattern terminate the Node.js process, a process-terminating denial of service. The flaw is reachable by remote, unauthenticated attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) whenever an application passes attacker-controlled strings into expand(), most commonly indirectly through minimatch or glob pattern matching of user-supplied glob or filter expressions. No public exploit code has been identified and the issue is not listed in CISA KEV, but the consuming application must expose a path to brace expansion for the bug to be reachable, so the practical risk depends entirely on how the library is embedded.
Improper authentication in @grpc/grpc-js causes servers to surface unauthorized TLS peer certificates as valid authentication context when requireClientCertificate is set to false, letting applications that consume that context for access control treat an untrusted client as authorized. Affected releases are those before 1.13.6 and before 1.14.5; @grpc/grpc-js-xds can reach the same condition when RBAC authentication is enabled. The vector is network-reachable with no privileges or user interaction required (AV:N/PR:N/UI:N), though high attack complexity (AC:H) reflects that a specific mTLS configuration and application reliance on getAuthContext are prerequisites; no public exploit has been identified at time of analysis, and vendor patches exist in 1.13.6 and 1.14.5.
Prototype-pollution gadget in the Axios promise-based HTTP client for Node.js and the browser lets a separate, pre-existing prototype-pollution flaw in the same JavaScript process steer how ToFormData serializes outgoing request bodies in Axios 0.28.0 through 0.33.x and 1.15.1 through 1.19.x. Inherited dots, indexes, metaTokens, maxDepth, visitor, or Blob values planted on Object.prototype silently rename or reinterpret serialized fields, or make requests fail outright via a polluted maxDepth; a polluted visitor only executes when the attacker already possesses a stronger function-injection primitive, so Axios adds no new code-execution capability on its own. Remote unauthenticated exploitation is inert without that chained second bug, and no public exploit identified at time of analysis, with no confirmed actively exploited (CISA KEV) status; vendor-released patches ship in 0.34.0 and 1.20.0.
Redirect-policy bypass in Axios 1.17.0 up to (but not including) 1.20.0 causes the fetch adapter to follow HTTP 3xx redirects even when the application explicitly sets maxRedirects: 0, so a redirect-blocking control that developers rely on as a security boundary is silently ignored. The flaw is a confused-deputy issue (CWE-441): an attacker positioned to control a redirect response from a server the application calls can push the request to internal responses or state-changing internal endpoints that should have been unreachable. Exploitation requires three simultaneous conditions - use of the fetch adapter (not the default http/xhr adapters), an explicit maxRedirects: 0 setting used as a security control, and an attacker-influenced redirect target - and per the independent assessment it is unauthenticated (CVSS PR:N) with only a single additional precondition (AT:P), yielding no direct impact on the axios host (VC/VI/VA:N) but high confidentiality and integrity impact on the subsequent internal systems reached (SC:H/SI:H). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Denial of service in the Axios HTTP client affects Node.js deployments running versions 1.15.0 through 1.19.x, where a crafted redirect Location hostname triggers quadratic regular-expression backtracking inside the proxy-bypass check and blocks the Node.js event loop. Successful exploitation requires an unusually specific combination - HTTP_PROXY/HTTPS_PROXY set, a non-empty NO_PROXY/no_proxy value, redirect following enabled, and requests reaching an attacker-influenced server that can return the malicious redirect - so exposure is narrow, and the reverse-trust nature of the attack means the adversary must control or compromise the redirect target rather than simply send a request to the victim. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) for CVE-2026-101906; the high vendor CVSS 4.0 score of 8.2 largely reflects the VA:H availability weighting rather than ease of exploitation, as reflected in our independent assessment of CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H.
Credential and response tampering in Axios's Node HTTP adapter (lib/adapters/http.js) affects versions 1.15.2 through 1.19.x when a separate, same-process prototype-pollution flaw plants a function on Object.prototype.createConnection: because the adapter supplies request options without an own createConnection property, Node resolves and invokes the inherited function as the socket factory, redirecting the transport to an attacker-controlled endpoint that receives request headers and bodies (including credentials) and returns forged responses while the requested URL still appears legitimate. This is a confused-deputy gadget rather than a self-contained flaw - it is inert without a co-resident pollution primitive that can write a function onto Object.prototype, which is why the vendor CVSS 4.0 vector carries AT:P and why our independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) treats exploitation as contingent on that chain. The issue is fixed in Axios 1.20.0; there is confirmed actively exploited (CISA KEV) status absent and no public exploit code identified at time of analysis.
Axios 1.16.1 through 1.19.x can be driven into catastrophic regular-expression backtracking through its data-URI parser, letting an unauthenticated remote attacker stall the Node.js event loop and cause a denial of service. The trigger is an attacker-controlled, malformed RFC 2397 data URL containing many slash characters on both sides of the media-type separator and no comma, which the fromDataURI / DATA_URL_PATTERN logic must exhaustively re-split before rejecting; because the parse is synchronous, the whole single-threaded process is blocked. Exploitation requires that the application actually route untrusted input into Axios's data: parsing path, so services that only make ordinary HTTP requests are not exposed; there is no confidentiality or integrity impact, authentication is not required, and no public exploit identified at time of analysis. Severity is rated 8.2 under the supplied CVSS 4.0 vector, while our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) treats it as availability-only and high-complexity given the deployment prerequisite, and the vendor-released patch is Axios 1.20.0.
Axios versions 1.13.0 through 1.19.x can crash a Node.js process because the HTTP/2 adapter installs no error handler on a ClientHttp2Session created for a request made with httpVersion: 2, so a session-level 'error' event emitted during session initialization or reuse escapes normal Promise rejection handling and becomes an uncaught exception that terminates the process, producing a denial of service. Only applications that explicitly opt into HTTP/2 are affected; the browser build and the default HTTP/1.x path are not, and the attacker must additionally be able to induce a genuine HTTP/2 session error (for example via a peer or intermediary), which is why the independent assessment rates this as high complexity rather than trivially triggerable. Impact is availability-only - no data exposure, no code execution, and no privilege requirement (unauthenticated). No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing).
Axios versions 1.13.0 through 1.19.x on Node.js can silently bypass a configured HTTP(S) proxy or a caller-supplied DNS lookup policy for requests that opt into HTTP/2, because the HTTP/2 adapter calls http2.connect() without consistently applying config.proxy, environment-derived proxy settings, or config.lookup before the connection is established. This is a defense-in-depth control bypass (CWE-918, SSRF-adjacent): confidentiality and integrity impacts fall on the systems the bypassed egress or DNS control was meant to protect, not on the local vulnerable host, and exploitation is gated by non-default configuration - the application must explicitly set httpVersion: 2 and must actually depend on the proxy or lookup policy as a security boundary. Unauthenticated remote reachability is indicated by the CVSS vectors, but practical risk is moderate given the narrow affected version band and the opt-in requirement; no public exploit identified at time of analysis.
Archive extraction in the Node.js decompress package allows a crafted archive containing chained symlink entries to resolve file writes outside the intended output directory, because the default decompress(input, output) API relies on lexical path containment checks that the kernel's symlink resolution can bypass. This affects @xhmikosr/decompress before 10.2.2 and before 11.1.4, and the separately maintained but unmaintained kevva/decompress package through 4.2.1, which remains unpatched. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N, 9.1) indicates unauthenticated remote triggering with high confidentiality and integrity impact; writing outside output can overwrite startup scripts or configuration and escalate to remote code execution, and the flaw is a bypass of the incomplete hardening previously applied for CVE-2026-53486. Exploitation requires the consuming application to extract an attacker-influenced archive on a non-Windows platform (Windows emulates symlinks via hardlinks and does not follow the affected path), and no public exploit code was identified at time of analysis, though the upstream fix ships a regression test that documents the escape technique.
Path traversal in the Rust-based pacquet package-manager component shipped inside pnpm allows a crafted lockfile to create symlinks and directories outside the project or node_modules boundary during installation. Only pnpm npm-package versions 12.0.0-alpha.0 through 12.0.0-alpha.4 that bundle pacquet are affected, and exploitation requires the victim to explicitly run an install with --trust-lockfile or a frozen lockfile against an attacker-supplied lockfile, so the trust flag that bypasses re-resolution is the enabling condition rather than a remotely reachable flaw. Impact is integrity-focused (CVSS 7.1, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L), and no public exploit code was identified at time of analysis.
Environment-variable secrets such as NPM_TOKEN or GITHUB_TOKEN can be exfiltrated from a developer's machine by pnpm 11.0.0 through 11.10.x and 10.7.0 through 10.34.4, which expand ${VAR} placeholders in the httpProxy, httpsProxy and noProxy settings read from a repository-controlled pnpm-workspace.yaml. An attacker who controls only that manifest - a public repo, a fork, or a supply-chain pull request - can cause a victim who merely clones the repository and runs a command such as pnpm install to expand secrets into an attacker-controlled proxy hostname or userinfo, routing install traffic and the associated DNS lookups through the attacker's host; exfiltration occurs during configuration loading, before any lifecycle script runs. No authentication or pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is required (CVSS PR:N), but the attack depends on user interaction because the victim must voluntarily clone the repository and invoke pnpm in a secret-bearing environment; publicly available proof-of-concept code exists, and no confirmed active exploitation (CISA KEV) has been reported.
Parse Server deployments running versions 9.0.0 through 9.10.1-alpha.9 or 8.0.2 through 8.6.90 that enable code-based social login adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo) fail to re-verify provider credentials when authentication data is submitted alongside a username and password on the login endpoint. An authenticated attacker holding a low-privileged account can therefore attach an arbitrary, unverified external provider identity to their own account - or pre-claim the provider ID of a victim who has not yet linked that provider, so the victim's later legitimate provider sign-in lands on the attacker's account. Exploitation is conditional: it requires a non-default adapter to be configured and a valid authenticated session, and the pre-hijack variant additionally requires the targeted victim to complete a legitimate provider login. No public exploit code or confirmed active exploitation was identified at time of analysis, and the assessed risk is a genuine but conditional authentication flaw rather than a mass-exploitation threat.
Denial of service in vm2 sandboxes before 3.12.2 allows an untrusted script running via VM.run to terminate the host Node.js process. The BaseHandler construct trap returns Reflect.construct's result without calling markHostPromiseHandled() the way the adjacent apply trap does, so if an embedder exposes a constructable host function whose constructor returns a resident rejected Promise, invoking it with `new` and discarding the result lets the rejection cross the sandbox bridge unhandled; under Node's default strict unhandled-rejection policy this is promoted to a process-terminating uncaught exception. The bug is unauthenticated in the sense that the attacker only needs to submit script code (PR:N/UI:N), but exploitation is conditional: it requires a specific embedder integration exposing such a constructable Promise-returning host constructor, which is the AT:P precondition and is not vm2 default behavior; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Stack exhaustion in Nodemailer before 10.0.2 allows unauthenticated remote attackers to crash an affected Node.js process by supplying a deeply nested JSON array in a recipient field (to, cc, or bcc) that the library flattens recursively until the call stack is exhausted. The flaw is only reachable through a host application that accepts externally controlled recipient input and passes it into Nodemailer message options without validating or bounding array nesting depth, so real-world impact is a recoverable denial of service with no data exposure or code execution. No KEV listing, EPSS signal, or public exploit code was identified at time of analysis, and the vendor has released a patched version (10.0.2); the issue is tracked as EUVD-2026-87675 and GHSA-8vvx-rff5-p5rq.
Denial of service in Nodemailer versions before 10.0.6 lets remote, unauthenticated attackers stall the Node.js event loop for tens of seconds by supplying crafted email address or header values that trigger quadratic backtracking in the addressparser free-text fallback regex. The flaw is only reachable when an application routes attacker-controllable strings into nodemailer's address parsing - user-supplied recipient or sender fields, contact-form addresses, or inbound headers - and the impact is availability only, with no crash, code execution, or data exposure since the affected process simply stops responding while the single-threaded event loop is blocked. No public exploit code has been identified at time of analysis, and upgrading to nodemailer 10.0.6 fully remediates the issue.
Arbitrary file read in Hugo v0.161.0 through v0.165.0 allows an attacker who can contribute content to a Hugo project - for example by opening a pull request - to commit a symlink such as assets/css/x.css pointing to /etc/passwd alongside a PostCSS plugin that reads it, causing any file readable by the build process to be disclosed and potentially published into the generated site. The flaw is remotely triggerable by unauthenticated attackers per the reported vector (PR:N), but in practice it only bites projects that actually invoke Node.js-based asset pipelines (css.PostCSS, css.TailwindCSS, js.Babel) under the default security configuration, and only when the attacker-supplied content is really built - automated CI or deploy-preview builds satisfy this with no human interaction, while review-then-merge workflows require a maintainer to build the change. Impact is confidentiality-only: there is no code execution or write primitive, and no public exploit identified at time of analysis; projects that never call the Node.js tools are unaffected.
Cross-tenant information disclosure in Budibase Server before 3.45.0 allows an authenticated low-privilege user to read another tenant's application metadata and source code by supplying a victim tenant's app ID to the GET /api/applications/:appId/appPackage endpoint, which omits an ownership check. Successful exploitation exposes navigation structure, role names, internal screen URLs, embedded JavaScript snippets, and user identifiers belonging to the victim application. No public exploit code was identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); real-world risk is concentrated in multi-tenant hosted or shared self-hosted deployments where untrusted tenants coexist, while single-tenant deployments sharply limit impact.
Budibase Server before 3.45.0 fails to redact plaintext datasource credentials before broadcasting external table updates to the Builder collaboration websocket room, allowing anyone already holding Builder-level access to a workspace to passively capture database passwords and API keys whenever a collaborator saves or deletes a table on an external datasource. The exposure is confidentiality-dominant (CVSS 4.0 base 7.0; VC:H/VI:L/VA:N) and requires the privileged Builder role (PR:H) - it is not reachable by unauthenticated users or by low-privilege consumers of published apps. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; a vendor patch is available in 3.45.0.
Authenticated privilege escalation in Budibase Server before 3.45.0 lets a low-privileged 'builder' account grant itself administrative roles in other workspaces. The flaw resides in the POST /api/global/groups/:groupId/apps endpoint, which fails to validate per-app authorization, allowing a builder who only has rights in one workspace to rewrite user-group role mappings for applications outside their own tenant boundary. Because the CVSS vector requires PR:L and no user interaction, exploitation is limited to authenticated builders, and a single-workspace or single-tenant instance offers no cross-boundary target; the raw 8.6 score therefore overstates the immediate threat even though the underlying authorization defect and its escalation impact are genuine. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, though a vendor patch is available in 3.45.0.
Broken workspace-level authorization in the Budibase server component before 3.45.0 allows an authenticated user holding builder access to a single workspace to enumerate chat identity link records belonging to every other workspace in the same tenant via a GET request to /api/chat-links. Exploitation discloses user IDs and external chat service identifiers for workspaces the builder is not permitted to access, but is read-only with no integrity or availability impact and no cross-tenant reach. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the real-world exposure is an insider or multi-workspace-tenant risk rather than an internet-wide threat.
Unauthenticated account takeover of pending invited users in Budibase Server (@budibase/server) versions 3.41.0 through 3.45.0, caused by an authentication bypass in the OIDC/SSO login path. In sso.authenticate, when no existing user matches the incoming SSO subject, the server resolves pending invites using only the IdP-asserted email address, skipping both invite-code validation and the email_verified check (which guards only the existing-account lookup), so anyone who can register at a trusted IdP and claim a victim's invited email - even with email_verified=false - consumes the invite and inherits its privileges, including builder and admin.global roles. Impact scales with the outstanding invite: an admin.global invite yields full tenant compromise (all apps, datasources with production credentials, automations) and the invite is consumed, denying onboarding to the legitimate invitee. Exploitation requires OIDC/SSO configured against a trusted IdP and an unclaimed pending invite matching the asserted email, per the vendor's AT:P attack-requirement modifier; no public exploit code or confirmed active exploitation was identified at time of analysis, and CVSS 4.0 rates this 9.2 with a CVSS 3.1 equivalent of AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
Remote code execution via arbitrary file write affects Budibase Server versions before 3.45.0. An authenticated attacker holding the BUILDER role can upload a crafted ZIP to the PWA icon upload endpoint that exploits missing symlink validation during extraction, using leaf symlink entries followed by duplicate file entries to overwrite arbitrary files as root. This allows root-level code execution; no public exploit code has been identified at time of analysis, and the vulnerability is not reported as actively exploited.
Authenticated users holding the builder role in Budibase Server deployments before 3.45.0 can read arbitrary files from the host by submitting an OpenAPI/Swagger specification containing file:// external references to the data-source import endpoint, because the import validator never disables external JSON reference ($ref) resolution. Disclosed files include .env content and other configuration material holding JWT signing secrets, API keys and database credentials, so a read-only confidentiality bug can chain into full session forgery and downstream access to connected systems. Both the NVD-style CVSS 4.0 vector and our independent CVSS 3.1 assessment (6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) require a valid builder-level account; there is no public exploit code identified at time of analysis and the CVE is not in CISA KEV, so exposure is bounded by how loosely builder accounts are provisioned - severe in shared or multi-tenant instances, lower in single-tenant deployments where builder seats are tightly held.
Stored cross-site scripting in SiYuan versions 3.7.0 through 3.8.3 (fixed in 3.8.4) allows an authenticated user with write access to a shared workspace to plant JavaScript inside a database field description that is later rendered unescaped into an aria-label attribute of gallery and kanban (Attribute View) layouts. When the victim views that board in the SiYuan Electron desktop app - where nodeIntegration is enabled by default - the injected script reaches Node.js child_process APIs and can execute arbitrary commands with the victim's privileges, escalating a rendering flaw into full local code execution. Exploitation is access-gated: it requires an authenticated writer, the victim rendering the poisoned view, and the desktop Electron build, so real-world reach is narrower than the 8.6 CVSS 4.0 headline; no public exploit code or confirmed active exploitation was identified at time of analysis.
SiYuan versions before 3.8.4 contain a cross-site scripting (XSS) flaw that allows attribute injection into gutter-button markup when a victim pastes attacker-controlled plain-text Markdown containing a Kramdown inline attribute list (IAL); on the Electron desktop build with Node integration enabled and context isolation disabled, this escalates to remote code execution with renderer Node.js privileges. Exploitation is unauthenticated (PR:N) but requires user interaction-the victim must paste the crafted Markdown and then focus the affected gutter control. No public exploit code has been identified at time of analysis, and the vendor has released a patch in v3.8.4.
Parse Server LiveQuery, the platform's real-time subscription component, can leak field values that the REST API properly withholds, affecting releases from 9.0.0 up to (but not including) 9.10.1-alpha.8 and all versions below 8.6.89. An authenticated subscriber (CVSS vectors for this issue specify PR:L, i.e. authenticated) can receive redacted-eligible field values and even use a masked field as a subscription filter, because LiveQuery evaluates the class-level protectedFields permission against an incompletely resolved caller identity: subscriber roles are never resolved, and when a subscription omits its own session token the payload is redacted against an anonymous identity even though the underlying read was authorized as the connected user. Only classes with LiveQuery enabled that define protectedFields under a role: group, the authenticated group, or a per-user group are exposed; masks defined under the public (*) group behave correctly, and only the specific masked fields are disclosed rather than arbitrary data, so this is a genuine but access-gated disclosure issue rather than an urgent one. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, and vendor-released patches (9.10.1-alpha.8 and 8.6.89) are available.
Unauthenticated remote attackers can delete every device registration in a Parse Server application - or any attacker-chosen subset - by submitting non-string (object) values in installation/device-token fields that are used to build the deduplication query without type validation. The only prerequisite is knowledge of the public application ID, which is intentionally distributed inside client apps; no account, session token, master key, or user interaction is required, and the destructive cleanup runs with elevated privileges before class-level permissions are evaluated. Parse Server versions prior to 8.6.90 and 9.0.0 through 9.10.1-alpha.9 are affected in the default configuration that exposes the REST API to clients and uses push notifications, and because deleted registrations cannot be recovered server-side, push delivery halts until every client re-registers; no public exploit identified at time of analysis, and the vendor-released patch is 8.6.90 or 9.10.1-alpha.9.
Privilege escalation in the Capgo Backend npm package (@capgo/backend) before 12.127.5 allows an authenticated attacker who already holds the org_admin role (priority rank 90) to demote org_super_admin role bindings (rank 95) down to a lower-privileged role such as org_member (rank 75) through the PATCH /private/role_bindings/:binding_id endpoint. Because the handler fails to verify the rank of the role currently bound to the target - and the prevent_last_super_admin_binding_delete safeguard fires only BEFORE DELETE, not on UPDATE - the attacker can strip every super administrator from the organization, leaving it without a super admin and enabling further governance/integrity abuse. Authentication with high privileges is required (CVSS vector PR:H), scope is limited to the attacker's own organization, and no public exploit has been identified at time of analysis; this is a bounded privileged-insider authorization defect rather than a remote unauthenticated compromise.
Improper authorization in Capgo App before 12.128.12 allows an authenticated organization member to mint a non-expiring, app-scoped API key even when the owning organization has enabled require_apikey_expiration and configured a max_apikey_expiration_days limit. The POST /apikey handler resolves the target app from the supplied app_id but omits the owning organization from the list passed to validateExpirationAgainstOrgPolicies when org_id, limited_to_orgs, and expires_at are absent, so the validation returns early and the expiration policy is silently skipped. Exploitation requires a valid org account with permission to create app-scoped keys and an organization that actually has the policy configured; the only privilege gained is indefinite key lifetime, and no public exploit code was identified at time of analysis. The vendor fixed the issue in version 12.128.12.
Capgo's Supabase backend bundle-promotion API allows an authenticated API key holder with app-level channel.promote_bundle to bypass explicit per-channel deny overrides and promote a bundle to a channel they were denied, updating public.channels.version. This affects Capgo (Cap-go/capgo.app) deployments, confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and likely earlier versions; no vendor-released patch was known at publication. The flaw only has impact when an administrator has configured a per-channel allow or deny override on the target channel_id, and no public exploit identified at time of analysis; the vendor/VulnCheck CVSS 4.0 base score is 7.2.
Capgo's direct exposure of the public.org_users table through Supabase PostgREST lets an authenticated user who already holds admin rights in an organization bypass the invitation and role-assignment workflow entirely, inserting or updating org_users rows to add any existing public.users account as an active member with user_right="admin". The vulnerable row-level security policies only enforce public.check_min_rights('admin', ...), so they skip the pending-invitation check in tmp_users, the /private/accept_invitation token flow, and the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. Per this assessment the practical impact is a moderate authorization flaw (PR:L, C:L/I:H/A:N) rather than a near-critical event; all versions are affected, no public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (it is not in CISA KEV).
Unauthenticated retrieval of deleted over-the-air update bundles from capgo.app through version 12.129.0 is possible via the public file read endpoint, which fails to check an artifact's deletion status before serving it; a cache hit additionally triggers restoration of the deleted object back into R2 storage. Any party holding a previously issued cached bundle URL can read content the operator believed was deleted, and the secondary restoration side effect re-persists that content. Exploitation requires a valid, previously recorded cached URL for a since-deleted and cached bundle - attackers cannot mint access from nothing - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis. Risk is driven by the precondition of a leaked or harvested cache URL, the vendor (VulnCheck) rating this CVSS 4.0 8.7 with high confidentiality impact, while our own assessment scores it lower (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) because the dependent-on-a-valid-cached-URL and cached-then-deleted preconditions materially limit realistic exposure.
Authenticated principals who hold an app-scoped upload/write/all API key with upload+ rights - or any user granted write+ rights on a target app - can poison Capgo's OTA update manifest so that client devices receive attacker-controlled download URLs. The bypass works because the on_version_update async worker runs with the Supabase service-role client and implicitly trusts the manifest field of an app_versions row whose storage_provider is 'r2-direct', a configuration excluded from the bundle content-lock check; the worker then writes attacker-supplied file_name, file_hash and s3_path values into public.manifest, and once a channel points at the crafted version the /updates endpoint serves the injected record as a client-facing download_url. All versions are affected, no vendor patch was available at time of publication, and no public exploit code has been identified at time of analysis.
An authenticated holder of an app-limited write API key on Capgo (capgo.app) can abuse the PUT /app/:id endpoint's user-controlled `icon` field to make a privileged service-role worker rewrite a private storage object belonging to another tenant, such as an organization logo, that the API key cannot read or write directly under Supabase Storage RLS. The flaw is a cross-tenant authorization bypass (CWE-639 / confused deputy) rather than remote code execution: the attacker cannot read the targeted object, cannot supply arbitrary replacement content beyond the referenced object being re-uploaded with cleaned metadata, and must already possess a scoped write API key for at least one app on the instance. Our independent assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N and considers the vendor's 8.7 (PR:N) rating materially overstated; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated administrators on Capgo (capgo.app) can grant channel-scoped permissions to non-member users because the platform fails to validate that principals in channel_permission_overrides belong to the organization (CWE-862). Attackers with app or org admin privileges can insert override rows with arbitrary external user UUIDs, enabling those external users to exercise permissions such as channel.promote_bundle and push over-the-air bundles to a channel. Exploitation requires an existing admin account; no public exploit code has been identified at time of analysis, and the vendor's CVSS 4.0 score of 8.7 appears generous given the high privilege prerequisite and the limited confidentiality and integrity impact assessed as moderate priority.
Privilege escalation in Capgo (capgo.app) before 12.267.1 allows a principal holding the apikey_manager role to rotate a higher-privileged same-owner sibling API key - such as an org_super_admin key - via the API key rotation PUT endpoint and retrieve the replacement plaintext secret, giving the attacker the credentials of the stronger principal. Exploitation is authenticated: the attacker must already possess or have compromised an apikey_manager key, and a more privileged sibling key under the same owner must exist, which limits exposure to organizations that delegate key-management duties to lower-trust roles. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; a vendor fix is available in 12.267.1.
Privilege escalation in the Capgo capgo.app backend (versions ≤ 12.261.0) lets an authenticated user who holds only the apikey_manager organization role mint API keys bound to higher-privileged deploy roles (app_developer, app_uploader, channel_developer, channel_uploader). Those keys can in turn be used to push arbitrary over-the-air JavaScript updates to every end user of the organization's apps, giving an insider or delegated-role holder unauthorized write access to production app content. Exploitation requires a valid JWT session and the apikey_manager role (authenticated, no user interaction), no public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; at advisory publication no patched version was available.
Missing authorization in Flowise through 3.1.4 allows any authenticated low-privilege user or holder of a valid API key to read or delete document-store upsert history records belonging to other users or workspaces by supplying a known chatflowId or record UUIDs. The chatflowId is exposed in public /chatbot/<chatflowId> share links, materially lowering the barrier, but the independent assessment limits practical impact to high confidentiality and low integrity with no availability impact and no code execution. No public exploit was identified at time of analysis, and no vendor-released patch is available.
Cross-tenant credential theft in Flowise through 3.1.4 allows an authenticated user on a multi-workspace instance to make the server decrypt and use another workspace's OpenAI or ElevenLabs API key by supplying that workspace's credential UUID to affected endpoints. The flaw is CWE-639 (Authorization Bypass Through User-Controlled Key), requires a valid account plus knowledge of the target credential UUID, and independent assessment treats it as a genuine but moderate-priority cross-tenant access-control issue rather than a headline emergency. The supplied CVSS:4.0 score is 7.6; no vendor-released patch was identified at the time of publication, and no public exploit was identified at time of analysis.
Authorization bypass in Flowise through 3.1.4 exposes the BullMQ (Bull-Board) admin dashboard to any authenticated user - including the lowest-privileged member of any tenant - when the server is started with MODE=queue and ENABLE_BULLMQ_DASHBOARD=true outside cloud mode. Because the /admin/queues mount is guarded only by verifyTokenForBullMQDashboard, which validates the JWT but performs no role, permission, or workspace/organization scoping, an attacker can read every queue and job payload instance-wide - chat inputs, overrideConfig objects that may carry credentials and prompts, chatflow.flowData graph definitions with custom function source code, chatIds, files, and the originating orgId/workspaceId - and can invoke write actions such as retry, remove, promote, and clean across tenants. Exposure is configuration-dependent (default single-process and cloud deployments are not affected) and no public exploit code has been identified at time of analysis.
Account takeover in Flowise through 3.1.4 allows unauthenticated attackers to impersonate any existing user by claiming that user's email at any configured SSO provider. This authentication bypass (CWE-287) occurs because the application resolves users solely by email without storing provider or subject identifier bindings, enabling cross-provider or local-password claim of identities. Exploitation requires SSO to be enabled and knowledge of a victim's email, but no public exploit code has been identified at time of analysis.
Authentication bypass in Flowise 3.1.4 and earlier running in Enterprise/platform mode with SSO enabled allows an attacker who can authenticate at any configured SSO provider while asserting a pending invitee's email address as the email claim to hijack that invitation, flipping the target account and its organization membership to ACTIVE without ever possessing the emailed invitation token. Our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L (vendor CVSS 4.0 base 9.2), reflecting full confidentiality and integrity impact with high attack complexity driven by the need for a matching SSO identity; the practical limiting factor is the trust and email-verification behavior of the configured SSO provider, and exploitation is constrained to the invitation's validity window (24 hours by default). No public exploit code has been identified at time of analysis, and at the time of the advisory no patched version was available.
Flowise through 3.1.4 omits route-level RBAC enforcement on its chat message endpoints, so an authenticated holder of a low-privileged API key that lacks the required flow permissions can read chat histories, prompts and model responses, and can delete chat messages, via the GET and DELETE chat message routes. The flaw is real but moderate priority: it requires a valid under-privileged API key (CVSS vector PR:L, i.e. authenticated) and mainly matters in multi-user or multi-tenant deployments that issue keys to lower-trust parties - single-operator setups where one trusted party holds all keys face negligible practical risk. Impact is confined to confidentiality and integrity of chat data (no code execution, no availability loss); no public exploit code and no confirmed active exploitation were identified at time of analysis.
Coordinated abuse reporting in the self-hosted ClawHub application/backend lets four distinct ordinary authenticated accounts push any visible skill to moderationStatus: hidden with no moderator in the loop, silently removing it from the catalog - and official/vendor-published skills are not exempt. Because the reporter quota only counts reports filed against currently-visible targets, the same four accounts can recycle the trick against additional skills, so the effect is repeatable catalog suppression rather than a one-off. Exploitation requires only ordinary authenticated users (CVSS vector PR:L, no moderator or admin role) and coordinated multi-account control; no public exploit code and no confirmed active exploitation (CISA KEV) have been identified at time of analysis. The vendor CVSS 4.0 score of 8.7 (VC:H/VI:H/VA:H) is more severe than the independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, which correctly bounds the impact to catalog visibility (no data read, no code execution); affected deployments are self-hosted ClawHub at or before revision cbfee7343ddc867316dd9b3de6fa8856730f9f41, while the npm CLI and OpenClaw runtime are separate products and are not affected.
Missing authorization enforcement in ClawHub's public skills:generateChangelogPreview action lets any signed-in caller preview the prior version of a skill they are not authorized to access, disclosing up to 8,000 characters of quarantined or otherwise restricted skill content per request. The issue is rated 7.1 (CVSS 4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N; independent CVSS 3.1 assessment 7.1 with confidentiality impact only) and requires nothing more than a valid ClawHub account - no user interaction, special network position, or non-default configuration - while impact is limited to reading content, with no integrity or availability effect. No public exploit code has been identified at time of analysis; the hosted clawhub.ai service was remediated by the 2026-09-11 deployment of revision 8c2de6c506bb, so realistic residual exposure is confined to self-hosted deployments built from revisions at or after cbfee7343ddc867316dd9b3de6fa8856730f9f41 and before that fix.
OpenClaw (npm package openclaw) before 2026.7.1 misbinds Signal approval reactions to the wrong message, so a reaction an approver places on ordinary outbound text can be interpreted as approving or denying a structured host-action request that happens to be pending in the same conversation. Exploitation requires an authenticated participant acting as approver (PR:L), deliberate user interaction via a reaction (UI:P), and precise timing where unrelated outbound messages and a pending approval coexist (AC:H, AT:P), which is why the CVSS 4.0 base score is 7.5 rather than critical. The flaw does not grant any party new authority and does not change the legitimacy of correctly identified approvers; impact is bounded by whatever host actions the OpenClaw process is authorized to perform for the specific pending request. Vendor-released patch: 2026.7.1; no public exploit identified at time of analysis and the issue is not in CISA KEV.
A time-of-check time-of-use race condition in OpenClaw's OpenShell local mirror filesystem mutation operations (remove, mkdir, rename) before 2026.7.1 allows an authenticated local attacker to escape the sandbox and delete, create, or rename host filesystem paths outside the intended mirror root with the permissions of the OpenClaw process user. Exploitation requires winning a narrow timing race between the sandbox path-safety check and the actual operation, which is a non-trivial precondition, but it does not require the operator to have granted host filesystem access outside the sandbox, so default deployments are affected. No public exploit code or active exploitation has been identified at time of analysis; the vendor has released a fix in version 2026.7.1.
OpenClaw deployments before 2026.7.1 contain an authorization-bypass flaw in the browser tool that lets a sandboxed session reach a paired host node's browser actions even when allowHostControl=false is set, so an attacker who can steer sandboxed agent input (e.g., via untrusted content or prompt injection) can inspect or manipulate the connected browser profile and its authenticated state. The issue affects remote, low-privilege, unauthenticated-at-the-network sandbox input paths (CVSS 8.7, vector PR:L/UI:N), and there is no public exploit identified at time of analysis; risk is concentrated in deployments that actually pair a host browser and feed untrusted content into the sandbox.
Authorization bypass in OpenClaw (npm package 'openclaw') before 2026.7.1 lets a low-privilege, write-scoped caller reach browser-control functionality through the node.invoke code path even though the equivalent direct browser.request path correctly enforces administrator scope. The issue only affects Gateway deployments that honor caller identity and narrower operator scopes, and it requires the attacker to already hold a valid write-scoped credential plus access to a connected browser-capable node; deployments using OpenClaw's shared-secret token or password trusted-operator model are not affected. A successful exploit allows the caller to inspect pages, navigate tabs, and interact with browser-visible applications without the configured admin requirement, with realized impact bounded by the target browser profile and its signed-in state; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authorization bypass in the npm package `openclaw` (OpenClaw) before version 2026.7.1 allows an already-authorized non-owner channel sender who holds channel command access to approve or deny Claude Code permission prompts that were meant for the owner, causing the pending action to proceed without owner consent. The severity of any given exploitation is bounded by what the specific Claude Code run requested - the attacker can only green-light capabilities the host run had already queued, so impact ranges from low-risk operations up to high-impact host actions depending on context. No public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited; the vendor-released fix is version 2026.7.1.
Channel read allowlist bypass in the OpenClaw channel plugins @openclaw/msteams, @openclaw/feishu, @openclaw/matrix, and @openclaw/googlechat before 2026.8.1 lets a low-privilege sender or a steered/prompt-injected agent pull messages, reactions, pins, member lists, and related metadata out of channels and rooms that the operator's read policy was intended to exclude. Exploitation is unauthenticated at the network layer but requires an existing low-privilege channel read capability (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and it only matters where a restrictive read allowlist is actually configured - default open policies expose nothing new. Exposure is further bounded by the permissions held by the connected bot account, and no public exploit code or confirmed active exploitation has been identified at time of analysis; the vendor fixed the issue in 2026.8.1.
OpenClaw (npm package 'openclaw') before 2026.7.1 lets an actor who can steer a tool-enabled agent create a persistent cron job that runs attacker-chosen commands with the privileges of the OpenClaw process user. A mixed-case payload 'kind' value slips past the agent-facing shell-execution guard and later normalizes into a command job, targeting the model-facing cron tool only. The vendor scores this 8.7 (High) on CVSS 4.0 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) and the vendor-released patch is 2026.7.1; no public exploit identified at time of analysis.
Authorization bypass in OpenClaw before 2026.7.1 allows a write-scoped caller in identity-bearing Gateway deployments to spoof another sender's identifier in message.action requests and invoke a channel action under that requester identity, reaching operations the channel adapter would have denied to the real caller. Exploitation requires a valid low-privilege (write-scoped) credential, an authentication mode that honors caller identity (shared-secret token and password callers are explicitly out of scope), and at least one enabled channel action that relies on requester identity; practical impact is bounded by the enabled channel, the action invoked, and the target account's permissions. No public exploit code or CISA KEV confirmation was identified at time of analysis, and the vendor-released fix is version 2026.7.1.
OpenClaw Gateway before 2026.7.1 fails to restrict owner-only infrastructure tools exposed through the chat.send endpoint, allowing an authenticated write-scoped non-owner caller to cause the agent to invoke owner-only configuration or scheduling operations, including persistent state changes. This privilege escalation (CWE-269) affects Gateway deployments using authentication modes that honor caller identity and narrower operator scopes, and where agent tool policies include the `gateway` and `cron` tools; shared-secret token and password callers are treated as fully trusted and are out of scope. No public exploit code identified at time of analysis; the vendor CVSS 4.0 score is 7.2 with integrity impact dominant.
Server-side request forgery in OpenClaw (npm package 'openclaw') before 2026.8.1 lets an attacker who can influence DNS for an already-allowlisted hostname bypass the trusted-host destination validation and reach a service bound only to loopback, disclosing that service's response. Exploitation is highly conditional and high-complexity: the fetch must go through the trusted-host DNS recheck path, the hostname must already be on the trusted-host allowlist, the attacker must be able to make it resolve to an unspecified address (0.0.0.0 or ::), and a loopback-bound service must actually exist and return useful data - impact is confidentiality-only. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor shipped a fix in 2026.8.1.
OpenClaw npm package versions 2026.3.28 through 2026.8.0 can be coerced into executing attacker-supplied Python code when an operator opens OpenClaw against an untrusted workspace whose .env file sets CLOUDSDK_PYTHON_ARGS and then runs the Gmail setup flow. The poisoned value is inherited by the gcloud launcher, which forwards it as arguments to the trusted Python interpreter, giving the attacker code execution with the OpenClaw host user's permissions - enough to read credentials, modify files, or spawn further processes. The issue is rated 8.5 (CVSS 4.0 AV:L/AC:L/AT:N/PR:N/UI:P; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and is fully local and interaction-dependent: the malicious workspace content must already be present and the operator must both launch OpenClaw on it and actively trigger Gmail setup, so it cannot be fired remotely or unattended; no public exploit code was identified at time of analysis. Version 2026.8.1 fixes the flaw.
Server-side request forgery in OpenClaw (npm package 'openclaw') versions 2026.4.5 through before 2026.8.1 lets an attacker who controls an approved remote Chrome DevTools Protocol (CDP) hostname, or its DNS answers, use DNS rebinding to steer the Gateway into connecting to SSRF-denied destinations such as loopback, private, link-local, or cloud metadata addresses. The flaw is a check-then-use (TOCTOU) gap: the Gateway validates and pins DNS at configuration time, but the raw WebSocket and Playwright transports independently re-resolve the hostname when the connection is actually made, discarding the pin. Per the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) exploitation is unauthenticated but requires a non-default, operator-configured hostname-based remote CDP endpoint plus a successful rebinding race, so impact is bounded by the internal services reachable from the Gateway host; no public exploit is identified at time of analysis and CISA KEV does not list this issue.
Command-execution approval bypass in the OpenClaw agent runtime (npm package 'openclaw') versions 2026.3.22 up to but not including 2026.8.1 lets an attacker piggyback on a previously approved command wrapper to run arbitrary commands with the OpenClaw process's host privileges, without triggering a new approval prompt; the vendor rates this 8.6 and our independent assessment places it at CVSS 3.1 8.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) because exploitation is gated by two preconditions. An authenticated operator must first have allowlisted or permanently approved a specific wrapper invocation, and that wrapper (a transparent shell carrier, or an opaque utility such as a process monitor, tracer, namespace tool, or proxy wrapper) must resolve on the host; a later agent turn can then substitute an arbitrary inner command in the wrapper's arguments and have it executed under the host privileges of the OpenClaw process. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), and the issue is fully remediated by upgrading to 2026.8.1.
Authorization bypass in OpenClaw before 2026.8.1 lets an attacker reuse an already-approved executable with different arguments, so commands execute without a new approval prompt. The root of the flaw is that 'Allow Always' approvals granted for an exact command are persisted on macOS and Linux as path-only grants, meaning any later invocation of that same binary silently inherits the earlier approval. Exploitation is conditionally gated: an operator must first have granted Allow Always for at least one command, and the attacker must then steer the agent into invoking that binary with attacker-chosen arguments (typically via prompt or content injection), which is reflected in the high attack complexity and user-interaction metrics of the assessed vector rather than a pre-auth internet-facing entry point. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Command injection in OpenClaw versions before 2026.8.1 lets an attacker who can supply command input to an agent turn slip hidden commands past the exec allowlist: escaped newlines desynchronize the allowlist parser, which validates only the visible portion of the input while the appended command executes without the expected authorization prompt. Successful exploitation yields full code execution on the host (VC:H/VI:H/VA:H, CVSS 4.0 base 8.6; independently assessed as CVSS 3.1 8.8 AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H), though it requires the operator to be actively driving the affected agent turn (UI:P) and the attacker to already hold a low-privilege position on the command-input surface (PR:L). No public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but the allowlist-bypass nature of the bug means any environment relying on the exec allowlist as its execution boundary should treat this as high priority.
Resource exhaustion in the OpenClaw Gateway listener affects every OpenClaw release before 2026.8.1 and lets unauthenticated remote attackers open WebSocket upgrade requests that retain response sockets without matching connection semantics; repeated malformed upgrade requests drain listener capacity until the service becomes unavailable (CVSS 4.0 8.7, availability-only; independent assessment rates A:H with PR:N/UI:N). Because those requests sidestep the product's WebSocket pre-auth connection budget, the built-in connection limiting does not throttle the flood, and the only prerequisites are network reachability to the Gateway listener - no credentials and no user interaction. No public exploit code has been identified at time of analysis, and impact is confined to availability, with no data disclosure or code execution reported.
Authorization bypass in OpenClaw versions before 2026.8.1 lets an authenticated, low-privileged sender who is permitted to invoke skill commands reach owner-only tools and owner-reserved server credentials, because skill tool dispatch does not propagate the sender's owner status into the tool authorization decision. Exploitation requires only the PR:L prerequisite defined by the CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N, base 8.7) - no owner credentials and no user interaction - and yields high confidentiality and integrity impact with limited availability impact, so the practical exposure is confined to multi-sender or multi-tenant OpenClaw deployments in which non-owner principals have been granted skill-command access; single-owner or no-external-sender deployments are not exposed. No public exploit identified at time of analysis, and this CVE is not reported as confirmed actively exploited (CISA KEV); a vendor security advisory (GHSA-7cp7-87pj-p32v) and a VulnCheck advisory are available, and the fixed release is 2026.8.1.
Server-side request forgery in OpenClaw Gateway (npm-distributed, versions 2026.7.1 through 2026.8.0) lets an authenticated, write-scoped caller abuse Synology Chat attachment delivery: the Gateway validates a single DNS lookup for a supplied file URL but then hands the original hostname to the Synology NAS, which resolves it independently and can be steered to a private or policy-denied resource whose contents are returned to the addressed conversation. Reaching that outcome requires remote URL attachment forwarding to be enabled, the Gateway to accept a remotely-influenced hostname, and the attacker to win a DNS rebinding race against the NAS's own resolution, so practical impact hinges on NAS routing, resolver behavior, and whether a useful response exists at the private destination; no public exploit code has been identified at time of analysis. The vendor CVSS 4.0 rating is 7.1 (HIGH), but our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, arguing for a lower real-world priority given the non-default feature-specific pathway, the PR:L authentication requirement, and the narrow affected window that is closed by upgrading to 2026.8.1.
OpenClaw before 2026.8.1 fails to enforce per-chat tool policies for Codex app-server runtime tools, allowing an authenticated participant (PR:L) in a lower-trust conversation to bypass a tools.allow allowlist and reach native shell, process, file, and patch tools. The vendor-assigned CVSS 4.0 score is 8.7, and the practical impact depends on the Codex runtime's host permissions and sandbox configuration; the issue is fixed in 2026.8.1. No public exploit identified at time of analysis.
Authorization bypass in the @openclaw/voice-call package before version 2026.8.1 lets a remote caller who is admitted by the configured inbound-call policy (open, pairing, or allowlist) drive the agent's owner-only tools, because the caller's identity and non-owner status are not propagated on classic inbound voice calls. The owner-only tool filter therefore fails open, allowing data reads, file modification, command execution, or control of connected services depending on how the agent is provisioned. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (CVSS 4.0 base 8.7), and no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments with inbound calling disabled, or whose allowlist excludes the attacker, are not affected.
OpenClaw (npm package 'openclaw') versions before 2026.8.1 leak deterministic hashes computed over the original, unredacted configuration inside responses to redacted configuration requests, so a caller who can invoke operations such as config.get can perform offline password-candidate testing instead of going through the rate-limited Gateway authentication endpoint. Exploitation is conditional: the attacker must already hold an authenticated, low-privileged session able to retrieve the redacted config, the Gateway password must have low entropy, and the remaining non-redacted configuration values must be reconstructable enough to compute candidate hashes - high-entropy passwords defeat the attack entirely and secret references are not exposed by the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis, and recovery of the password would grant the documented shared-secret operator authority, which explains the High confidentiality, integrity and availability impact rating.
Authorization bypass in OpenClaw's Matrix integration (@openclaw/matrix) allows an authenticated Matrix participant to inherit another account's authority when their user identifier collides after case/Unicode folding. Versions 2026.2.2 through 2026.8.0 lowercase the complete Matrix user ID - including the case-sensitive server-name portion and historical localparts - before deriving the OpenClaw authorization identity, so an attacker controlling a protocol-valid, fold-equivalent identifier (display-name matching is not required) can gain allowlist, owner-command, exec-approval, or plugin-approval rights configured for the privileged account. The vendor rates this CVSS 7.7 with high confidentiality, integrity, and availability impact; real-world risk is moderate and gated by the attacker needing a valid authenticated Matrix account plus a registrable colliding identifier, and no public exploit identified at time of analysis.
Incorrect authorization in OpenClaw Feishu before 2026.8.1 allows an authenticated attacker who can already invoke the agent's model tool operations to act through a default account that the operator has disabled, because the account-selection logic never checks the disabled flag before using that account's still-stored Feishu credentials. Successful exploitation lets the attacker read or modify Feishu resources under a revoked identity, yielding high confidentiality and integrity impact (CVSS 4.0 base 7.6; assessed CVSS 3.1 7.6 with AV:N/AC:H/PR:L/UI:N/C:H/I:H/A:N by our analysis). Exploitation is conditional and non-default: it requires a multi-account configuration where the default account is disabled yet its credentials remain valid, plus pre-existing low-privilege access to the OpenClaw agent, so it is not reachable by an anonymous remote attacker against a default install; no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Local file disclosure in OpenClaw (npm package 'openclaw') before 2026.8.1 allows an authenticated, already-admitted requester to read arbitrary known local host files even when that sender's identity has been explicitly denied filesystem read tools through the global or per-agent toolsBySender policy. The bypass occurs because outbound attachment handling - via a final-response media directive or a message attachment - does not re-apply the originating sender's policy, so a denied sender can still have a known local file read and returned to an admitted requester whose agent turn never included the read tool. Exploitation requires the attacker to already be admitted to the agent, to know or derive a useful host path, and to reach a delivery flow that accepts local attachments; impact is read-only disclosure of file contents with no integrity or availability effect, and no public exploit code has been identified at time of analysis.
Sensitive local file disclosure in OpenClaw before 2026.8.1 lets a low-privileged caller (PR:L per the CVSS vector, not fully anonymous) smuggle an unvalidated absolute host path past sandbox path validation by supplying structured message attachments that carry multiple 'source' fields, hiding the disallowed path behind an allowed attachment source. When the Telegram delivery channel is configured and active, the agent then reads the referenced host file and relays it out through that channel, giving the attacker high-confidentiality read access to files that policy would otherwise reject. There is no code execution, file modification, or denial of service; EPSS and KEV data are not provided, and no public exploit code has been identified at time of analysis. The vendor has released a fix, and exploitation requires both a message-submission-capable attacker and an OpenClaw deployment that uses Telegram delivery.
Privilege escalation in the OpenClaw npm package (versions >= 2026.4.5 and < 2026.8.1) allows a restricted external sender to have its session-derived text persisted into shared session memory and later replayed to an unattended background 'dreaming' agent that holds broader file and command privileges, producing actions beyond the authority of the original turn. The flaw is only reachable in deployments where session-memory capture and the dreaming agent are both enabled and the background agent is provisioned with more capability than the originating turn, and the exploit chain additionally depends on the content being selected for later processing and then actually followed by the model. No public exploit identified at time of analysis; vendor has released a fix in OpenClaw 2026.8.1, and the vendor-assigned CVSS 4.0 score is 7.7.
Authenticated non-owner senders can abuse the generic channel-tool path in the @openclaw/whatsapp plugin (npm, versions before 2026.8.1) to force a WhatsApp login for a configured Gateway account, issuing a fresh QR code that disconnects the existing session and causes loss of availability; integrity impact is limited because full account relinking still requires the attacker to physically scan the returned QR code with another phone. The flaw is a missing authorization check on an owner-only tool boundary (CWE-862) rather than a bypass of WhatsApp transport authentication, and it requires PR:L - an attacker who has already been admitted to a channel and can steer the agent. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released a fix in version 2026.8.1.
An authenticated attacker with low privileges can exploit an authorization bypass in the @openclaw/slack npm package (versions before 2026.8.1) to download file contents from Slack conversations outside their permitted scope, resulting in cross-boundary data disclosure. The flaw is an IDOR-class (CWE-639) issue where the conversation-authorization check fails open when a file lacks the share metadata normally used to prove conversation membership. No public exploit code or active exploitation has been identified, and the issue does not bypass Slack's own authentication or allow file enumeration. Vendor patch 2026.8.1 is available.
Directory-context bypass in OpenClaw before 2026.8.1 allows authenticated attackers with user interaction to reuse an 'allow-always' exec approval to execute the same command against unreviewed files or repositories, escaping the original approved working directory. Exploitation requires a pre-existing 'allow-always' approval and the ability to influence agent behavior; it is not exploitable on a default installation with no standing approvals. No public exploit identified at time of analysis.
Authorization scope widening in OpenClaw before 2026.8.1 allows an authenticated low-privilege sender to reuse a standing 'allow-always' file-transfer approval and reach file paths or nodes that the operator never reviewed, resulting in unauthorized file read and write (C:H/I:H, no availability impact) within whatever the agent's file-transfer capability can touch. Exploitation is conditional: it requires a previously granted allow-always approval, an already-admitted sender who can steer the agent (PR:L/UI:P), and successful abuse of glob metacharacter interpretation or node display-name reuse to resolve the grant to sibling paths or a different node (AC:H/AT:P), so it is not reliably automatable and there is no prior grant to widen otherwise. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited; a vendor patch is available in OpenClaw 2026.8.1.
Information disclosure in Actual Sync Server versions prior to 26.7.0 allows an authenticated user (CVSS PR:L) to bypass the plugin CORS proxy allowlist and cause the server to attach its configured ACTUAL_GITHUB_TOKEN to GitHub API requests outside the permitted repository, exposing private GitHub resources that the token can reach. The flaw is a prefix-matching error: the allowlist check accepts any GitHub API path beginning with /repos/{owner}/{repo}, so sibling repositories sharing an allowlisted repository's name prefix pass validation. Exploitation is config-gated - it requires the operator to have set ACTUAL_GITHUB_TOKEN and to have at least one allowlisted public plugin repository - and impact is bounded by whatever permissions that token holds; no public exploit code was identified at time of analysis, and the vendor has released a fix in 26.7.0.
Brute-force attacks against the POST /api/auth login endpoint in Flame through 2.4.0 let remote, unauthenticated attackers submit unlimited password guesses because the endpoint implements no rate limiting, attempt counters, delays, or lockouts. A successful guess yields full administrator access and the ability to modify application configuration. Exploitation requires network reachability to the instance and is only practical against weak or default-style admin passwords - a long, high-entropy password makes guessing impractical (reflected in AC:H/AT:P), and no public exploit code has been identified at time of analysis; instances behind a VPN, an authenticating reverse proxy, or on isolated LANs are not remotely reachable.
Transactions built through a remote StorageClient in @bsv/wallet-toolbox 1.1.47 through 2.3.3, @bsv/wallet-toolbox-client 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile 1.3.21 through 2.3.3 can be silently redirected by a malicious or compromised storage provider, which returns output locking scripts the wallet signs without confirming they match the caller's request. Because the provider can substitute a recipient script or append an attacker-controlled output funded by shrinking change, the wallet broadcasts a transaction paying the attacker while the application and user interface still display the intended recipient; the integrity impact is high with no confidentiality or availability effect, and no authentication against the victim wallet is required (CVSS 4.0 8.7, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Exploitation requires the application to use a remote StorageClient backend the attacker controls and the user to initiate a transaction through it - local-storage applications and those that independently verify outputs are unaffected; no public exploit code has been identified at time of analysis and the issue is patched in 2.4.0.
Denial of service in NodeRedis redis-parser through 3.0.0 lets a hostile or hijacked Redis endpoint crash the Node.js client process by returning a crafted RESP multi-bulk header whose declared length exceeds 2^32-1, triggering an uncaught RangeError during parsing. The flaw is reachable by unauthenticated remote attackers (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N) but its impact is strictly availability (VA:H) - no confidentiality, integrity, or scope impact - so a malicious server, a compromised legitimate Redis instance, or an on-path injector in the RESP response stream can only take down the parsing process. Rated 8.7 (HIGH) by CVSS 4.0, with no public exploit identified at time of analysis and no confirmed vendor-released patch, though the issue is publicly tracked upstream.