Astro: Reflected/Stored XSS via unescaped <script>/<style> tag content in JSX/MDX rendering
Published 22 Oct 2026 · Updated 22 Oct 2026
Affected package
- Affected
- <7.3.2
- Fixed in
- 7.3.2
npm install astro@7.3.2Details
Summary
Astro's JSX and MDX rendering pipeline treated string children of <script> and <style> elements as trusted HTML. When a dynamic value was passed through a JSX expression, such as <script>{value}</script>, an attacker-controlled value containing </script> or </style> could terminate the element and inject arbitrary HTML and JavaScript.
Other JSX expression contexts escaped dynamic strings automatically. This behavior was limited to <script> and <style> children rendered through Astro's astro:jsx renderer, including MDX components.
Details
The affected rendering paths marked all string children of <script> and <style> elements as safe HTML, without distinguishing literal content generated by the compiler from dynamic expression values. An application was vulnerable when attacker-controlled data, such as a query parameter or CMS field, was interpolated directly into one of these elements.
For example, a value containing </script><script>alert(1)</script> passed to <script>{value}</script> was emitted without escaping. The browser interpreted the first closing tag as markup and executed the injected script.
The fix preserves raw rendering for literal script and style content while escaping dynamic string children like other JSX expression values.
Impact
Affected applications could be vulnerable to reflected or stored cross-site scripting. Exploitation required an application to pass attacker-controlled data directly as a dynamic child of a <script> or <style> element in MDX or through the astro:jsx runtime. Successful exploitation allowed arbitrary JavaScript execution in the victim's browser under the application's origin.
Patches
This issue is patched in astro@7.3.2.
Workarounds
Do not interpolate untrusted dynamic values directly into <script> or <style> element children. Applications that cannot upgrade should validate and contextually encode these values before rendering them.
Credit
Reported by @RKasai127.
Is GHSA-98hj-9722-w3j8 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.
References
- Linkgithub.com/withastro/astro/security/advisories/GHSA-98hj-9722-w3j8
- Advisorynvd.nist.gov/vuln/detail/CVE-2026-114128
- Linkgithub.com/withastro/astro/pull/17896
- Linkgithub.com/withastro/astro/commit/a548223607b9bb146d5d90ddda495343f9a2a739
- Packagegithub.com/withastro/astro
- Linkgithub.com/withastro/astro/releases/tag/astro@7.3.2
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.