LowGHSA-mh32-jxcr-mh9fCVE-2026-126361

Astro: XSS via attribute injection in dynamic tag names

Published 13 Nov 2026 · Updated 13 Nov 2026

Is your project on an affected astro?

Private repo? Upload its lockfile instead, or connect GitHub to check every repo.

Look after several JavaScript apps? Indie watches up to 15 repos, private ones too, for $5 a month. See Indie

Affected package

Affected
<7.4.5
Fixed in
7.4.5
Update to the fixed version for your release line, for example:npm install astro@7.4.5

Details

Summary

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.

Impact

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.

Affected versions

astro <= 7.4.4.

Patches

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.

Workarounds

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.

Credits

Reported by @uttej-badwane.

Is GHSA-mh32-jxcr-mh9f in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected astro, and gives you the command that fixes it.

More advisories for astro

  • MediumCVE-2026-126364Astro: Image endpoint in @astrojs/node can read files from a case-variant sibling of the output directory on case-sensitive filesystems · 13 Nov 2026
  • MediumCVE-2026-114128Astro: Reflected/Stored XSS via unescaped <script>/<style> tag content in JSX/MDX rendering · 22 Oct 2026
  • LowCVE-2026-114127Astro: Arbitrary CSS injection in Astro View Transitions · 22 Oct 2026
  • CriticalGHSA-26w7-cxv4-gfx2Astro: Remote code execution through AVIF image optimization · 8 Sept 2026
  • MediumCVE-2026-84376Astro: Authorization bypass from missing path-segment boundary check when stripping the configured base · 8 Sept 2026
  • MediumCVE-2026-73423Astro: composable `astro/hono` pipeline bypasses `security.checkOrigin` when `middleware()` is absent or misordered · 20 Jul 2026
All 31 advisories for astro

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.