CVE-2026-126361

## Summary When a dynamic tag (`const Tag = ...; <Tag />`) resolves to a string, Astro renders it as a raw HTML element name. The name was filtered to remove characters that could inject attributes, but the filter did not handle `/`. Because HTML parsers treat `/` inside a tag as an attribute separator, a tag name such as `img/src/onerror=alert(1)` was rendered as an `<img>` element with an `onerror` attribute. The JSX renderer used for MDX did not filter string tag names at all. For example: ```astro --- const Tag = Astro.url.searchParams.get('as') ?? 'div'; --- <Tag>hello</Tag> ``` rendered `?as=img/src/onerror=alert(1)` as live HTML. ## Impact Reflected or stored cross-site scripting, but only in applications that use untrusted input (such as a request parameter or an uncontrolled CMS field) as all or part of an element name. Astro itself never derives element names from request data. Applications that let content choose an element should map that input to a fixed set of known tags. Letting untrusted input choose an element name is unsafe even with a correct filter, because it can still select elements such as `script` or `iframe`. ## Affected versions `astro` <= 7.4.4. ## Patches Fixed in `astro` 7.4.5. String tag names in `.astro` dynamic tags, JSX, and MDX now render only the leading valid element name, so characters such as `/` or `=` can no longer change the generated markup. Strings that do not start with a valid element name now throw an error. ## Workarounds Upgrade to `astro` 7.4.5 or later. Before upgrading, do not use untrusted input as an element name, or map it to a fixed set of known tags. ## Credits Reported by @uttej-badwane.