
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: <= 7.4.4
Patched in 7.4.5
Details
When a dynamic tag (const Tag = ...; <Tag />) resolves to a string, Astro renders it as a raw HTML element name. The name was filtered to remove characters that could inject attributes, but the filter did not handle /. Because HTML parsers treat / inside a tag as an attribute separator, a tag name such as img/src/onerror=alert(1) was rendered as an <img> element with an onerror attribute. The JSX renderer used for MDX did not filter string tag names at all.
For example:
---
const Tag = Astro.url.searchParams.get('as') ?? 'div';
---
<Tag>hello</Tag>
rendered ?as=img/src/onerror=alert(1) as live HTML.
Reflected or stored cross-site scripting, but only in applications that use untrusted input (such as a request parameter or an uncontrolled CMS field) as all or part of an element name. Astro itself never derives element names from request data.
Applications that let content choose an element should map that input to a fixed set of known tags. Letting untrusted input choose an element name is unsafe even with a correct filter, because it can still select elements such as script or iframe.
astro <= 7.4.4.
Fixed in astro 7.4.5. String tag names in .astro dynamic tags, JSX, and MDX now render only the leading valid element name, so characters such as / or = can no longer change the generated markup. Strings that do not start with a valid element name now throw an error.
Upgrade to astro 7.4.5 or later. Before upgrading, do not use untrusted input as an element name, or map it to a fixed set of known tags.
Reported by @uttej-badwane.
EPSS, exploit probability
Low0.32%
estimated chance of real-world exploitation in the next 30 days, higher than 24.8% of every CVE FIRST.org scores
Refreshed 11/14/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.