Astro is a web framework. Prior to version 5.15.8, a reflected XSS vulnerability is present when the server islands feature is used in the targeted application, regardless of what was intended by the component template(s). This issue has been patched in version 5.15.8.

Affected: npm: astro

## Summary After some research it appears that it is possible to obtain a reflected XSS when the server islands feature is used in the targeted application, **regardless of what was intended by the component template(s)**.

## Details Server islands run in their own isolated context outside of the page request and use the following pattern path to hydrate the page: `/_server-islands/[name]`. These paths can be called via GET or POST and use three parameters:

- `e`: component to export - `p`: the transmitted properties, encrypted - `s`: for the slots

Slots are placeholders for external HTML content, and therefore allow, by default, the injection of code if the component template supports it, nothing exceptional in principle, just a feature.

This is where it becomes problematic: it is possible, independently of the component template used, even if it is completely empty, to inject a slot containing an XSS payload, whose parent is a tag whose name is is the absolute path of the island file. Enabling reflected XSS on any application, regardless of the component templates used, provided that the server islands is used at least once.

**How ?**

By default, when a call is made to the endpoint `/_server-islands/[name]`, the value of the parameter `e` is `default`, pointing to a function exported by the component's module.

Upon further investigation, we find that two other values ​​are possible for the component export (param `e`) in a typical configuration: `url` and `file`. `f…