CVE-2026-41067

What it actually does

Astro versions prior to 6.1.6 incorrectly sanitize values inserted into inline script blocks through the server-side rendering define:vars directive. The vulnerable logic only replaces the exact lowercase string </script>, but browsers and HTML parsers treat script closing tags case-insensitively and accept certain whitespace or slash variations before the closing bracket. If attacker-controlled data reaches define:vars, an attacker can prematurely terminate the intended script element using variants such as </Script>, </script >, or </script/>, then inject arbitrary HTML or JavaScript into the rendered page. The practical impact is reflected cross-site scripting with possible theft of browser-accessible data, session abuse, UI manipulation, credential phishing, or actions performed in the victim user's browser context.

Why it matters to the business

A vulnerable Astro application can be used to run attacker-supplied code in users' browsers if untrusted input is rendered through define:vars. This can lead to account compromise, fraudulent actions, data exposure visible to the user session, reputational damage, and loss of trust in the affected web application. The CVSS score is moderate and EPSS is currently very low with no known KEV listing or reported exploit maturity, but the issue is easy to exploit where vulnerable data flow exists and Astro is commonly used for public-facing web applications, so remediation should be prioritized for internet-facing sites and pages that render user-controllable content.

How an attack unfolds

An attacker first identifies an Astro-rendered page where user-controlled input is passed into the define:vars directive and emitted into an inline script during server-side rendering. Instead of using the exact </script> sequence that Astro attempted to sanitize, the attacker submits an HTML-equivalent variant such as </Script>, </script >, or </script/>. The browser interprets that sequence as the end of the script element, while the vulnerable sanitizer fails to neutralize it. The remainder of the payload is then parsed as attacker-controlled HTML or JavaScript, such as a new script block, event-handler HTML, or phishing markup. When a victim visits the affected page or follows a crafted link, the injected code executes in the context of the vulnerable site, allowing the attacker to read accessible page data, interact with the application as the victim, redirect the user, or exfiltrate tokens that are exposed to JavaScript.

How to fix it

Upgrade Astro to version 6.1.6 or later. Treat the framework upgrade as the primary fix because it addresses the incorrect script-closing-tag handling in defineScriptVars. After upgrading, rebuild and redeploy all affected applications and invalidate cached HTML where applicable. If immediate upgrade is not possible, avoid passing untrusted or user-controllable values to define:vars, encode dynamic values using safe JSON/script serialization primitives, and move untrusted data into contexts that are safely escaped by the framework. Add or tighten a Content Security Policy that disallows unsafe inline script where feasible, but do not rely on CSP as the sole fix. Review application code for define:vars usage and confirm that all values inserted into inline scripts are either trusted constants or correctly encoded.

How to confirm the fix worked

Confirm the deployed Astro version is 6.1.6 or later in package manifests, lockfiles, build logs, and deployed artifact metadata. Search source code for define:vars usage and verify that no untrusted request, form, CMS, profile, URL, or API-derived values are passed into inline script variables without safe encoding. In a non-production test environment, reproduce the issue against a representative affected page using benign payloads such as </Script><div id="astro-xss-test"></div>, </script ><div id="astro-xss-test"></div>, and </script/><div id="astro-xss-test"></div>; the payload should render as inert data and must not create new DOM elements or execute script after the fix. Validate browser behavior with automated tests that inspect the DOM and JavaScript execution, not only server response text. Also verify that stale pre-rendered pages, CDN caches, and static build outputs were regenerated after the upgrade.

Typical attack path

1. Find an Astro application running a version prior to 6.1.6.
2. Identify a page or route that uses define:vars to place dynamic data inside an inline script.
3. Determine whether any value reaching define:vars can be influenced by a URL parameter, form field, stored profile content, CMS content, API response, or other untrusted source.
4. Submit a payload that closes the script tag using a bypass form such as </Script>, </script >, or </script/>.
5. Append attacker-controlled HTML or JavaScript after the bypassed closing tag.
6. Cause a victim to load the affected page, either through direct browsing, a crafted link, stored content, or social engineering.
7. Execute JavaScript in the victim's browser under the vulnerable site's origin.
8. Use the browser context to steal accessible data, perform actions as the victim, alter page content, or redirect to attacker-controlled infrastructure.

How to detect it

To determine whether exploitation has already occurred, review HTTP access logs, application request logs, CDN logs, WAF events, reverse proxy logs, browser error telemetry, and CSP violation reports for payloads that include non-standard script closing tags followed by HTML or JavaScript. Focus on parameters, request bodies, headers, CMS content submissions, profile fields, search fields, comments, and any endpoint that can influence Astro-rendered output. Look for case variations of closing script tags, whitespace before the closing angle bracket, slash variants, URL-encoded equivalents, and payloads followed by tags such as <script>, <img onerror=...>, <svg onload=...>, <iframe>, or external JavaScript URLs. If CSP reporting is enabled, inspect reports for blocked inline script execution, unexpected script-src targets, or document-uri values tied to Astro routes using define:vars. For stored exploitation, inspect user-generated or CMS-managed content for injected script-closing sequences and compare recent content changes around suspicious requests. For confirmed suspicious payloads, correlate the requesting IPs, user agents, sessions, and subsequent victim page views, and review whether affected user accounts performed unusual actions shortly after viewing the injected page.

• </Script>
• </script >
• </script/>
• %3C%2FScript%3E
• %3C%2Fscript%20%3E
• %3C%2Fscript%2F%3E
• </SCRIPT>
• </script\t>
• </script\n>
• </script\r>
• define:vars
• astro-xss-test
• <svg onload=
• <img onerror=
• <script src=
• javascript:
• document.cookie
• localStorage
• sessionStorage
• fetch(
• navigator.sendBeacon
• new Image().src

What your security team should do

• Inventory Astro applications and identify any running versions prior to 6.1.6.
• Prioritize internet-facing applications and pages that render user-controlled or CMS-controlled content through define:vars.
• Upgrade Astro to 6.1.6 or later, rebuild, redeploy, and purge cached or pre-rendered vulnerable pages.
• Search repositories for define:vars and review each use for untrusted data flow into inline scripts.
• Add regression tests using mixed-case, whitespace, and slash variants of closing script tags to prevent reintroduction.
• Review CSP configuration and reduce reliance on inline scripts where practical.
• Hunt historical access logs, WAF logs, application logs, and CSP violation reports for script-closing-tag bypass attempts.
• Monitor for suspicious post-exploitation behavior such as unexpected outbound browser requests, credential phishing markup, unauthorized user actions, or unusual JavaScript error reports.
• Because EPSS is currently low and the CVE is not in the Known Exploited Vulnerabilities catalog, handle as a standard but time-bounded web application security fix unless exposed high-risk data flows are found.