Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
29 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 paths marked all string children of <script and <style elements as safe HTML, without distinguishing literal content generated by the compiler from dynamic expression values. An application was vulnerable when attacker-controlled data, such as a query parameter or CMS field, was interpolated directly into one of these elements. For example, a value containing </script<scriptalert(1)</script passed to <script{value}</script was…
Recommended action: Upgrade to 7.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 requires an application to pass untrusted, request-derived, or user-controlled content directly into a transition animation value. This is an uncommon application pattern, and applications using static or otherwise trusted transition values are unaffected. The resulting capability is limited to CSS in the rendered document. The proof of concept does not demonstrate JavaScript execution, HTML injection, an…
Recommended action: Upgrade to 7.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 7.2.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. - Protect base-prefixed routes in middleware using context.url.pathname. Because routing and middleware resolved different effective pathnames, a request such as /appX/admin (or other single-character extensions like /app2/admin or /app-/admin) reached the protected /admin route without passing the middleware check that guards /app/admin. Astro's authentication guide demonstrates protecting routes in middleware via…
Recommended action: Upgrade to 7.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 module even when the user has no src/middleware.ts. In the composable astro/hono pipeline, the user assembles primitives manually. The check is only installed inside middleware() — so: - Mounting actions() before middleware() allows cross-origin form-encoded action requests to execute before the gate runs. The examples/advanced-routing example and the Cloudflare hono docs shipped this order. - Omitting middleware() entirely…
Recommended action: Upgrade to 7.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an INVALIDATTRNAMECHAR 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: 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: renderHTMLElement is reached from component.ts when the component is a native HTMLElement subclass: where props carries spread props verbatim. Reachability The branch only…
Recommended action: Upgrade to 7.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 here requires the application developer to have written a non-idiomatic pattern — passing untrusted, request-derived input directly into a transition directive. Astro applications that do not route untrusted input into these directives are unaffected. This mitigating precondition places the real-world severity at Low. Details In generateHydrateScript() (packages/astro/src/runtime/server/hydration.ts), every island property…
Recommended action: Upgrade to 7.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, middleware and route matching may operate on different pathname representations, enabling authorization bypasses under specific application patterns. Potential CWE: CWE-647 – Use of Non-Canonical URL Paths for Authorization Decisions --- Vulnerable Pattern Middleware authorization sees: Later rewrite route matching sees: This discrepancy allows a request that bypasses middleware checks to subsequently resolve to a…
Recommended action: Upgrade to 6.4.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 template. Like GHSA-8hv8-536x-4wqp, exploitation requires an application to pass attacker-controlled data to an Astro API. However, the value is subsequently inserted into the HTML response without context-appropriate escaping by Astro. Details packages/astro/src/runtime/server/transition.ts The generated stylesheet is wrapped in a <style element and marked as HTML-safe: Animation properties are added to the…
Recommended action: Upgrade to 7.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The spreadAttributes function in Astro's server-side rendering pipeline iterates over object keys and passes them directly to addAttribute, which interpolates the key into the HTML output without escaping. When a developer uses the spread syntax {...props} on an HTML element and the object keys come from an untrusted source (API, CMS, URL parameters), an attacker can inject arbitrary HTML attributes including event handlers like onmousemove, onclick, or break out of the attribute context entirely to inject new elements. Details The vulnerable function is addAttribute at packages/astro/src/runtime/server/render/util.ts:81-141: This function is called from spreadAttributes at packages/astro/src/runtime/server/index.ts:91-92: The toAttributeString function escapes the attribute value, but the attribute name key is never validated or escaped. An attacker can craft a JSON object with a key containing " characters to break out of the attribute context and inject event handlers.…
Recommended action: Upgrade to 6.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.render() without overriding prerenderedErrorPageFetch — this includes custom servers built on the public API and third-party adapters Not affected: - @astrojs/node = 9.5.4 (reads error pages from disk) - @astrojs/cloudflare (uses the ASSETS binding) - The dev server (renders error pages in-process) How it works createRequestFromNodeRequest builds request.url from the raw Host / :authority header. The allowedDomains option is…
Recommended action: Upgrade to 6.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a component uses a client: directive, Astro inserts named slot content into a data-astro-template attribute without HTML escaping the slot name allowing an attacker to break out of the attribute context and inject arbitrary HTML, resulting in reflected XSS during SSR. This is similar to GHSA-wrwg-2hg8-v723 but exploits a different injection point. Vulnerable Code packages/astro/src/runtime/server/render/component.ts:371:376 I found that key is interpolated directly into the attribute value without proper escaping. Proof of Concept For the PoC, I set up with a minimal repository with Astro 6.3.1, Node.js: v26.0.0. astro.config.mjs src/pages/index.astro src/components/Wrapper.jsx Payload: Accessing this URL will trigger the popup. http://localhost:4321/?tab=abc%22%3E%3C%2Ftemplate%3E%3C%2Fastro-island%3E%3Cimg+src%3Dx+onerror%3Dconfirm(document.domain)%3E%3C!-- <img width="1268" height="592" alt="image"…
Recommended action: Upgrade to 6.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Astro versions prior to 6.1.10 used AES-GCM encryption to protect the confidentiality and integrity of server island props and slots parameters, but did not bind the ciphertext to its intended component or parameter type. An attacker could replay one component's encrypted props (p) value as another component's slots (s) value, or vice versa. Since slots contain raw unescaped HTML while props may contain user-controlled values, this could lead to XSS in applications that meet all of the following conditions: - The application uses server islands - Two different server island components share the same key name for a prop and a slot - An attacker has full control over the value of the overlapping prop (requires a dynamically rendered page) These conditions are very unlikely to occur in real-world production applications. Patches This has been patched in astro@6.1.10. The fix binds each encrypted parameter to its target component and purpose using AES-GCM authenticated additional…
Recommended action: Upgrade to 6.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The defineScriptVars function in Astro's server-side rendering pipeline uses a case-sensitive regex /<\/script/g to sanitize values injected into inline <script tags via the define:vars directive. HTML parsers close <script elements case-insensitively and also accept whitespace or / before the closing , allowing an attacker to bypass the sanitization with payloads like </Script, </script , or </script/ and inject arbitrary HTML/JavaScript. Details The vulnerable function is defineScriptVars at packages/astro/src/runtime/server/render/util.ts:42-53: This function is called from renderElement at util.ts:172-174 when a <script element has define:vars: The regex /<\/script/g fails to match three classes of closing script tags that HTML parsers accept per the HTML specification §13.2.6.4: 1. Case variations: </Script, </SCRIPT, </sCrIpT — HTML tag names are case-insensitive but the regex has no i flag. 2. Whitespace before : </script , </script\t, </script\n — after the tag name,…
Recommended action: Upgrade to 6.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This issue concerns Astro's remotePatterns path enforcement for remote URLs used by server-side fetchers such as the image optimization endpoint. The path matching logic for / wildcards is unanchored, so a pathname that contains the allowed prefix later in the path can still match. As a result, an attacker can fetch paths outside the intended allowlisted prefix on an otherwise allowed host. In our PoC, both the allowed path and a bypass path returned 200 with the same SVG payload, confirming the bypass. Impact Attackers can fetch unintended remote resources on an allowlisted host via the image endpoint, expanding SSRF/data exposure beyond the configured path prefix. Description Taint flow: request - transform.src - isRemoteAllowed() - matchPattern() - matchPathname() User-controlled href is parsed into transform.src and validated via isRemoteAllowed(): Source:…
Recommended action: Upgrade to 5.18.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authentication Bypass via Double URL Encoding in Astro Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794 --- Summary A double URL encoding bypass allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like /%2561dmin instead of /%61dmin, attackers can still bypass authentication and access protected resources such as /admin, /api/internal, or any route protected by middleware pathname checks. Fix A more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :
Recommended action: Upgrade to 5.15.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Cross-Site Scripting (XSS) vulnerability exists in Astro when using the @astrojs/cloudflare adapter with output: 'server'. The built-in image optimization endpoint (/image) uses isRemoteAllowed() from Astro’s internal helpers, which unconditionally allows data: URLs. When the endpoint receives a valid data: URL pointing to a malicious SVG containing JavaScript, and the Cloudflare-specific implementation performs a 302 redirect back to the original data: URL, the browser directly executes the embedded JavaScript. This completely bypasses any domain allow-listing (image.domains / image.remotePatterns) and typical Content Security Policy mitigations. Affected Versions - @astrojs/cloudflare ≤ 12.6.10 (and likely all previous versions) - Astro ≥ 4.x when used with output: 'server' and the Cloudflare adapter Root Cause – Vulnerable Code File: nodemodules/@astrojs/internal-helpers/src/remote.ts In the Cloudflare adapter, the /image endpoint contains logic similar to: Because data:…
Recommended action: Upgrade to 5.15.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A mismatch exists between how Astro normalizes request paths for routing/rendering and how the application’s middleware reads the path for validation checks. Astro internally applies decodeURI() to determine which route to render, while the middleware uses context.url.pathname without applying the same normalization (decodeURI). This discrepancy may allow attackers to reach protected routes (e.g., /admin) using encoded path variants that pass routing but bypass validation checks. https://github.com/withastro/astro/blob/ebc4b1cde82c76076d5d673b5b70f94be2c066f3/packages/astro/src/vite-plugin-astro-server/request.ts#L40-L44 Consider an application having the following middleware code: context.url.pathname is validated , if it's equal to /admin the isAuthed property must be true for the next() method to be called. The same example can be found in the official docs https://docs.astro.build/en/guides/authentication/ context.url.pathname returns the raw version which is /%61admin while…
Recommended action: Upgrade to 5.15.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.15.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability has been identified in the Astro framework's development server that allows arbitrary local file read access through the image optimization endpoint. The vulnerability affects Astro development environments and allows remote attackers to read any image file accessible to the Node.js process on the host system. Details - Title: Arbitrary Local File Read in Astro Development Image Endpoint - Type: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - Component: /packages/astro/src/assets/endpoint/node.ts - Affected Versions: Astro v5.x development builds (confirmed v5.13.3) - Attack Vector: Network (HTTP GET request) - Authentication Required: None The vulnerability exists in the Node.js image endpoint handler used during development mode. The endpoint accepts an href parameter that specifies the path to an image file. In development mode, this parameter is processed without adequate path validation, allowing attackers to…
Recommended action: Upgrade to 5.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In impacted versions of Astro using on-demand rendering, request headers x-forwarded-proto and x-forwarded-port are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are: - Middleware-based protected route bypass (only via x-forwarded-proto) - DoS via cache poisoning (if a CDN is present) - SSRF (only via x-forwarded-proto) - URL pollution (potential SXSS, if a CDN is present) - WAF bypass Details The x-forwarded-proto and x-forwarded-port headers are used without sanitization in two parts of the Astro server code. The most important is in the createRequest() function. Any configuration, including the default one, is affected: https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97 https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121 These header values are then used directly to…
Recommended action: Upgrade to 5.15.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Reflected Cross-Site Scripting (XSS) vulnerability exists in Astro's development server error pages when the trailingSlash configuration option is used. An attacker can inject arbitrary JavaScript code that executes in the victim's browser context by crafting a malicious URL. While this vulnerability only affects the development server and not production builds, it could be exploited to compromise developer environments through social engineering or malicious links. Details Vulnerability Location https://github.com/withastro/astro/blob/5bc37fd5cade62f753aef66efdf40f982379029a/packages/astro/src/template/4xx.ts#L133-L149 Root Cause The vulnerability was introduced in commit 536175528 (PR #12994) , as part of a feature to "redirect trailing slashes on on-demand rendered pages." The feature added a helpful 404 error page in development mode to alert developers of trailing slash mismatches. Issue: The corrected variable, which is derived from the user-controlled pathname…
Recommended action: Upgrade to 5.15.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is a patch bypass of CVE-2025-58179 in commit 9ecf359. The fix blocks http://, https:// and //, but can be bypassed using backslashes (\) - the endpoint still issues a server-side fetch. PoC https://astro.build/image?href=\\raw.githubusercontent.com/projectdiscovery/nuclei-templates/refs/heads/main/helpers/payloads/retool-xss.svg&f=svg
Recommended action: Upgrade to 5.13.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe. Details Astro reflects the value in X-Forwarded-Host in output when using Astro.url without any validation. It is common for web servers such as nginx to route requests via the Host header, and forward on other request headers. As such as malicious request can be sent with both a Host header and an X-Forwarded-Host header where the values do not match and the X-Forwarded-Host header is malicious. Astro will then return the malicious value. This could result in any usages of the Astro.url value in code being manipulated by a request. For example if a user follows guidance and uses Astro.url for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could…
Recommended action: Upgrade to 5.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of astro, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served. Details On-demand rendered sites built with Astro include an /image endpoint which returns optimized versions of images. The /image endpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using the image.domains or image.remotePatterns options). However, a bug in impacted versions of astro allows an attacker to bypass the third-party domain restrictions by using a protocol-relative URL as the image source, e.g. /image?href=//example.com/image.png. Proof of Concept 1. Create a new minimal Astro project (astro@5.13.0). 2. Configure it to use the Node adapter (@astrojs/node@9.1.0 — newer versions are not impacted): 3. Build the site by running astro build. 4. Run the server, e.g. with astro preview. 5.…
Recommended action: Upgrade to 5.13.2 or 4.16.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.