astro

## Summary Astro's JSX and MDX rendering pipeline treated string children of `<script>` and `<style>` elements as trusted HTML. When a dynamic value was passed through a JSX expression, such as `<script>{value}</script>`, an attacker-controlled value containing `</script>` or `</style>` could terminate the element and inject arbitrary HTML and JavaScript. Other JSX expression contexts escaped dynamic strings automatically. This behavior was limited to `<script>` and `<style>` children rendered through Astro's `astro:jsx` renderer, including MDX components. ## Details The affected rendering

CVE: CVE-2026-114128

### Summary Astro's server-side View Transition CSS generator did not keep string animation properties within their generated CSS declarations. In an application that passes attacker-controlled data into an animation property such as `duration`, a value containing CSS delimiters could terminate the declaration and rule, then add attacker-selected CSS to the server-rendered page. The injected content remains inside the generated `<style>` element. It cannot terminate that element or inject HTML or JavaScript because Astro escapes `<` before emitting the stylesheet. ### Severity Exploitation

CVE: CVE-2026-114127

A vulnerability in `libheif`, used by the default Sharp image service in Astro, can lead to remote code execution when a malicious AVIF image is optimized. Projects are affected when an attacker can cause Astro to process an untrusted AVIF image. The fix was released in Astro 7.2.8, which requires Sharp 0.35.4.

## Summary Astro stripped a configured `base` path from request pathnames using a string-prefix check that did not verify a path-segment boundary. With `base: "/app"`, a request to `/appX/admin` was treated as being under the base and resolved internally to the `/admin` route, while middleware still observed the public pathname `/appX/admin`. Middleware that authorizes routes by inspecting `context.url.pathname` could therefore be bypassed. ## Impact An unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that: - Configure a non-root `base`. -

CVE: CVE-2026-84376

## Summary Astro's server-side View Transition CSS generator interpolates animation properties into an inline `<style>` element without escaping them for the CSS and HTML contexts. An attacker-controlled value passed to an animation property such as `duration` can contain a `</style>` sequence, terminate the generated style element, and inject arbitrary HTML or JavaScript. This is similar to GHSA-8hv8-536x-4wqp, but exploits a different injection point: unescaped View Transition animation values in a server-generated `<style>` element rather than an unescaped slot name in a hydration templa

CVE: CVE-2026-73422

### Summary When a `transition:persist`, `transition:scope`, or `transition:persist-props` directive is applied to a client-hydrated (`client:*`) component, Astro copied the directive value onto the rendered `<astro-island>` element **without HTML-escaping it**. If a developer reflects attacker-controlled input into one of these directives, an attacker can break out of the attribute and inject arbitrary HTML/JavaScript into the server-rendered output, resulting in reflected cross-site scripting (XSS). ### Severity Although a generic reflected XSS scores in the Medium range, exploitation her

CVE: CVE-2026-59727

## Summary In the composable `astro/hono` pipeline, the `security.checkOrigin` protection is only installed by the `middleware()` primitive. The `actions()` and `pages()` primitives each dispatch to user code independently, so a pipeline that mounts either primitive before (or without) `middleware()` will bypass the origin check for those requests. ## Details `security.checkOrigin` (default: `true`) is intended to reject cross-site `POST`/`PUT`/`PATCH`/`DELETE` form submissions. In the classic pipeline (`astro()` all-in-one), the check always runs because Astro injects a virtual middleware

CVE: CVE-2026-73423

## 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 c

CVE: CVE-2026-59729

# Astro 6.4.7 Authorization Bypass via Decode Iteration Limit and Rewrite Path Canonicalization Mismatch ## Summary Astro 6.4.7 appears to reintroduce a middleware authorization bypass pattern when a request path is encoded more deeply than the newly introduced iterative URL decoder's maximum decoding depth. The issue occurs because Astro performs authorization decisions on a partially decoded pathname after reaching a decoding iteration cap, while later route matching logic performs an additional `decodeURI()` operation and resolves the request to a protected route. As a result, middlewar

CVE: CVE-2026-59731

## Summary Astro SSR apps with prerendered error pages (`/404` or `/500` using `export const prerender = true`) fetch those pages over HTTP at runtime when an error occurs. The URL for this fetch is derived from `request.url`, which in turn gets its origin from the incoming `Host` header. When the `Host` header is not validated against `allowedDomains`, an attacker can point the fetch at an arbitrary host and read the response. ## Who is affected This affects SSR deployments that: 1. Have a prerendered 404 or 500 page 2. Use `createRequestFromNodeRequest` from `astro/app/node` with `app.re

CVE: CVE-2026-54299