VDB
KO
MEDIUM

GHSA-f48w-9m4c-m7f5

Astro: XSS via unescaped spread attribute names in renderHTMLElement (incomplete fix for CVE-2026-54298)

Quick fix

GHSA-f48w-9m4c-m7f5 — astro: upgrade to the fixed version with the command below.

npm install astro@7.0.6

Details

## Summary

The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an `INVALID_ATTR_NAME_CHAR` guard to `addAttribute()` so that spread-prop attribute names containing `"' >/=` or whitespace are dropped. A second attribute-rendering path, `renderHTMLElement()` in `packages/astro/src/runtime/server/render/dom.ts`, has its own inline attribute loop that does not go through `addAttribute()` and was not updated. It interpolates the attribute name unescaped and only escapes the value, so untrusted prop keys spread onto a native-`HTMLElement`-subclass component can still break out of the attribute context, resulting in XSS.

## Details

`renderHTMLElement` builds attributes directly:

```js for (const attr in props) { attrHTML += ` ${attr}="${toAttributeString(await props[attr])}"`; } ```

The attribute name (`attr`) is interpolated raw; only the value is escaped via `toAttributeString`. By contrast, the hardened `addAttribute` in `util.ts` rejects invalid names:

```js if (INVALID_ATTR_NAME_CHAR.test(key)) { return ''; } // /[\s"'>/=]/ ```

`renderHTMLElement` is reached from `component.ts` when the component is a native `HTMLElement` subclass:

```js if (!renderer && typeof HTMLElement === 'function' && componentIsHTMLElement(Component)) { const output = await renderHTMLElement(result, Component, _props, slots); } ```

where `_props` carries spread props verbatim.

### Reachability

The branch only runs when `typeof HTMLElement === 'function'` at SSR time. In default Node SSR `HTMLElement` is `undefined`, so the branch is dead. It becomes reachable when the SSR runtime exposes a global `HTMLElement` (Deno, Bun with a DOM shim, or jsdom/happy-dom in Node) **and** a class extending `HTMLElement` is used directly as an Astro component that receives untrusted-keyed spread props.

## Proof of Concept

Given malicious spread props:

```js const maliciousProps = { 'onmouseover=alert(document.domain) x': 'y', 'x><script>alert(1)</script>': 'z', }; ```

- `addAttribute` (post-fix) → `<my-el></my-el>` (key stripped — safe) - `renderHTMLElement` → `<my-el onmouseover=alert(document.domain) x="y" x><script>alert(1)</script>="z"></my-el>` (handler + `<script>` injected — XSS)

Equivalent Astro template, served by an SSR runtime that defines a global `HTMLElement`:

```astro --- import MyElement from '../MyElement.js'; // class MyElement extends HTMLElement {} const userInput = Astro.url.searchParams; // untrusted keys --- <MyElement {...Object.fromEntries(userInput)} /> ```

## Impact

Cross-site scripting (CWE-79) via attribute-name breakout — the same vulnerability class as CVE-2026-54298, in a code path its fix did not cover. An attacker who controls the keys of an object spread onto a native-`HTMLElement`-subclass component can inject arbitrary event-handler attributes or sibling elements (including `<script>`) into the SSR output. Reachability is constrained by the runtime and component preconditions described above.

Are you affected?

Enter the version of the package you're using.

Affected packages

npm / astro
Introduced in: 0 Fixed in: 7.0.6
Fix npm install astro@7.0.6

References