CVE-2026-45028

What it actually does

Astro versions before 6.1.10 encrypted server island props and slots with AES-GCM, but the authenticated encryption context did not bind the ciphertext to the intended component or to whether the value represented props versus slots. Because of that missing contextual binding, a valid encrypted value generated for one server island parameter could be replayed in another server island parameter position. In vulnerable applications, an attacker who can fully control a prop value on a dynamically rendered page may cause that encrypted prop value to be accepted as a slot value for a different server island component. Since slot content may be rendered as raw, unescaped HTML, this can result in cross-site scripting.

Why it matters to the business

Successful exploitation can allow an attacker to run malicious JavaScript in users’ browsers when they view affected pages. The likely consequences include session theft, account misuse, unauthorized actions performed as the victim, phishing content injected into trusted pages, and reputational damage. The issue is conditional: it requires use of Astro server islands, overlapping prop and slot key names across components, attacker control of the overlapping prop value, and dynamic rendering. The CVSS score is moderate, EPSS is currently very low and stable, and it is not listed in CISA KEV, but internet-facing applications using the vulnerable pattern should still prioritize upgrading because XSS can directly affect users and customers.

How an attack unfolds

An attacker first identifies an Astro application using server islands and looks for a dynamically rendered page where they can control a prop value. They then determine whether another server island component uses the same key name for a slot. The attacker submits or injects an HTML/JavaScript payload into the controllable prop value and causes the application to generate a legitimate encrypted server island props parameter for that value. Because vulnerable Astro versions do not cryptographically bind the encrypted value to the component name or parameter type, the attacker replays that encrypted props value in the slots parameter position for a different server island request. The server accepts the ciphertext as valid, decrypts it, and treats the attacker-controlled value as raw slot HTML. When a victim loads the affected page or server island output, the malicious script executes in the victim’s browser under the trusted origin of the application.

How to fix it

Upgrade Astro to version 6.1.10 or later. The fix binds encrypted server island values to their intended context so ciphertext generated for props cannot be replayed as slots, or across incompatible components. If an immediate upgrade is not possible, reduce exposure by disabling or avoiding server islands on routes that accept attacker-controlled input, ensuring that attacker-controllable values are never used in overlapping prop/slot key names, renaming keys so props and slots do not share names across server island components, and treating any user-controlled content rendered through slots as untrusted by sanitizing or escaping it before rendering. Also rotate any server-side encryption secrets used for server island payloads if there is evidence that crafted replay attempts were made, although key rotation alone does not correct the design flaw in vulnerable versions.

How to confirm the fix worked

Confirm dependency resolution shows Astro 6.1.10 or later in the deployed application, lockfile, and built artifact. Verify that no production build is using an older transitive or pinned Astro package. Review application code for server island usage and confirm that user-controlled values are not rendered as raw slot HTML. As a functional validation, reproduce the vulnerable pattern in a non-production test environment: generate an encrypted props value from a controllable prop and attempt to replay it as a slots value for another component. On fixed versions, the replay should fail or be rejected rather than rendering as slot content. Finally, run browser-based XSS regression tests against affected routes and verify that injected HTML or JavaScript is escaped, sanitized, rejected, or otherwise not executed.

Typical attack path

1. Find an Astro application running a version earlier than 6.1.10 that uses server islands.
2. Identify a dynamically rendered page where the attacker can fully control a prop value passed to a server island component.
3. Identify another server island component that uses the same key name for a slot parameter.
4. Place an XSS payload, such as a script-capable HTML fragment or event-handler payload, into the controllable prop value.
5. Obtain the legitimate encrypted props ciphertext generated by the application for that value.
6. Replay that ciphertext as a slots parameter for a compatible server island request or crafted page flow.
7. Cause a victim to load the affected page or server island response.
8. Execute attacker-controlled JavaScript in the victim’s browser in the context of the vulnerable site.

How to detect it

Detection should focus on web access logs, application request logs, CDN/WAF logs, client-side error telemetry, and any security monitoring that records requests to Astro server island endpoints. Look for requests to server island routes that contain both props and slots parameters, especially where a ciphertext-like value previously seen in a props parameter later appears in a slots parameter or appears against a different component route. Because the payload is encrypted, the malicious HTML or JavaScript may not be visible in server logs; correlation of parameter replay is more useful than searching only for script tags. Review logs for unusual spikes in server island requests, repeated long base64/base64url-like parameter values, requests with modified p and s query parameters, and XSS aftermath indicators such as browser console CSP violations, blocked inline script reports, unexpected outbound calls from user browsers, or anomalous authenticated actions immediately after page views. If application telemetry records decrypted server island values or render errors, search for raw HTML fragments, event-handler attributes, script-capable tags, and values rendered through slot paths where only props were expected. Threat intelligence currently does not indicate known KEV listing, ransomware use, named actor exploitation, or mature public exploit activity for this vulnerability, so detection is primarily behavior- and artifact-based.

• /_server-islands/
• ?p=
• &p=
• ?s=
• &s=
• p=.*&s=
• s=.*&p=
• <script
• </script>
• onerror=
• onload=
• onclick=
• javascript:
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• navigator.sendBeacon
• Content-Security-Policy-Report-Only
• violated-directive
• script-src

What your security team should do

• Inventory applications using Astro and identify those running versions earlier than 6.1.10.
• Prioritize internet-facing applications that use server islands, dynamic rendering, and user-controlled input passed into server island props.
• Upgrade Astro to 6.1.10 or later and redeploy affected applications.
• Search code for server island components that reuse the same key names between props and slots, especially where props can contain user-controlled values.
• Add regression tests for server island parameter replay and XSS payload rendering on dynamic pages.
• Review web access logs for unusual requests to server island endpoints containing both props and slots parameters, repeated ciphertext values, or parameter swapping patterns.
• If suspicious activity is found, review affected user sessions and browser-facing content for evidence of script injection, credential theft, or unauthorized actions.
• Keep content security policy controls enabled or strengthened to reduce XSS impact, but do not treat CSP as a substitute for upgrading.