Common Weakness Enumeration

CWE-349

Allowed

Acceptance of Extraneous Untrusted Data With Trusted Data

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

82 vulnerabilities reference this CWE, most recent first.

GHSA-G8WJ-3CR3-6W7V

Vulnerability from github – Published: 2026-05-19 20:03 – Updated: 2026-07-08 17:35
VLAI
Summary
Nuxt: `__nuxt_island` endpoint does not bind responses to request props, enabling shared-cache poisoning
Details

Summary

The /__nuxt_island/* endpoint accepts attacker-controlled props query/body parameters and renders any island component without verifying that the URL-resident hash (<Name>_<hashId>.json) was actually issued for those inputs by <NuxtIsland>. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query.

Island components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does not treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one.

Impact

In applications where a CDN or reverse-proxy in front of the app caches /__nuxt_island/* keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a path with their own choice of props, and subsequent users requesting the same path receive the attacker's rendered HTML rather than the response intended for them. The cache entry persists until normal expiry.

Where the affected island has any prop flowing into an unsafe HTML sink in application code (v-html, innerHTML, a third-party renderer treating a prop as HTML), this becomes stored XSS in the embedding page's origin until the cache entry expires. HttpOnly cookies remain out of reach but anything else in the origin (other cookies, in-origin requests, DOM state) is reachable by the injected script.

Preconditions:

  • experimental.componentIslands enabled (or the default 'auto' with at least one server / island component in the app).
  • A shared intermediary cache (CDN, reverse-proxy, edge cache) keyed on path only.
  • For the XSS pivot specifically: an application-authored island that puts a prop through an unsafe HTML sink.

Without the second precondition, the response shape is per-request and unaffected. Without the third, the worst case is content-swap / inert HTML injection rather than script execution.

Patches

Patched in nuxt@4.4.6 and nuxt@3.21.6 by #35077. The island handler now recomputes the expected hashId from (name, props, context) using the same ohash function <NuxtIsland> already uses to embed the hash in the URL, and rejects requests (HTTP 400) whose URL-resident hash does not match. The response is now a pure function of the request path: a path-keyed shared cache returns the correct response to every requester for that path, and an attacker cannot synthesise a path whose hash matches arbitrary props.

Workarounds

For users unable to upgrade immediately:

  • Ensure any intermediary cache keys /__nuxt_island/* on the full query string, not on the path alone. This is the recommended configuration regardless.
  • Audit application-authored islands for props flowing into v-html / innerHTML / similar HTML sinks; treat island props as untrusted user input.

Note on island authentication

[!IMPORTANT] It's important to remember that route middleware does not run when rendering island components, and islands cannot rely on routing-layer auth. Applications gating sensitive data behind page middleware should enforce that auth inside the island's own data layer (server-only routes, useRequestEvent + manual session checks, etc.) rather than relying on the embedding page's middleware - this was true before this advisory and remains true after it.

A separate advisory addresses *.server.vue pages registered as page_<routeName> islands, where the documented "middleware doesn't run for islands" contract collides with the page's own definePageMeta({ middleware }) declaration in a way that constitutes a genuine bug rather than documented behaviour.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.21.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.21.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-alpha.1"
            },
            {
              "fixed": "4.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.21.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nuxt/nitro-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.21.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nuxt/nitro-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-444",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T20:03:24Z",
    "nvd_published_at": "2026-06-12T14:16:31Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `/__nuxt_island/*` endpoint accepts attacker-controlled `props` query/body parameters and renders any island component without verifying that the URL-resident hash (`\u003cName\u003e_\u003chashId\u003e.json`) was actually issued for those inputs by `\u003cNuxtIsland\u003e`. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query.\n\nIsland components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does **not** treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one.\n\n### Impact\n\nIn applications where a CDN or reverse-proxy in front of the app caches `/__nuxt_island/*` keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a path with their own choice of props, and subsequent users requesting the same path receive the attacker\u0027s rendered HTML rather than the response intended for them. The cache entry persists until normal expiry.\n\nWhere the affected island has any prop flowing into an unsafe HTML sink in application code (`v-html`, `innerHTML`, a third-party renderer treating a prop as HTML), this becomes stored XSS in the embedding page\u0027s origin until the cache entry expires. `HttpOnly` cookies remain out of reach but anything else in the origin (other cookies, in-origin requests, DOM state) is reachable by the injected script.\n\nPreconditions:\n\n- `experimental.componentIslands` enabled (or the default `\u0027auto\u0027` with at least one server / island component in the app).\n- A shared intermediary cache (CDN, reverse-proxy, edge cache) keyed on path only.\n- For the XSS pivot specifically: an application-authored island that puts a prop through an unsafe HTML sink.\n\nWithout the second precondition, the response shape is per-request and unaffected. Without the third, the worst case is content-swap / inert HTML injection rather than script execution.\n\n### Patches\n\nPatched in `nuxt@4.4.6` and `nuxt@3.21.6` by [#35077](https://github.com/nuxt/nuxt/pull/35077). The island handler now recomputes the expected `hashId` from `(name, props, context)` using the same `ohash` function `\u003cNuxtIsland\u003e` already uses to embed the hash in the URL, and rejects requests (HTTP 400) whose URL-resident hash does not match. The response is now a pure function of the request path: a path-keyed shared cache returns the correct response to every requester for that path, and an attacker cannot synthesise a path whose hash matches arbitrary props.\n\n### Workarounds\n\nFor users unable to upgrade immediately:\n\n- Ensure any intermediary cache keys `/__nuxt_island/*` on the full query string, not on the path alone. This is the recommended configuration regardless.\n- Audit application-authored islands for props flowing into `v-html` / `innerHTML` / similar HTML sinks; treat island props as untrusted user input.\n\n### Note on island authentication\n\n\u003e [!IMPORTANT]\n\u003e It\u0027s important to remember that route middleware does not run when rendering island components, and islands cannot rely on routing-layer auth. Applications gating sensitive data behind page middleware should enforce that auth inside the island\u0027s own data layer (server-only routes, `useRequestEvent` + manual session checks, etc.) rather than relying on the embedding page\u0027s middleware - this was true before this advisory and remains true after it.\n\nA separate advisory addresses `*.server.vue` *pages* registered as `page_\u003crouteName\u003e` islands, where the documented \"middleware doesn\u0027t run for islands\" contract collides with the page\u0027s own `definePageMeta({ middleware })` declaration in a way that constitutes a genuine bug rather than documented behaviour.",
  "id": "GHSA-g8wj-3cr3-6w7v",
  "modified": "2026-07-08T17:35:09Z",
  "published": "2026-05-19T20:03:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-g8wj-3cr3-6w7v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46342"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/pull/35077"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nuxt: `__nuxt_island` endpoint does not bind responses to request props, enabling shared-cache poisoning"
}

GHSA-GC56-W3PR-7W7F

Vulnerability from github – Published: 2025-10-18 09:30 – Updated: 2025-10-18 09:30
VLAI
Details

The WP Go Maps (formerly WP Google Maps) plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 9.0.48. This is due to the plugin not serving cached data from server-side responses and instead relying on user-input. This makes it possible for unauthenticated attackers to poison the cache location for location search results.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-11703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-18T07:15:35Z",
    "severity": "MODERATE"
  },
  "details": "The WP Go Maps (formerly WP Google Maps) plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 9.0.48. This is due to the plugin not serving cached data from server-side responses and instead relying on user-input. This makes it possible for unauthenticated attackers to poison the cache location for location search results.",
  "id": "GHSA-gc56-w3pr-7w7f",
  "modified": "2025-10-18T09:30:51Z",
  "published": "2025-10-18T09:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11703"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CodeCabin/wp-google-maps/pull/1087/files"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3378871%40wp-google-maps\u0026new=3378871%40wp-google-maps\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2025-11703"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/531360c6-e78a-4344-be06-95735337a2d6?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GP8F-8M3G-QVJ9

Vulnerability from github – Published: 2024-09-17 21:58 – Updated: 2024-09-18 14:28
VLAI
Summary
Next.js Cache Poisoning
Details

Impact

By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.

To be potentially affected all of the following must apply:

  • Next.js between 13.5.1 and 14.2.9
  • Using pages router
  • Using non-dynamic server-side rendered routes e.g. pages/dashboard.tsx not pages/blog/[slug].tsx

The below configurations are unaffected:

  • Deployments using only app router
  • Deployments on Vercel are not affected

Patches

This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.

Workarounds

There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.

Credits

  • Allam Rachid (zhero_)
  • Henry Chen
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.5.1"
            },
            {
              "fixed": "13.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0"
            },
            {
              "fixed": "14.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-46982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-17T21:58:09Z",
    "nvd_published_at": "2024-09-17T22:15:02Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nBy sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a `Cache-Control: s-maxage=1, stale-while-revalidate` header which some upstream CDNs may cache as well. \n\nTo be potentially affected all of the following must apply: \n\n- Next.js between 13.5.1 and 14.2.9\n- Using pages router\n- Using non-dynamic server-side rendered routes e.g. `pages/dashboard.tsx` not `pages/blog/[slug].tsx`\n\nThe below configurations are unaffected:\n\n- Deployments using only app router\n- Deployments on [Vercel](https://vercel.com/) are not affected\n\n\n### Patches\n\nThis vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.\n\n### Workarounds\n\nThere are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.\n\n#### Credits\n\n- Allam Rachid (zhero_)\n- Henry Chen",
  "id": "GHSA-gp8f-8m3g-qvj9",
  "modified": "2024-09-18T14:28:54Z",
  "published": "2024-09-17T21:58:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-gp8f-8m3g-qvj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46982"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/7ed7f125e07ef0517a331009ed7e32691ba403d3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/bd164d53af259c05f1ab434004bcfdd3837d7cda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Next.js Cache Poisoning"
}

GHSA-GPRP-2VJM-M5GJ

Vulnerability from github – Published: 2023-11-14 12:30 – Updated: 2025-01-14 12:31
VLAI
Details

A vulnerability has been identified in SCALANCE XB205-3 (SC, PN) (All versions < V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB205-3 (ST, PN) (All versions < V4.5), SCALANCE XB205-3LD (SC, E/IP) (All versions < V4.5), SCALANCE XB205-3LD (SC, PN) (All versions < V4.5), SCALANCE XB208 (E/IP) (All versions < V4.5), SCALANCE XB208 (PN) (All versions < V4.5), SCALANCE XB213-3 (SC, E/IP) (All versions < V4.5), SCALANCE XB213-3 (SC, PN) (All versions < V4.5), SCALANCE XB213-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB213-3 (ST, PN) (All versions < V4.5), SCALANCE XB213-3LD (SC, E/IP) (All versions < V4.5), SCALANCE XB213-3LD (SC, PN) (All versions < V4.5), SCALANCE XB216 (E/IP) (All versions < V4.5), SCALANCE XB216 (PN) (All versions < V4.5), SCALANCE XC206-2 (SC) (All versions < V4.5), SCALANCE XC206-2 (ST/BFOC) (All versions < V4.5), SCALANCE XC206-2G PoE (All versions < V4.5), SCALANCE XC206-2G PoE (54 V DC) (All versions < V4.5), SCALANCE XC206-2G PoE EEC (54 V DC) (All versions < V4.5), SCALANCE XC206-2SFP (All versions < V4.5), SCALANCE XC206-2SFP EEC (All versions < V4.5), SCALANCE XC206-2SFP G (All versions < V4.5), SCALANCE XC206-2SFP G (EIP DEF.) (All versions < V4.5), SCALANCE XC206-2SFP G EEC (All versions < V4.5), SCALANCE XC208 (All versions < V4.5), SCALANCE XC208EEC (All versions < V4.5), SCALANCE XC208G (All versions < V4.5), SCALANCE XC208G (EIP def.) (All versions < V4.5), SCALANCE XC208G EEC (All versions < V4.5), SCALANCE XC208G PoE (All versions < V4.5), SCALANCE XC208G PoE (54 V DC) (All versions < V4.5), SCALANCE XC216 (All versions < V4.5), SCALANCE XC216-3G PoE (All versions < V4.5), SCALANCE XC216-3G PoE (54 V DC) (All versions < V4.5), SCALANCE XC216-4C (All versions < V4.5), SCALANCE XC216-4C G (All versions < V4.5), SCALANCE XC216-4C G (EIP Def.) (All versions < V4.5), SCALANCE XC216-4C G EEC (All versions < V4.5), SCALANCE XC216EEC (All versions < V4.5), SCALANCE XC224 (All versions < V4.5), SCALANCE XC224-4C G (All versions < V4.5), SCALANCE XC224-4C G (EIP Def.) (All versions < V4.5), SCALANCE XC224-4C G EEC (All versions < V4.5), SCALANCE XF204 (All versions < V4.5), SCALANCE XF204 DNA (All versions < V4.5), SCALANCE XF204-2BA (All versions < V4.5), SCALANCE XF204-2BA DNA (All versions < V4.5), SCALANCE XP208 (All versions < V4.5), SCALANCE XP208 (Ethernet/IP) (All versions < V4.5), SCALANCE XP208EEC (All versions < V4.5), SCALANCE XP208PoE EEC (All versions < V4.5), SCALANCE XP216 (All versions < V4.5), SCALANCE XP216 (Ethernet/IP) (All versions < V4.5), SCALANCE XP216EEC (All versions < V4.5), SCALANCE XP216POE EEC (All versions < V4.5), SCALANCE XR324WG (24 x FE, AC 230V) (All versions < V4.5), SCALANCE XR324WG (24 X FE, DC 24V) (All versions < V4.5), SCALANCE XR326-2C PoE WG (All versions < V4.5), SCALANCE XR326-2C PoE WG (without UL) (All versions < V4.5), SCALANCE XR328-4C WG (24XFE, 4XGE, 24V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE, 4xGE,DC24V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions < V4.5), SCALANCE XR328-4C WG (28xGE, AC 230V) (All versions < V4.5), SCALANCE XR328-4C WG (28xGE, DC 24V) (All versions < V4.5), SIPLUS NET SCALANCE XC206-2 (All versions < V4.5), SIPLUS NET SCALANCE XC206-2SFP (All versions < V4.5), SIPLUS NET SCALANCE XC208 (All versions < V4.5), SIPLUS NET SCALANCE XC216-4C (All versions < V4.5). Affected products do not properly validate the content of uploaded X509 certificates which could allow an attacker with administrative privileges to execute arbitrary code on the device.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-44317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T11:15:12Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SCALANCE XB205-3 (SC, PN) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, PN) (All versions \u003c V4.5), SCALANCE XB205-3LD (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3LD (SC, PN) (All versions \u003c V4.5), SCALANCE XB208 (E/IP) (All versions \u003c V4.5), SCALANCE XB208 (PN) (All versions \u003c V4.5), SCALANCE XB213-3 (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3 (SC, PN) (All versions \u003c V4.5), SCALANCE XB213-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3 (ST, PN) (All versions \u003c V4.5), SCALANCE XB213-3LD (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3LD (SC, PN) (All versions \u003c V4.5), SCALANCE XB216 (E/IP) (All versions \u003c V4.5), SCALANCE XB216 (PN) (All versions \u003c V4.5), SCALANCE XC206-2 (SC) (All versions \u003c V4.5), SCALANCE XC206-2 (ST/BFOC) (All versions \u003c V4.5), SCALANCE XC206-2G PoE (All versions \u003c V4.5), SCALANCE XC206-2G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC206-2G PoE EEC (54 V DC) (All versions \u003c V4.5), SCALANCE XC206-2SFP (All versions \u003c V4.5), SCALANCE XC206-2SFP EEC (All versions \u003c V4.5), SCALANCE XC206-2SFP G (All versions \u003c V4.5), SCALANCE XC206-2SFP G (EIP DEF.) (All versions \u003c V4.5), SCALANCE XC206-2SFP G EEC (All versions \u003c V4.5), SCALANCE XC208 (All versions \u003c V4.5), SCALANCE XC208EEC (All versions \u003c V4.5), SCALANCE XC208G (All versions \u003c V4.5), SCALANCE XC208G (EIP def.) (All versions \u003c V4.5), SCALANCE XC208G EEC (All versions \u003c V4.5), SCALANCE XC208G PoE (All versions \u003c V4.5), SCALANCE XC208G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC216 (All versions \u003c V4.5), SCALANCE XC216-3G PoE (All versions \u003c V4.5), SCALANCE XC216-3G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC216-4C (All versions \u003c V4.5), SCALANCE XC216-4C G (All versions \u003c V4.5), SCALANCE XC216-4C G (EIP Def.) (All versions \u003c V4.5), SCALANCE XC216-4C G EEC (All versions \u003c V4.5), SCALANCE XC216EEC (All versions \u003c V4.5), SCALANCE XC224 (All versions \u003c V4.5), SCALANCE XC224-4C G (All versions \u003c V4.5), SCALANCE XC224-4C G (EIP Def.) (All versions \u003c V4.5), SCALANCE XC224-4C G EEC (All versions \u003c V4.5), SCALANCE XF204 (All versions \u003c V4.5), SCALANCE XF204 DNA (All versions \u003c V4.5), SCALANCE XF204-2BA (All versions \u003c V4.5), SCALANCE XF204-2BA DNA (All versions \u003c V4.5), SCALANCE XP208 (All versions \u003c V4.5), SCALANCE XP208 (Ethernet/IP) (All versions \u003c V4.5), SCALANCE XP208EEC (All versions \u003c V4.5), SCALANCE XP208PoE EEC (All versions \u003c V4.5), SCALANCE XP216 (All versions \u003c V4.5), SCALANCE XP216 (Ethernet/IP) (All versions \u003c V4.5), SCALANCE XP216EEC (All versions \u003c V4.5), SCALANCE XP216POE EEC (All versions \u003c V4.5), SCALANCE XR324WG (24 x FE, AC 230V) (All versions \u003c V4.5), SCALANCE XR324WG (24 X FE, DC 24V) (All versions \u003c V4.5), SCALANCE XR326-2C PoE WG (All versions \u003c V4.5), SCALANCE XR326-2C PoE WG (without UL) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24XFE, 4XGE, 24V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE, 4xGE,DC24V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (28xGE, AC 230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (28xGE, DC 24V) (All versions \u003c V4.5), SIPLUS NET SCALANCE XC206-2 (All versions \u003c V4.5), SIPLUS NET SCALANCE XC206-2SFP (All versions \u003c V4.5), SIPLUS NET SCALANCE XC208 (All versions \u003c V4.5), SIPLUS NET SCALANCE XC216-4C (All versions \u003c V4.5). Affected products do not properly validate the content of uploaded X509 certificates which could allow an attacker with administrative privileges to execute arbitrary code on the device.",
  "id": "GHSA-gprp-2vjm-m5gj",
  "modified": "2025-01-14T12:31:47Z",
  "published": "2023-11-14T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44317"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-068047.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-602936.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-690517.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-699386.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-068047.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-699386.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JFGC-MGQQ-R573

Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-24 15:32
VLAI
Details

In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.

Severity
9.3 (Critical)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
5.7 (Medium)
CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H/E:P/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-50252"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T14:17:20Z",
    "severity": "MODERATE"
  },
  "details": "In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled (\u0027so-reuseport: yes\u0027) in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel\u2019s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver\u2019s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.",
  "id": "GHSA-jfgc-mgqq-r573",
  "modified": "2026-07-24T15:32:55Z",
  "published": "2026-07-22T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50252"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-50252.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JRWQ-36RX-842C

Vulnerability from github – Published: 2025-05-21 18:33 – Updated: 2025-05-21 18:33
VLAI
Details

A vulnerability in client join services of Cisco Webex Meetings could allow an unauthenticated, remote attacker to manipulate cached HTTP responses within the meeting join service.

This vulnerability is due to improper handling of malicious HTTP requests to the affected service. An attacker could exploit this vulnerability by manipulating stored HTTP responses within the service, also known as HTTP cache poisoning. A successful exploit could allow the attacker to cause the Webex Meetings service to return incorrect HTTP responses to clients.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-20255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-21T17:15:56Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in client join services of Cisco Webex Meetings could allow an unauthenticated, remote attacker to manipulate cached HTTP responses within the meeting join service.\n\n This vulnerability is due to improper handling of malicious HTTP requests to the affected service. An attacker could exploit this vulnerability by manipulating stored HTTP responses within the service, also known as HTTP cache poisoning. A successful exploit could allow the attacker to cause the Webex Meetings service to return incorrect HTTP responses to clients.",
  "id": "GHSA-jrwq-36rx-842c",
  "modified": "2025-05-21T18:33:31Z",
  "published": "2025-05-21T18:33:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20255"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-cache-Q4xbkQBG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVHM-GJRH-3H93

Vulnerability from github – Published: 2025-03-19 19:54 – Updated: 2025-03-20 19:31
VLAI
Summary
Nuxt allows DOS via cache poisoning with payload rendering response
Details

Summary

By sending a crafted HTTP request to a server behind an CDN, it is possible in some circumstances to poison the CDN cache and highly impacts the availability of a site.

It is possible to craft a request, such as https://mysite.com/?/_payload.json which will be rendered as JSON. If the CDN in front of a Nuxt site ignores the query string when determining whether to cache a route, then this JSON response could be served to future visitors to the site.

Impact

An attacker can perform this attack to a vulnerable site in order to make a site unavailable indefinitely. It is also possible in the case where the cache will be reset to make a small script to send a request each X seconds (=caching duration) so that the cache is permanently poisoned making the site completely unavailable.

Conclusion :

This is similar to a vulnerability in Next.js that resulted in CVE-2024-46982 (and see this article, in particular the "Internal URL parameter and pageProps" part, the latter being very similar to the one concerning us here.)

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-19T19:54:25Z",
    "nvd_published_at": "2025-03-19T19:15:47Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nBy sending a crafted HTTP request to a server behind an CDN, it is possible in some circumstances to poison the CDN cache and highly impacts the availability of a site.\n\nIt is possible to craft a request, such as `https://mysite.com/?/_payload.json` which will be rendered as JSON. If the CDN in front of a Nuxt site ignores the query string when determining whether to cache a route, then this JSON response could be served to future visitors to the site.\n\n### Impact\n\nAn attacker can perform this attack to a vulnerable site in order to make a site unavailable indefinitely. It is also possible in the case where the cache will be reset to make a small script to send a request each X seconds (=caching duration) so that the cache is permanently poisoned making the site completely unavailable.\n\n\n## Conclusion : \n\nThis is similar to a vulnerability in Next.js that resulted in CVE-2024-46982 (and see [this article](https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir), in particular the \"Internal URL parameter and pageProps\" part, the latter being very similar to the one concerning us here.)",
  "id": "GHSA-jvhm-gjrh-3h93",
  "modified": "2025-03-20T19:31:04Z",
  "published": "2025-03-19T19:54:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-jvhm-gjrh-3h93"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27415"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nuxt allows DOS via cache poisoning with payload rendering response"
}

GHSA-JWM6-6MGM-W3F5

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-04-04 02:15
VLAI
Details

A vulnerability exists in the way that iTerm2 integrates with tmux's control mode, which may allow an attacker to execute arbitrary commands by providing malicious output to the terminal. This affects versions of iTerm2 up to and including 3.3.5. This vulnerability may allow an attacker to execute arbitrary commands on their victim's computer by providing malicious output to the terminal. It could be exploited using command-line utilities that print attacker-controlled content.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-9535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-74"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-09T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability exists in the way that iTerm2 integrates with tmux\u0027s control mode, which may allow an attacker to execute arbitrary commands by providing malicious output to the terminal. This affects versions of iTerm2 up to and including 3.3.5. This vulnerability may allow an attacker to execute arbitrary commands on their victim\u0027s computer by providing malicious output to the terminal. It could be exploited using command-line utilities that print attacker-controlled content.",
  "id": "GHSA-jwm6-6mgm-w3f5",
  "modified": "2024-04-04T02:15:20Z",
  "published": "2022-05-24T16:58:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9535"
    },
    {
      "type": "WEB",
      "url": "https://blog.mozilla.org/security/2019/10/09/iterm2-critical-issue-moss-audit"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/iterm2-discuss/57k_AuLdQa4"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#%21topic/iterm2-discuss/57k_AuLdQa4"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/763073"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3MH-3MPG-37HW

Vulnerability from github – Published: 2026-03-30 18:52 – Updated: 2026-04-10 19:45
VLAI
Summary
OpenClaw has an Arbitrary Malicious Code Execution Vulnerability
Details

Fixed in OpenClaw 2026.3.24, the current shipping release.

Summary

During the installation phase of OpenClaw local plugins/hooks, the Git executable can be hijacked by a project-level .npmrc file, leading to arbitrary code execution during installation.

Details

Please note that the source code locations mentioned below are based on version openclaw-2026.3.13-1, but the issue has been confirmed to still exist in the current latest version, 2026.3.23.

When installing a local plugin directory, local plugin archive, local hook pack directory, or local hook pack archive, OpenClaw first copies the source directory to a temporary stageDir, then executes the following in that directory:

npm install --omit=dev --silent --ignore-scripts

See src/infra/install-package-dir.ts:176-199.

Since this process does not strip the project root .npmrc, and npm reads the project-level .npmrc during local project installation, an attacker could use a .npmrc file in a malicious plugin or hook directory to override npm’s git executable path. By leveraging a Git dependency, the attacker could trigger npm to call this malicious program, thereby executing arbitrary local code during the installation phase.

Affected Paths

  • Plugin CLI entry point: src/cli/plugins-cli.ts:199-255
  • Hook CLI entry point: src/cli/hooks-cli.ts:573-676
  • Plugin local directory / archive installation: src/plugins/install.ts:379-405, src/plugins/install.ts:541-565
  • Hook local directory / archive installation: src/hooks/install.ts:380-403, src/hooks/install.ts:443-470
  • Actual execution of npm install --ignore-scripts: src/infra/install-package-dir.ts:176-199

Vulnerability Trigger Flow

  1. The user executes one of the following commands:

  2. openclaw plugins install <path-or-spec>

  3. openclaw hooks install <path-or-spec>
  4. If the argument is a local directory or local archive, OpenClaw navigates to the local installation path.
  5. OpenClaw copies the source directory to a temporary stageDir. See src/infra/install-package-dir.ts:176-177.
  6. If dependencies are present in package.json, OpenClaw executes the following in stageDir:
npm install --omit=dev --silent --ignore-scripts

See src/infra/install-package-dir.ts:188-199.

  1. npm reads the project-level .npmrc file in this directory. Official documentation: .npmrc
  2. If .npmrc is set to git=<path to malicious program> and there is a git dependency in the dependency tree, npm will invoke that git program when resolving the dependency. Official documentation: npm config git Git dependency documentation: package.json
  3. Consequently, an attacker can execute arbitrary local programs during the plugin/hook installation phase without waiting for the plugin or hook to be loaded later.

Triggering Commands

  • Plugin installation command:
openclaw plugins install <path-or-spec>
  • Hook installation command:
openclaw hooks install <path-or-spec>

When <path-or-spec> is a local directory or local archive, it will be resolved to the path used by the npm install --omit=dev --silent --ignore-scripts command mentioned above.

PoC

Currently, testpoc/ is a minimal PoC directory used to verify that “when installing local packages, OpenClaw enters the npm install --ignore-scripts path.” It is divided into two core sections:

testpoc/pkg/ Purpose: Simulates the local package directory installed by openclaw plugins install ... or openclaw hooks install ... testpoc/repo/ Purpose: Simulates a Git dependency repository within the npm dependency tree Directory Structure

testpoc/ ├─ pkg/ │ ├─ .npmrc │ ├─ package.json │ └─ sample-hook/ │ ├─ HOOK.md │ └─ handler.js └─ repo/ ├─ package.json └─ .git/... Function of Each Component

testpoc/pkg/.npmrc

Current content: git=calc.exe Function: Overrides npm’s Git executable configuration. Meaning: When npm encounters a git dependency during installation, it will not call the system git but will attempt to call the program specified here. This is the core trigger point of this PoC. See testpoc/pkg/.npmrc:1 testpoc/pkg/package.json

Currently, this is a “mixed-use” manifest that includes both plugin and hook fields: { “name”: “probe-host”, “version”: “1.0.0”, “private”: true, “openclaw”: { “extensions”: [“./dist/index.js”], “hooks”: [“./sample-hook”] }, “dependencies”: { “probe-git-dep”: “git+file:///D:/AI Agent Source/OpenClaw/openclaw-2026.3.13-1/.testpoc/repo” } } Its functionality is divided into three layers: openclaw.extensions: Allows it to be validated as a plugin package openclaw.hooks: Enables it to be validated as a hook package The Git URL in dependencies: Forces npm to enter the Git dependency resolution path during installation See testpoc/pkg/package.json:1 testpoc/pkg/sample-hook/HOOK.md

Purpose: To meet the minimum metadata requirements for a hook package. This is the key file that allows openclaw hooks install pkg to pass the pre-check. See testpoc/pkg/sample-hook/HOOK.md:1 testpoc/pkg/sample-hook/handler.js

Current content: export default async function handler() { return { ok: true }; } Purpose: Meets the requirement that the hook directory must contain a handler entry file. It is not a usage point in itself; its sole purpose is to allow OpenClaw to proceed to the dependency installation phase. See testpoc/pkg/sample-hook/handler.js:1 testpoc/repo/package.json

Current content: {“name”:“probe-git-dep”,‘version’:“1.0.0”} Purpose: Serves as the minimum repository content corresponding to a Git dependency. The focus is not on the repository code itself, but on the fact that “it is a Git repository,” allowing npm to perform Git-related operations on it. See testpoc/repo/package.json:1 testpoc/repo/.git/

Purpose: Makes testpoc/repo/ a real Git repository rather than a regular directory. When npm resolves git+file://... When installing dependencies, this is treated as the Git source. How the current PoC works

If installing via hooks:

openclaw hooks install testpoc/pkg The trigger chain is:

OpenClaw identifies testpoc/pkg as the local hook package path Through pre-validation in openclaw.hooks, HOOK.md, and handler.js Proceeds to src/infra/install-package-dir.ts:188-199 Executes: npm install --omit=dev --silent --ignore-scripts npm reads testpoc/pkg/.npmrc npm processes the git dependency in package.json npm attempts to call the git=calc.exe specified in .npmrc

Impact

It is best described as an installation-time local command execution / unsafe package-install configuration issue.

More precisely:

OpenClaw installs local plugin and hook packs by running npm install --omit=dev --silent --ignore-scripts inside the staged package directory, see src/infra/install-package-dir.ts:188-199. If that local package directory contains an attacker-controlled .npmrc, npm will still read it. If .npmrc overrides npm’s git executable and the package has a git dependency, npm can invoke the attacker-chosen program during install.

Who is impacted

Users who run:

openclaw plugins install openclaw hooks install

And who install a malicious or untrusted local package that includes:

a controlled .npmrc a git dependency a runnable attacker-controlled git target on that platform

This should be treated as a security issue, not just “malicious plugin behavior,” because the code execution happens during OpenClaw’s install workflow, before the plugin or hook is ever loaded as trusted runtime code.

The important distinction is:

A normal “trusted plugin” case is: the operator installs a plugin, enables it, and later that plugin runs with plugin privileges. This issue is different: OpenClaw’s installer executes npm install --omit=dev --silent --ignore-scripts inside an attacker-controlled package directory, and npm still honors attacker-controlled project config from .npmrc.

That means an untrusted local plugin or hook package can influence the package manager itself and reach arbitrary program execution at install time, via npm’s git setting and a git dependency, even though --ignore-scripts is present.

Why this matters from a security perspective:

It is install-time execution, not post-install trusted execution.

The execution is triggered by OpenClaw’s installer in src/infra/install-package-dir.ts:188-199.

This occurs before the package is accepted as a trusted loaded plugin/hook in the usual sense.

It defeats an expected safety boundary.

The code explicitly uses --ignore-scripts, which strongly suggests an intent to make installation safer.

But the installer still allows attacker-controlled package-manager configuration from .npmrc to affect execution.

So the current mitigation is incomplete in a security-relevant way.

The dangerous input is part of a supported user flow.

OpenClaw explicitly supports installing plugins and hook packs from local directories and archives:

src/cli/plugins-cli.ts:199-255 src/cli/hooks-cli.ts:573-676

That makes “download a package/archive, then install it” a realistic operator action, not an artificial lab setup.

The issue is broader than plugin trust.

The problem is not “plugins can do bad things once trusted.”

The problem is “the installer consumes attacker-controlled package-manager config before trust is established.”

That is much closer to an unsafe install / supply-chain execution flaw than to ordinary trusted-plugin behavior.

Hooks are affected too.

The same installer path is used for hook packs, not only plugins.

So this is a shared install-surface issue, not an isolated plugin-runtime concern.

Severity
8.6 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
8.4 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2025.3.23"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T18:52:09Z",
    "nvd_published_at": "2026-04-10T17:17:04Z",
    "severity": "HIGH"
  },
  "details": "\u003e Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n### Summary\nDuring the installation phase of OpenClaw local plugins/hooks, the Git executable can be hijacked by a project-level .npmrc file, leading to arbitrary code execution during installation.\n\n### Details\nPlease note that the source code locations mentioned below are based on version openclaw-2026.3.13-1, but the issue has been confirmed to still exist in the current latest version, 2026.3.23.\n\nWhen installing a local plugin directory, local plugin archive, local hook pack directory, or local hook pack archive, OpenClaw first copies the source directory to a temporary `stageDir`, then executes the following in that directory:\n\n```\nnpm install --omit=dev --silent --ignore-scripts\n```\n\nSee `src/infra/install-package-dir.ts:176-199`.\n\nSince this process does not strip the project root `.npmrc`, and npm reads the project-level `.npmrc` during local project installation, an attacker could use a `.npmrc` file in a malicious plugin or hook directory to override npm\u2019s `git` executable path. By leveraging a Git dependency, the attacker could trigger npm to call this malicious program, thereby executing arbitrary local code during the installation phase.\n\n**Affected Paths**\n\n- Plugin CLI entry point: `src/cli/plugins-cli.ts:199-255`\n- Hook CLI entry point: `src/cli/hooks-cli.ts:573-676`\n- Plugin local directory / archive installation: `src/plugins/install.ts:379-405`, `src/plugins/install.ts:541-565`\n- Hook local directory / archive installation: `src/hooks/install.ts:380-403`, `src/hooks/install.ts:443-470`\n- Actual execution of `npm install --ignore-scripts`: `src/infra/install-package-dir.ts:176-199`\n\n**Vulnerability Trigger Flow**\n\n1. The user executes one of the following commands:\n\n   - `openclaw plugins install \u003cpath-or-spec\u003e`\n   - `openclaw hooks install \u003cpath-or-spec\u003e`\n2. If the argument is a local directory or local archive, OpenClaw navigates to the local installation path.\n3. OpenClaw copies the source directory to a temporary `stageDir`. See `src/infra/install-package-dir.ts:176-177`.\n4. If `dependencies` are present in `package.json`, OpenClaw executes the following in `stageDir`:\n\n```\nnpm install --omit=dev --silent --ignore-scripts\n```\n\nSee `src/infra/install-package-dir.ts:188-199`.\n\n5. npm reads the project-level `.npmrc` file in this directory.  Official documentation: [`.npmrc`](https://docs.npmjs.com/cli/v11/configuring-npm/npmrc/)\n6. If `.npmrc` is set to `git=\u003cpath to malicious program\u003e` and there is a git dependency in the dependency tree, npm will invoke that `git` program when resolving the dependency.  Official documentation: [`npm config git`](https://docs.npmjs.com/cli/v11/using-npm/config/)  Git dependency documentation: [`package.json`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/)\n7. Consequently, an attacker can execute arbitrary local programs during the plugin/hook installation phase without waiting for the plugin or hook to be loaded later.\n\n**Triggering Commands**\n\n- Plugin installation command:\n\n```\nopenclaw plugins install \u003cpath-or-spec\u003e\n```\n\n- Hook installation command:\n\n```\nopenclaw hooks install \u003cpath-or-spec\u003e\n```\n\nWhen `\u003cpath-or-spec\u003e` is a local directory or local archive, it will be resolved to the path used by the `npm install --omit=dev --silent --ignore-scripts` command mentioned above.\n\n### PoC\n\n\n\nCurrently, `testpoc/` is a minimal PoC directory used to verify that \u201cwhen installing local packages, OpenClaw enters the `npm install --ignore-scripts` path.\u201d It is divided into two core sections:\n\ntestpoc/pkg/\nPurpose: Simulates the local package directory installed by `openclaw plugins install ...` or `openclaw hooks install ...`\ntestpoc/repo/\nPurpose: Simulates a Git dependency repository within the npm dependency tree\nDirectory Structure\n\ntestpoc/\n\u251c\u2500 pkg/\n\u2502  \u251c\u2500 .npmrc\n\u2502  \u251c\u2500 package.json\n\u2502  \u2514\u2500 sample-hook/\n\u2502     \u251c\u2500 HOOK.md\n\u2502     \u2514\u2500 handler.js\n\u2514\u2500 repo/\n   \u251c\u2500 package.json\n   \u2514\u2500 .git/...\nFunction of Each Component\n\ntestpoc/pkg/.npmrc\n\nCurrent content:\ngit=calc.exe\nFunction: Overrides npm\u2019s Git executable configuration.\nMeaning: When npm encounters a git dependency during installation, it will not call the system git but will attempt to call the program specified here.\nThis is the core trigger point of this PoC. See testpoc/pkg/.npmrc:1\ntestpoc/pkg/package.json\n\nCurrently, this is a \u201cmixed-use\u201d manifest that includes both plugin and hook fields:\n{\n  \u201cname\u201d: \u201cprobe-host\u201d,\n  \u201cversion\u201d: \u201c1.0.0\u201d,\n  \u201cprivate\u201d: true,\n  \u201copenclaw\u201d: {\n    \u201cextensions\u201d: [\u201c./dist/index.js\u201d],\n    \u201chooks\u201d: [\u201c./sample-hook\u201d]\n  },\n  \u201cdependencies\u201d: {\n    \u201cprobe-git-dep\u201d: \u201cgit+file:///D:/AI Agent Source/OpenClaw/openclaw-2026.3.13-1/.testpoc/repo\u201d\n  }\n}\nIts functionality is divided into three layers:\nopenclaw.extensions: Allows it to be validated as a plugin package\nopenclaw.hooks: Enables it to be validated as a hook package\nThe Git URL in dependencies: Forces npm to enter the Git dependency resolution path during installation\nSee testpoc/pkg/package.json:1\ntestpoc/pkg/sample-hook/HOOK.md\n\nPurpose: To meet the minimum metadata requirements for a hook package.\nThis is the key file that allows `openclaw hooks install pkg` to pass the pre-check. See testpoc/pkg/sample-hook/HOOK.md:1\ntestpoc/pkg/sample-hook/handler.js\n\nCurrent content:\nexport default async function handler() {\n  return { ok: true };\n}\nPurpose: Meets the requirement that the hook directory must contain a handler entry file.\nIt is not a usage point in itself; its sole purpose is to allow OpenClaw to proceed to the dependency installation phase. See testpoc/pkg/sample-hook/handler.js:1\ntestpoc/repo/package.json\n\nCurrent content:\n{\u201cname\u201d:\u201cprobe-git-dep\u201d,\u2018version\u2019:\u201c1.0.0\u201d}\nPurpose: Serves as the minimum repository content corresponding to a Git dependency.\nThe focus is not on the repository code itself, but on the fact that \u201cit is a Git repository,\u201d allowing npm to perform Git-related operations on it. See testpoc/repo/package.json:1\ntestpoc/repo/.git/\n\nPurpose: Makes testpoc/repo/ a real Git repository rather than a regular directory.\nWhen npm resolves git+file://... When installing dependencies, this is treated as the Git source.\nHow the current PoC works\n\nIf installing via hooks:\n\nopenclaw hooks install testpoc/pkg\nThe trigger chain is:\n\nOpenClaw identifies testpoc/pkg as the local hook package path\nThrough pre-validation in openclaw.hooks, HOOK.md, and handler.js\nProceeds to src/infra/install-package-dir.ts:188-199\nExecutes:\nnpm install --omit=dev --silent --ignore-scripts\nnpm reads testpoc/pkg/.npmrc\nnpm processes the git dependency in package.json\nnpm attempts to call the git=calc.exe specified in .npmrc\n\n### Impact\nIt is best described as an installation-time local command execution / unsafe package-install configuration issue.\n\nMore precisely:\n\nOpenClaw installs local plugin and hook packs by running npm install --omit=dev --silent --ignore-scripts inside the staged package directory, see src/infra/install-package-dir.ts:188-199.\nIf that local package directory contains an attacker-controlled .npmrc, npm will still read it.\nIf .npmrc overrides npm\u2019s git executable and the package has a git dependency, npm can invoke the attacker-chosen program during install.\n\nWho is impacted\n\nUsers who run:\n\nopenclaw plugins install \u003clocal path/archive\u003e\nopenclaw hooks install \u003clocal path/archive\u003e\n\nAnd who install a malicious or untrusted local package that includes:\n\na controlled .npmrc\na git dependency\na runnable attacker-controlled git target on that platform\n\nThis should be treated as a security issue, not just \u201cmalicious plugin behavior,\u201d because the code execution happens during OpenClaw\u2019s install workflow, before the plugin or hook is ever loaded as trusted runtime code.\n\nThe important distinction is:\n\nA normal \u201ctrusted plugin\u201d case is: the operator installs a plugin, enables it, and later that plugin runs with plugin privileges.\nThis issue is different: OpenClaw\u2019s installer executes npm install --omit=dev --silent --ignore-scripts inside an attacker-controlled package directory, and npm still honors attacker-controlled project config from .npmrc.\n\nThat means an untrusted local plugin or hook package can influence the package manager itself and reach arbitrary program execution at install time, via npm\u2019s git setting and a git dependency, even though --ignore-scripts is present.\n\nWhy this matters from a security perspective:\n\nIt is install-time execution, not post-install trusted execution.\n\nThe execution is triggered by OpenClaw\u2019s installer in src/infra/install-package-dir.ts:188-199.\n\nThis occurs before the package is accepted as a trusted loaded plugin/hook in the usual sense.\n\nIt defeats an expected safety boundary.\n\nThe code explicitly uses --ignore-scripts, which strongly suggests an intent to make installation safer.\n\nBut the installer still allows attacker-controlled package-manager configuration from .npmrc to affect execution.\n\nSo the current mitigation is incomplete in a security-relevant way.\n\nThe dangerous input is part of a supported user flow.\n\nOpenClaw explicitly supports installing plugins and hook packs from local directories and archives:\n\nsrc/cli/plugins-cli.ts:199-255\nsrc/cli/hooks-cli.ts:573-676\n\nThat makes \u201cdownload a package/archive, then install it\u201d a realistic operator action, not an artificial lab setup.\n\nThe issue is broader than plugin trust.\n\nThe problem is not \u201cplugins can do bad things once trusted.\u201d\n\nThe problem is \u201cthe installer consumes attacker-controlled package-manager config before trust is established.\u201d\n\nThat is much closer to an unsafe install / supply-chain execution flaw than to ordinary trusted-plugin behavior.\n\nHooks are affected too.\n\nThe same installer path is used for hook packs, not only plugins.\n\nSo this is a shared install-surface issue, not an isolated plugin-runtime concern.",
  "id": "GHSA-m3mh-3mpg-37hw",
  "modified": "2026-04-10T19:45:21Z",
  "published": "2026-03-30T18:52:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-m3mh-3mpg-37hw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35641"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-code-execution-via-npmrc-in-local-plugin-hook-installation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has an Arbitrary Malicious Code Execution Vulnerability"
}

GHSA-MC43-3P9F-8C28

Vulnerability from github – Published: 2026-06-25 15:31 – Updated: 2026-06-25 15:31
VLAI
Details

A malicious authoritative server can send a crafted zone via the ZoneToCache function that leads to cache poisoning.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-33612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T13:16:38Z",
    "severity": "HIGH"
  },
  "details": "A malicious authoritative server can send a crafted zone via the ZoneToCache function that leads to cache poisoning.",
  "id": "GHSA-mc43-3p9f-8c28",
  "modified": "2026-06-25T15:31:59Z",
  "published": "2026-06-25T15:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33612"
    },
    {
      "type": "WEB",
      "url": "https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-powerdns-2026-08.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-141: Cache Poisoning

An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.

CAPEC-142: DNS Cache Poisoning

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

CAPEC-75: Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

← Back to the CWE list