CVE-2026-73422

Executive Summary

CVE-2026-73422 is a server-side HTML/CSS injection vulnerability in the Astro web framework, affecting all versions from 2.9.0 up to (but not including) 7.1.0. The flaw exists in Astro's View Transition CSS generator, which interpolates animation property values into an inline style element without escaping them for either CSS or HTML context. An attacker who can control a View Transition animation value (e.g., duration) can terminate the generated <style> element and inject arbitrary HTML or JavaScript that executes in the origin of the affected application. The issue is fixed in Astro 7.1.0; exploitation requires an on-demand or server-rendered route that reflects attacker-controlled data into a View Transition animation definition.

Technical Analysis

The vulnerability is located in packages/astro/src/runtime/server/transition.ts, the module responsible for generating server-side CSS for Astro's View Transitions. The vulnerable data flow is described as follows: the function renderTransition assembles a CSS style sheet and passes sheet.toString() into markHTMLString(). markHTMLString() is an Astro internal that marks a string as trusted, pre-sanitized HTML so it is emitted without further encoding. The string passed to it, however, contains serialized CSS properties produced by addAnimationProperty. That function serializes animation inputs — including duration (routed through toTimeValue()) and also easing, direction, delay, fillMode, and name — into CSS declarations without escaping the values for either the CSS grammar or the surrounding HTML document context.

There are two nested injection contexts that must be considered:

1. CSS context: A value inserted into an animation shorthand or a transition property is expected to conform to CSS token grammar. If the value contains characters such as ;, }, or ), it can break out of the property declaration and inject additional CSS rules.
2. HTML context: The produced CSS is wrapped in an inline <style> element. If the interpolated value contains a </style> sequence, it terminates the style element entirely. Everything that follows is parsed by the HTML parser, not the CSS parser, which enables injection of arbitrary HTML tags — most significantly <script> — leading to script execution in the page origin.

Because the final serialized string is fed through markHTMLString(), Astro's normal HTML escaping is bypassed, and the attacker-controlled substrings reach the response verbatim. No sanitization step is applied between addAnimationProperty's value serialization and renderTransition's emission of the style sheet.

The attack surface is any Astro application deployed with on-demand or server-rendered routes (e.g., using adapters for SSR or static-on-demand rendering) where user-controlled data — query parameters, form fields, cookies, or externally sourced CMS content — is used to construct the View Transition animation definition. The implicit trust in markHTMLString() is the root enabler: the framework treats the generated CSS as safe without validating the individual property values that were concatenated into it.

No CNA title, vendor advisory, or CVSS vector has been published for this CVE. The only patch signal is the OSV entry claiming the fix in version 7.1.0. Given the patch confidence of 2/4, the fix claim should be treated as credible but not yet independently verified. CISA KEV does not list this CVE, and EPSS places it at 0.00311 (23.8th percentile of exploited CVEs), indicating no observed in-the-wild exploitation as of the time of writing.

Exploitation Scenarios

No public PoC or exploit code exists for this CVE; the attack chain below is inferred from the vulnerability class and the data flow described in the NVD record.

Step 1 — Reconnaissance / target identification. An attacker fingerprints a target as an Astro application (e.g., via the <meta name="generator" content="Astro ..."> tag, /_astro/ static asset paths, or distinctive response headers). The attacker then enumerates routes that are server-rendered or on-demand rendered and that accept user-controlled input. Candidate inputs include search/filter parameters, pagination values, theme or UI customization parameters, or locale/region fields — anything that an application might plausibly bind into a View Transition animation definition to customize the transition experience (duration, easing, direction, delay, fill mode, or animation name).

Step 2 — Triggering the flaw. The attacker crafts a request in which the controlled parameter is set to a malicious animation value. Conceptually, the payload value must contain two parts: a valid (or at least parseable) CSS fragment to satisfy the serialization logic, followed by an HTML breakout sequence. The breakout sequence terminates the generated <style> element — e.g., including </style> — and begins an HTML context. Because the serialization path (duration through toTimeValue(), and the other properties handled by addAnimationProperty) does not escape quotes, angle brackets, or slash characters, no additional encoding bypass is required.

Step 3 — Payload / execution method. The injected HTML is served in the HTTP response body as part of the page's inline style output. A payload of the form 1s</style><script>/* attacker code */</script> would cause the browser to:

• parse the preceding CSS as a style element,
• close the style element at the injected </style>,
• execute the attacker's <script> block in the page's origin,
• continue rendering the remainder of the page normally.

The injection is delivered via the normal request/response cycle, so no client-side interaction beyond visiting the affected URL is required. If the value is stored (for example, from a CMS field or user profile attribute rendered into a transition), the attack becomes a stored XSS affecting any visitor of the page.

Step 4 — Post-exploitation impact. Script execution occurs in the affected application's origin, not a third-party origin. This gives the attacker access to:

• session tokens and authentication cookies for the victim,
• sensitive page data, including server-rendered data embedded in the DOM (which may include user PII, tokens, or internal configuration),
• authenticated actions available to the victim, allowing state-changing operations (profile modification, data deletion, privilege escalation if the victim is an administrator) via same-origin fetch/XHR requests.

