Astro: Reflected/Stored XSS via unescaped <script>/<style> tag content in JSX/MDX renderingGHSA-98hj-9722-w3j8
MEDIUMFix: withastro/astro#17896GHSA-98hj-9722-w3j8 is a medium-severity (CVSS 6.5) Cross-site Scripting (XSS) vulnerability in astro. A fix is available for astro — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-98hj-9722-w3j8 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
astronpmDescription
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 [email protected].
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | astro | all versions | 7.3.2npm install astro@7.3.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for astro, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update astro to 7.3.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-98hj-9722-w3j8 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is evaluated with a Moderate impact because exploitation requires user interaction to trigger script execution and depends on an application explicitly embedding untrusted dynamic values into script or style tags. Within Red Hat OpenShift AI environments, Astro is utilized as an internal dependency…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for GHSA-98hj-9722-w3j8 (CC BY 4.0)
Frequently Asked Questions
Is GHSA-98hj-9722-w3j8 in your dependencies?
Find it across npm, including transitive dependencies.