CVE-2026-45028: Astro Framework XSS Vulnerability

CVE-2026-45028 Overview

CVE-2026-45028 affects the Astro web framework in versions prior to 6.1.10. The framework uses AES-GCM encryption to protect the confidentiality and integrity of server island props and slots parameters. The implementation did not bind ciphertext to its intended component or parameter type. An attacker can replay one component's encrypted props (p) value as another component's slots (s) value, or the reverse. Because slot values are rendered as raw unescaped HTML, this confusion enables Cross-Site Scripting (XSS) [CWE-79] in applications that meet specific conditions. The flaw is tracked as [CWE-323] (reusing a nonce/key in encryption) and is patched in Astro 6.1.10.

Critical Impact

Attackers with control over a prop value can swap encrypted parameters between server island components to inject unescaped HTML, producing reflected or stored XSS in dynamically rendered pages.

Affected Products

• Astro framework versions prior to 6.1.10
• Node.js-based deployments using server islands
• Applications with dynamically rendered pages sharing key names between props and slots

Discovery Timeline

• 2026-05-13 - CVE-2026-45028 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-45028

Vulnerability Analysis

Astro server islands serialize component inputs into two encrypted payloads: props (p), containing structured values that Astro escapes during rendering, and slots (s), containing raw HTML that is rendered without escaping. Both payloads are encrypted with the same site-wide AES-GCM key. The original encryptString function called crypto.subtle.encrypt with only a name and IV, omitting Additional Authenticated Data (AAD). Without AAD binding, a valid ciphertext is interchangeable across any field protected by the same key.

An attacker who controls a prop value on one server island component can capture its encrypted p value and submit it as the s value on a second component. The server decrypts the ciphertext successfully because the key matches, then renders the attacker-controlled string as raw HTML.

Root Cause

The root cause is missing authenticated context binding in the encryption routine. AES-GCM supports AAD that is verified during decryption but not stored in the ciphertext. Astro did not pass any context describing whether the ciphertext represented a prop, a slot, a component export, or which specific component owned it. Reused key material across semantically distinct fields produced a confused deputy condition.

Attack Vector

Exploitation requires four conditions: the application uses server islands, two different server island components share the same key name for a prop and a slot, the attacker controls the value of the overlapping prop, and the page is dynamically rendered. The attacker requests a page that encrypts the controlled prop, extracts the p ciphertext, then issues a server island request substituting that value as the s parameter for a different component.

// Patch in packages/astro/src/core/encryption.ts
/**
 * Using a CryptoKey, encrypt a string into a base64 string.
 * @param additionalData Optional authenticated context (e.g. "props:ComponentName") that is
 *   verified during decryption but not included in the ciphertext. Both sides must agree on
 *   the same value or decryption will fail.
 */
export async function encryptString(key: CryptoKey, raw: string, additionalData?: string) {
	const iv = crypto.getRandomValues(new Uint8Array(IV_LENGTH / 2));
	const data = encoder.encode(raw);
	const params: AesGcmParams = { name: ALGORITHM, iv };
	if (additionalData) {
		params.additionalData = encoder.encode(additionalData);
	}
	const buffer = await crypto.subtle.encrypt(params, key, data);
	// iv is 12, hex brings it to 24
	return encodeHexUpperCase(iv) + encodeBase64(new Uint8Array(buffer));
}

Source: GitHub Commit 3d82220

The fix adds an additionalData parameter that callers populate with contextual strings such as export:${componentId}, props:${componentId}, or slots:${componentId}. Decryption now fails when ciphertext from one context is replayed into another.

// Patch in packages/astro/src/core/server-islands/endpoint.ts
// Decrypt componentExport
let componentExport: string;
try {
	componentExport = await decryptString(key, data.encryptedComponentExport, `export:${componentId}`);
} catch (_e) {
	return badRequest('Encrypted componentExport value is invalid.');
}

Source: GitHub Commit 3d82220

Detection Methods for CVE-2026-45028

Indicators of Compromise

• Server island requests where the s parameter value matches a previously observed p parameter value from a different component request.
• Reflected HTML or script content in rendered server island responses where structured prop data was expected.
• Repeated server island POST requests targeting different componentId values with identical encrypted payload fragments.

Detection Strategies

• Inventory Astro deployments and identify any server island components that share field names between props and slots across the application.
• Inspect application logs for _server-islands/ endpoint requests carrying high-entropy s values that originated from prop-encoded sources.
• Add server-side telemetry that records the componentId, parameter type, and ciphertext fingerprint to support correlation across requests.

Monitoring Recommendations

• Alert on outbound responses containing script tags or event handler attributes from server island rendered output paths.
• Monitor for repeated 200 responses on dynamically rendered routes followed by client-side execution anomalies in Real User Monitoring.
• Track upgrades of the astro package across CI/CD pipelines to confirm production builds resolve to version 6.1.10 or later.

How to Mitigate CVE-2026-45028

Immediate Actions Required

• Upgrade Astro to version 6.1.10 or later in all production and staging environments.
• Audit server island components for shared key names between props and slots, and rename overlapping fields where possible.
• Rebuild and redeploy applications so the patched encryptString and decryptString calls take effect with AEAD context binding.

Patch Information

The fix is delivered in Astro 6.1.10. The change is implemented in GitHub Pull Request #16457 and merged in commit 3d82220a1549e699e34ed433f3846a919f4c02bd. Refer to the GitHub Security Advisory GHSA-xr5h-phrj-8vxv for the complete vendor disclosure. The patch adds an additionalData argument to AES-GCM encryption and decryption calls, binding ciphertext to its parameter type and component identifier.

Workarounds

• Switch dynamically rendered routes that use server islands to static pre-rendering until the patched version is deployed.
• Refactor components so no prop name overlaps with any slot name across the application's server island surface.
• Apply a Content Security Policy that disallows inline scripts to limit the impact of HTML injection during the remediation window.

# Upgrade Astro to the patched release
npm install astro@^6.1.10

# Verify the installed version
npm ls astro

# Rebuild the application so encryption call sites use the patched API
npm run build