Skip to main content

Astro CVE-2026-59729

| EUVDEUVD-2026-49580 MEDIUM
Cross-site Scripting (XSS) (CWE-79)
2026-07-20 https://github.com/withastro/astro GHSA-f48w-9m4c-m7f5
5.1
CVSS 4.0 · Vendor: https://github.com/withastro/astro
Share

Severity by source

Vendor (https://github.com/withastro/astro) PRIMARY
5.1 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vuln.today AI
4.7 MEDIUM

AC:H reflects three simultaneous preconditions (non-default runtime, custom element component, untrusted key spread); S:C and UI:R reflect classic reflected XSS impacting the victim browser.

3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Primary rating from Vendor (https://github.com/withastro/astro).

CVSS VectorVendor: https://github.com/withastro/astro

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
A
Scope
X

Lifecycle Timeline

3
CVSS changed
Jul 27, 2026 - 20:22 NVD
5.1 (MEDIUM)
Source Code Evidence Fetched
Jul 20, 2026 - 23:47 vuln.today
Analysis Generated
Jul 20, 2026 - 23:47 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 2 npm packages depend on astro (1 direct, 1 indirect)

Ecosystem-wide dependent count for version 7.0.6.

DescriptionCVE.org

Summary

The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an INVALID_ATTR_NAME_CHAR guard to addAttribute() so that spread-prop attribute names containing "' >/= or whitespace are dropped. A second attribute-rendering path, renderHTMLElement() in packages/astro/src/runtime/server/render/dom.ts, has its own inline attribute loop that does not go through addAttribute() and was not updated. It interpolates the attribute name unescaped and only escapes the value, so untrusted prop keys spread onto a native-HTMLElement-subclass component can still break out of the attribute context, resulting in XSS.

Details

renderHTMLElement builds attributes directly:

js
for (const attr in props) {
  attrHTML += ` ${attr}="${toAttributeString(await props[attr])}"`;
}

The attribute name (attr) is interpolated raw; only the value is escaped via toAttributeString. By contrast, the hardened addAttribute in util.ts rejects invalid names:

js
if (INVALID_ATTR_NAME_CHAR.test(key)) { return ''; } // /[\s"'>/=]/

renderHTMLElement is reached from component.ts when the component is a native HTMLElement subclass:

js
if (!renderer && typeof HTMLElement === 'function' && componentIsHTMLElement(Component)) {
  const output = await renderHTMLElement(result, Component, _props, slots);
}

where _props carries spread props verbatim.

Reachability

The branch only runs when typeof HTMLElement === 'function' at SSR time. In default Node SSR HTMLElement is undefined, so the branch is dead. It becomes reachable when the SSR runtime exposes a global HTMLElement (Deno, Bun with a DOM shim, or jsdom/happy-dom in Node) and a class extending HTMLElement is used directly as an Astro component that receives untrusted-keyed spread props.

Proof of Concept

Given malicious spread props:

js
const maliciousProps = {
  'onmouseover=alert(document.domain) x': 'y',
  'x><script>alert(1)</script>': 'z',
};
  • addAttribute (post-fix) → <my-el></my-el> (key stripped - safe)
  • renderHTMLElement<my-el onmouseover=alert(document.domain) x="y" x><script>alert(1)</script>="z"></my-el> (handler + <script> injected - XSS)

Equivalent Astro template, served by an SSR runtime that defines a global HTMLElement:

astro
---
import MyElement from '../MyElement.js'; // class MyElement extends HTMLElement {}
const userInput = Astro.url.searchParams;  // untrusted keys
---
<MyElement {...Object.fromEntries(userInput)} />

Impact

Cross-site scripting (CWE-79) via attribute-name breakout - the same vulnerability class as CVE-2026-54298, in a code path its fix did not cover. An attacker who controls the keys of an object spread onto a native-HTMLElement-subclass component can inject arbitrary event-handler attributes or sibling elements (including <script>) into the SSR output. Reachability is constrained by the runtime and component preconditions described above.

AnalysisAI

XSS via unescaped attribute name interpolation in Astro's renderHTMLElement affects all versions of the npm package 'astro' prior to 7.0.6, representing an incomplete fix for CVE-2026-54298. The renderHTMLElement() function in dom.ts interpolates spread prop keys directly into HTML attribute names without sanitization - escaping only the value - allowing an attacker who controls prop key names on a native HTMLElement-subclass Astro component to inject event-handler attributes or sibling script elements into SSR-rendered output. Exploitation is constrained to SSR runtimes that expose a global HTMLElement (Deno, Bun with a DOM shim, jsdom/happy-dom in Node); standard Node.js SSR is not reachable. A proof of concept is publicly available in the GitHub advisory (GHSA-f48w-9m4c-m7f5). This CVE is not listed in CISA KEV.

Technical ContextAI

Astro (pkg:npm/astro) is a JavaScript web framework supporting SSR. The vulnerable code resides in packages/astro/src/runtime/server/render/dom.ts within renderHTMLElement(), which handles Astro components that are native HTMLElement subclasses (custom elements). The function builds attribute HTML via direct string interpolation: attrHTML += ${attr}="${toAttributeString(await props[attr])}" - where the prop key (attr) is inserted raw while only the value is sanitized by toAttributeString. CWE-79 (Improper Neutralization of Input During Web Page Generation) is the root cause class. The incomplete fix history is the key context: CVE-2026-54298 added an INVALID_ATTR_NAME_CHAR guard (/[\s"'>/=]/) to addAttribute() in util.ts, but renderHTMLElement() maintained its own parallel attribute loop that was never updated to apply the same guard. The fix for this CVE exports INVALID_ATTR_NAME_CHAR from util.ts and imports it into dom.ts, applying an identical guard inside the renderHTMLElement attribute loop with a continue statement to skip invalid keys. The routing into the vulnerable path occurs in component.ts when typeof HTMLElement === 'function' and componentIsHTMLElement(Component) returns true.

RemediationAI

Upgrade to astro@7.0.6 or later, which applies the INVALID_ATTR_NAME_CHAR guard to renderHTMLElement() in dom.ts - the same guard already in place in addAttribute() in util.ts. The patch is at https://github.com/withastro/astro/pull/17251, with the commit at https://github.com/withastro/astro/commit/5240e26c9dd91f9bc7140dcfacdb48d5a132830d and the release at https://github.com/withastro/astro/releases/tag/astro@7.0.6. If an immediate upgrade is not feasible and the deployment uses Deno, Bun with DOM shims, or jsdom/happy-dom, the most targeted workaround is to audit all Astro components that extend HTMLElement and replace unconstrained spread of user input (e.g., Object.fromEntries(Astro.url.searchParams)) with an explicit allowlist of known-safe prop key names before spreading - this eliminates the untrusted-key condition without requiring a runtime change. As a more aggressive workaround, removing or disabling HTMLElement-subclass Astro components in affected runtimes eliminates the attack surface entirely, at the cost of losing custom element SSR support. Standard Node.js SSR deployments without jsdom or happy-dom are not reachable via this path and can deprioritize the upgrade.

Share

CVE-2026-59729 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy