Astro versions older than 6.1.10 employed AES‑GCM to encrypt server island props and slots, but the ciphertext was not tied to the specific component or parameter type. This allowed an attacker to replay a ciphertext created for a prop of one component as the slot value of another component, or vice versa. When the attacked component’s slot contains unsanitized raw HTML while the prop potentially contains user‑controlled content, this swap can inject malicious script into the page, resulting in cross‑site scripting. The vulnerability requires that both server islands share the same key name for a prop and a slot and that the attacker can fully control the value of the overlapping prop in a dynamically rendered page.

The issue affects any project built with the Astro framework using version 6.1.9 or earlier. Specifically, applications that employ server islands and where two distinct components share a key name for a prop and a slot are at risk. The vulnerability is not present once the project is upgraded to Astro 6.1.10 or later.

The CVSS score of 2.9 indicates a low overall severity. An EPSS score of <1% (0.00023) shows a very low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog, indicating no known public exploitation. However, exploitation is feasible if an application satisfies the conditions above and an attacker can inject a controlled value into the vulnerable prop. Successful replay can lead to client‑side XSS, which may be used for phishing, credential theft, or defacement. The risk is confined to the boundaries of the affected component, but any compromised content can affect all viewers of the page.