The attacker can also use the compromised origin to pivot toward internal API endpoints that are reachable from the victim's browser.

Impact Assessment

This is a client-side code execution vulnerability with server-side injection mechanics, classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). The practical impact is equivalent to stored or reflected XSS in the application's own origin, which is generally considered high severity because it bypasses origin-based trust boundaries: any same-origin capability is available to the attacker.

Business impact. Astro is widely used for content-driven websites — marketing sites, documentation portals, blogs, and e-commerce storefronts. For content-only sites, the impact may be limited to defacement, SEO spam injection, or credential harvesting via injected login forms. For applications with authenticated user areas, administrative consoles, or payment flows (Astro is frequently paired with headless commerce backends), the impact escalates to account takeover, mass data exfiltration, and fraud. The script executes with the victim's privileges, so an admin browsing the site is sufficient for full administrative compromise.

Affected systems. All Astro deployments running versions 2.9.0 through 7.0.x that use server-side or on-demand rendering ("server" or "hybrid" output modes) and expose any route that binds external input into a View Transition animation property. Static-only Astro builds (fully pre-rendered with no server routes) are not exposed, because there is no server-side interpolation of runtime user input. Pre-rendered pages whose animation values originate from a CMS are still at risk if the CMS content is attacker-influenceable.

Blast radius. The vulnerability is reachable over the network without authentication for reflected scenarios, although it requires a victim to visit the crafted URL. Stored scenarios widen the blast radius to every authenticated page visitor. The CVSS vector is N/A — no score has been assigned by the CNA or NVD — so risk teams should assign severity based on the organization's deployment posture; the vulnerability class and origin-level impact typically justify a high-severity rating (CVSSv3 base range approximately 6.1–8.2 depending on scope and confidentiality/integrity impact).

Exploitation likelihood. EPSS is 0.00311 (23.8th percentile) — low. No exploit code, no Nuclei template, and no CISA KEV listing. However, the injection mechanism is well described in the advisory data, making exploit development straightforward once researchers study the transition.ts serialization logic. Given the patch is only claimed by a single source (OSV), there is a possibility that not all downstream packages and framework consumers are aware of it, widening the window of exposure.

Detection Guidance

Sigma Rule

title: CVE-2026-73422 Astro View Transition Injection Attempt
id: 8f2b1c4e-7d5a-4a1e-9c3f-0a6b2d8e1f44
status: experimental
description: Detects requests targeting Astro View Transition parameters that contain HTML breakout sequences indicative of CVE-2026-73422 exploitation.
logsource:
  category: webserver
  product: apache | nginx | iis
detection:
  selection_transition:
    cs-uri-query|contains:
      - "transition"
      - "animation"
      - "duration"
      - "easing"
      - "delay"
  selection_payload:
    cs-uri-query|contains:
      - "<script"
      - "</style>"
      - "<svg"
      - "%3Cscript"
      - "%3C%2Fstyle%3E"
      - "%3Csvg"
  condition: selection_transition and selection_payload
falsepositives:
  - Security scanners sending benign test payloads
  - Applications that legitimately use transition-related query parameters (unlikely to include angle brackets)
level: high
tags:
  - attack.t1190
  - cve.2026-73422

YARA Rule

rule CVE_2026_73422_Astro_View_Transition_XSS
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Detects HTML responses containing Astro server-side View Transition style elements terminated by an injected HTML or script payload"
        reference = "CVE-2026-73422"
        cwe = "CWE-79"
        date = "2026-01-01"

    strings:
        $anim_decl = /animation(-[a-zA-Z]+)?\s*:\s*[^;}<]*?/ nocase
        $style_end = "</style>"
        $script = /<script[\s>]/i nocase
        $svg = /<svg[\s>]/i nocase
        $iframe = /<iframe[\s>]/i nocase
        $onload = /onload\s*=/i nocase

    condition:
        any of ($anim_decl) and $style_end and 1 of ($script, $svg, $iframe, $onload)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-73422 Astro View Transition style injection in HTTP response body"; flow:established,to_client; content:"animation"; http.server_body; nocase; content:"</style>"; http.server_body; within:512; content:"<script"; http.server_body; within:1024; nocase; classtype:attempted-user; sid:7342201; rev:1; metadata:cve CVE-2026-73422; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-73422;)

The rule inspects server responses for the signature sequence: an inline animation CSS declaration followed shortly by a premature </style> closure and a <script> opener — the expected fingerprint of a successful injection through the View Transition serializer.

Elastic Detection

// EQL - Detect HTTP responses containing style-termination + script injection
any where
  http.response.body.content : "*animation*" and
  http.response.body.content : "*</style>*<script*"

// EQL - Detect requests with transition params carrying encoded breakout payloads
any where
  url.query : "*transition*" and
  (url.query : "*%3Cscript*" or url.query : "*%3C%2Fstyle%3E*" or url.query : "*</style>*")

Splunk SPL Query

