GHSA-5339-HVWR-7582

Vulnerability from github – Published: 2026-03-12 14:19 – Updated: 2026-03-12 19:14
VLAI?
Summary
Unhead Vulnerable to Bypass of URI Scheme Sanitization in makeTagSafe via Case-Sensitivity
Details

The link.href check in makeTagSafe (safe.ts, line 68-71) uses String.includes(), which is case-sensitive:

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

useHeadSafe({
  link: [{
    rel: 'stylesheet',
    href: 'DATA:text/css,body{display:none}'
  }]
})

SSR output:

<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

if (key === 'href') {
  const lower = val.toLowerCase()
  if (lower.includes('javascript:') || lower.includes('data:')) {
    return
  }
  next[key] = val
}
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "unhead"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31873"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:19:25Z",
    "nvd_published_at": "2026-03-12T18:16:24Z",
    "severity": "LOW"
  },
  "details": "The `link.href` check in `makeTagSafe` (safe.ts, line 68-71) uses `String.includes()`, which is case-sensitive:\n\n```typescript\nif (key === \u0027href\u0027) {\n  if (val.includes(\u0027javascript:\u0027) || val.includes(\u0027data:\u0027)) {\n    return\n  }\n  next[key] = val\n}\n```\n\nBrowsers treat URI schemes case-insensitively. `DATA:text/css,...` is the same as `data:text/css,...` to the browser, but `\u0027DATA:...\u0027.includes(\u0027data:\u0027)` returns `false`.\n\n### PoC\n\n```javascript\nuseHeadSafe({\n  link: [{\n    rel: \u0027stylesheet\u0027,\n    href: \u0027DATA:text/css,body{display:none}\u0027\n  }]\n})\n```\n\nSSR output:\n\n```html\n\u003clink rel=\"stylesheet\" href=\"DATA:text/css,body{display:none}\"\u003e\n```\n\nThe 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.\n\nAny case variation works: `DATA:`, `Data:`, `dAtA:`, `JAVASCRIPT:`, etc.\n\n## Suggested fix\n\n```typescript\nif (key === \u0027href\u0027) {\n  const lower = val.toLowerCase()\n  if (lower.includes(\u0027javascript:\u0027) || lower.includes(\u0027data:\u0027)) {\n    return\n  }\n  next[key] = val\n}\n```",
  "id": "GHSA-5339-hvwr-7582",
  "modified": "2026-03-12T19:14:29Z",
  "published": "2026-03-12T14:19:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unjs/unhead/security/advisories/GHSA-5339-hvwr-7582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31873"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/unjs/unhead"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unjs/unhead/releases/tag/v2.1.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unhead Vulnerable to Bypass of URI Scheme Sanitization in makeTagSafe via Case-Sensitivity"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…