CVE-2026-54298

What it actually does

Astro versions prior to 6.4.6 can render attacker-controlled object keys as raw HTML attribute names when server-side rendering components that use spread attributes such as {...props}. Because the attribute key is passed into HTML output without proper escaping, untrusted keys from sources such as APIs, CMS content, request parameters, or other user-controlled data can become executable attributes like onclick or onmousemove, or may alter the surrounding markup. The practical result is a reflected or stored cross-site scripting condition in affected Astro applications, depending on where the unsafe props originate and whether malicious values are persisted.

Why it matters to the business

Successful exploitation can let an attacker run JavaScript in a victim user's browser in the context of the affected site, potentially stealing session data accessible to scripts, performing actions as the user, defacing content, or redirecting users to phishing pages. The CVSS and EPSS values indicate lower currently observed exploitation likelihood, and this is not listed in CISA KEV, but public-facing sites that render untrusted CMS, API, or URL-derived properties through Astro spread attributes should still treat it as a priority because exploitation affects user trust and can lead to account compromise or fraud workflows.

How an attack unfolds

An attacker first identifies an Astro-rendered page or component that spreads an object onto an HTML element using syntax like {...props}. The attacker then finds a way to influence the keys of that object, for example through URL parameters, profile fields, CMS entries, API data, or other externally supplied content. Instead of supplying only normal attribute names, the attacker submits a crafted key such as an event-handler attribute or markup-breaking payload. When the vulnerable Astro server-side rendering pipeline processes the component, spreadAttributes iterates over the object keys and addAttribute places the unescaped key into the HTML response. When a victim loads or interacts with the resulting page, the injected browser-side script executes in the site origin. User interaction is generally required for event-handler payloads unless the attacker can inject an automatically firing element or attribute pattern.

How to fix it

Upgrade Astro to version 6.4.6 or later. Where exact package management is used, update the astro package and regenerate the lockfile, then redeploy all server-rendered applications built from the affected dependency. As defense in depth, audit components for spread attributes applied to native HTML elements and ensure object keys are never sourced directly from untrusted input. Validate attribute names against a strict allowlist before spreading props, especially when data originates from CMS entries, APIs, query parameters, form submissions, or user profiles. Avoid passing arbitrary objects into {...props}; map only expected properties explicitly. Consider enforcing a Content Security Policy that blocks inline script execution, though CSP should be treated as mitigation rather than a substitute for upgrading.

How to confirm the fix worked

Confirm that deployed applications resolve Astro to 6.4.6 or later using package metadata, lockfiles, build manifests, software composition analysis, or runtime container images. Search source code for spread attributes on HTML elements and review whether the spread object can contain untrusted keys. Test representative affected pages by supplying suspicious attribute names such as onclick or onmousemove through relevant input paths and verify they are not rendered as executable attributes in the HTML response. Rebuild and redeploy after upgrading, then confirm the rendered HTML encodes or rejects unsafe attribute keys. Validate that any CDN or edge cache has been purged so stale vulnerable SSR output is not served.

Typical attack path

1. Identify an Astro application running a vulnerable version prior to 6.4.6.
2. Locate a page or component that uses spread attributes on an HTML element, such as {...props}.
3. Determine whether any object keys included in the spread attributes can be influenced by untrusted input from a URL, API, CMS, form field, or stored content source.
4. Submit a crafted object key containing an HTML event handler or markup-breaking payload.
5. Cause the vulnerable server-side rendering path to generate HTML containing the attacker-controlled attribute or markup.
6. Lure or wait for a victim user to view or interact with the affected page.
7. Execute JavaScript in the victim's browser under the affected site's origin and use that access to steal data, perform actions, redirect the user, or modify page content.

How to detect it

Review HTTP access logs, CDN logs, WAF alerts, application logs, CMS audit logs, and API request logs for attempts to submit HTML event-handler names or markup-breaking payloads as parameter names, JSON object keys, form field names, or content property names. Because this issue is triggered by attacker-controlled attribute keys rather than only values, detection should inspect both request parameter names and JSON keys, not just values. Look for stored content updates that introduce keys resembling browser event handlers, script tags, iframe tags, SVG payloads, or quote/bracket sequences intended to escape an attribute context. In rendered-response telemetry, synthetic tests, or forensic captures, look for unexpected attributes such as onclick, onmousemove, onerror, onload, or autofocus on elements that should not contain them. If exploitation is suspected, correlate the malicious request or CMS update with subsequent victim page views, JavaScript error logs, CSP violation reports, unusual redirects, suspicious outbound browser requests, session anomalies, or unauthorized user actions. There are no public CVE-specific threat actors, KEV listing, or ransomware campaign links reported in the provided data, so detection should focus on generic XSS tradecraft against Astro SSR pages using spread attributes.

• onclick=
• onmousemove=
• onmouseover=
• onerror=
• onload=
• onfocus=
• autofocus onfocus=
• <script
• ></script>
• <img src=x onerror=
• <svg onload=
• ><script
• javascript:
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• new Image().src
• String.fromCharCode
• eval(
• atob(
• %3Cscript
• %3Cimg%20src%3Dx%20onerror
• %3Csvg%20onload
• on%5Cw+=

What your security team should do

• Upgrade all Astro applications to version 6.4.6 or later and redeploy from clean builds.
• Prioritize internet-facing applications, applications with authenticated user content, and applications that render CMS or API-provided objects through spread attributes.
• Run SCA across repositories and container images to identify Astro versions prior to 6.4.6.
• Ask engineering teams to review use of {...props} on native HTML elements and replace arbitrary spreading with explicit allowlisted attributes where untrusted data is involved.
• Add application tests that submit unsafe attribute-name payloads and fail builds if they are rendered into HTML responses.
• Deploy or tighten Content Security Policy to reduce the impact of injected inline JavaScript, while still completing the upgrade.
• Review web, WAF, CDN, and application logs for suspicious parameter names or stored content containing event-handler attributes or markup-breaking XSS payloads.
• If suspicious exploitation is found, investigate affected user sessions, forced redirects, unexpected account actions, and unauthorized content changes around the time of the malicious request.