index=weblog sourcetype=access_combined
| eval response_body_clean = lower(response_body)
| search response_body_clean="*</style><script*" OR response_body_clean="*</style><svg*"
| eval malicious=if(match(response_body_clean, "<\\/style>\\s*<(script|svg|iframe)"), "true", "false")
| where malicious="true"
| stats count min(_time) max(_time) by src_ip, uri, status, response_content_type
| sort - count

Alternative query for proxy logs when response bodies are not logged — detect the pre-exploit request pattern:

index=proxy OR index=weblog
| search uri_query="*transition*" AND (uri_query="*<script*" OR uri_query="*%3Cscript*" OR uri_query="*</style>*" OR uri_query="*%3C%2Fstyle%3E*")
| stats values(uri) by src_ip, user_agent

Wazuh OSSEC Rule

<group name="web,astro,cve_2026_73422,">
  <rule id="100734" level="12">
    <decoded_as>web-access</decoded_as>
    <match>transition</match>
    <regex>(?i).*(%3Cscript|%3C%2Fstyle%3E|&lt;script|&lt;/style&gt;|&lt;svg).*</regex>
    <description>CVE-2026-73422: Possible Astro View Transition CSS/HTML injection attempt (query contains script/style breakout payload)</description>
    <group>attack.t1190,pci_dss_6.5.7,gdpr_32,</group>
  </rule>

  <rule id="100735" level="14">
    <if_sid>100734</if_sid>
    <regex>(?i).*</style>\s*<script.*</regex>
    <description>CVE-2026-73422: Astro View Transition injection payload observed in server response body (likely successful exploitation)</description>
    <group>attack.t1190,pci_dss_6.5.7,gdpr_32,</group>
  </rule>
</group>

The first rule fires on request-side indicators (encoded or literal breakout sequences in query parameters bound to transition fields). The second rule escalates when the corresponding response contains a terminated </style> immediately followed by <script>, indicating the payload was reflected unescaped and executed in the page.

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. The fix in Astro 7.1.0 is asserted by a single source (OSV) and has not been independently confirmed via a vendor advisory, changelog entry, or diff review. Treat the patched version as authoritative only after verifying it against your own build, and monitor the Astro project for a formal security advisory.

1) Immediate mitigations (if upgrading is not possible today):

• Do not bind attacker-influenceable data (query parameters, form fields, cookies, CMS-authored content) into View Transition animation definitions. Hard-code animation values for duration, easing, direction, delay, fillMode, and name server-side, or restrict them to an allowlist of safe literal strings.
• Run a web application firewall (WAF) with a virtual patch that blocks </style>, <script, <svg, and their URL-encoded equivalents in any request parameter whose name suggests transition/animation binding. Note that WAF rules are a compensating control, not a fix.
• Deploy a strict Content-Security-Policy (CSP) with script-src 'self' 'nonce-<random>' and style-src 'self' 'unsafe-inline' (nonce-based script CSP substantially reduces the impact of XSS even if injection recurs).
• If the application has an admin or CMS content-authoring surface, enable HTTP-only and SameSite cookies to limit token theft via injected script.

2) Patch / upgrade steps:

• Upgrade Astro to version 7.1.0 or later in all applications that use server-side or on-demand rendering: npm install astro@^7.1.0 (or the equivalent for pnpm/yarn/bun).
• Audit the dependency tree for Astro as a transitive dependency (e.g., via content collections, integrations, or starter templates) and update accordingly.
• After upgrading, verify that server-rendered responses containing View Transition styles no longer reflect user-controlled values without escaping; regression-test routes that previously accepted animation parameters.
• Verify the OSV record for the package (commit 92382ea1d4e6400302b8375b4f701c10aa02043f) resolves to a fixed state in your lockfile, and re-run a dependency scanner to confirm CVE-2026-73422 is cleared.

3) Long-term hardening:

• Treat markHTMLString() and similar "trust me" HTML-marking primitives as a security boundary: enforce a policy that nothing derived from external input may flow into them without explicit context-aware escaping (CSS-escape and HTML-escape).
• Add a CI gate that fails builds when user-controlled data is passed into transition/animation helper functions in transition.ts or custom renderers.
• Subscribe to the Astro security advisory feed and the OSV database; re-evaluate patch confidence once the vendor publishes an advisory.
• For content-driven sites, prefer fully static pre-rendering where feasible, reducing the server-side attack surface for this class of vulnerability.

References

1. NVD — CVE-2026-73422 Detail: https://nvd.nist.gov/vuln/detail/CVE-2026-73422
2. OSV — CVE-2026-73422 Entry (patch source): https://osv.dev/vulnerability/CVE-2026-73422
3. Astro Project Repository (upstream fix tracking): https://github.com/withastro/astro
4. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-73422 is not listed.
5. ATT&CK Technique T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Threat actor / in-the-wild evidence: None known at the time of writing. No public PoC, no exploit code, no Nuclei template, and no CISA KEV listing. EPSS 0.00311 (23.8th percentile) indicates low observed exploitation activity. Organizations should still prioritize remediation because the technical mechanism is fully described in the advisory and weaponization is straightforward.