GHSA-95h2-gj7x-gx9w: Unhead has a hasDangerousProtocol() bypass via leading-zero padded HTML entities in useHeadSafe()
##EVIDENCE| **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: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}` capWhen 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 AnalysisVulnerable code (`packages/unhead/src/plugins/safe.ts`, lines 10–11)Why the bypass worksThe 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 ReproduceEnvironment**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 projectStep 2 — Replace `pages/index.vue`Step 3 — Start the dev server and inspect SSR outputIn a separate terminal:Expected result (safe)Tags stripped entirely, or schemes rewritten to safe placeholder values.Actual result (vulnerable)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 clientSEO and analytics scripts that read canonical or icon link valuesApplication features that preview, validate, or forward link URLs into iframesDeveloper tooling that loads icon URLs for thumbnail generationChrome 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:Full PoC with cookie exfiltration beaconReplace `ADD-YOUR-WEBHOOK-URL-HERE` with a webhook.site URL before running.**Observed result:**`alert()` fires from inside the iframe's `data:` document contextWebhook receives a GET request with the cookie value and origin in the query stringPage source confirms `&#x000003A;` is present unescaped in the SSR-rendered `<link>` tagAll 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.Impact1. Broken security contractDevelopers 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 outputA 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 exploitabilityIf 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 FixRemove 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.**File:** `packages/unhead/src/plugins/safe.ts`, lines 10–11This 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 |
CVSS v3.1: 6.1