Update dependency astro to v7 [SECURITY] #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "renovate/npm-astro-vulnerability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
^4.2.8→^7.0.0DOM Clobbering Gadget found in astro's client-side router that leads to XSS
CVE-2024-47885 / GHSA-m85w-3h95-hcf9
More information
Details
Summary
A DOM Clobbering gadget has been discoverd in Astro's client-side router. It can lead to cross-site scripting (XSS) in websites enables Astro's client-side routing and has stored attacker-controlled scriptless HTML elements (i.e.,
iframetags with unsanitizednameattributes) on the destination pages.Details
Backgrounds
DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:
[1] https://scnps.co/papers/sp23_domclob.pdf
[2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/
Gadgets found in Astro
We identified a DOM Clobbering gadget in Astro's client-side routing module, specifically in the
<ViewTransitions />component. When integrated, this component introduces the following vulnerable code, which is executed during page transitions (e.g., clicking an<a>link):github.com/withastro/astro@7814a6cad1/packages/astro/src/transitions/router.ts (L135-L156)However, this implementation is vulnerable to a DOM Clobbering attack. The
document.scriptslookup can be shadowed by an attacker injected non-script HTML elements (e.g.,<img name="scripts"><img name="scripts">) via the browser's named DOM access mechanism. This manipulation allows an attacker to replace the intended script elements with an array of attacker-controlled scriptless HTML elements.The condition
script.dataset.astroExec === ''on line 138 can be bypassed because the attacker-controlled element does not have a data-astroExec attribute. Similarly, the check on line 134 can be bypassed as the element does not require atypeattribute.Finally, the
innerHTMLof an attacker-injected non-script HTML elements, which is plain text content before, will be set to the.innerHTMLof an script element that leads to XSS.PoC
Consider a web application using Astro as the framework with client-side routing enabled and allowing users to embed certain scriptless HTML elements (e.g.,
formoriframe). This can be done through a bunch of website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.For PoC website, please refer to:
https://stackblitz.com/edit/github-4xgj2d. Clicking the "about" button in the menu will trigger analert(1)from an attacker-injectedformelement.Impact
This vulnerability can result in cross-site scripting (XSS) attacks on websites that built with Astro that enable the client-side routing with
ViewTransitionsand store the user-inserted scriptless HTML tags without properly sanitizing thenameattributes on the page.Patch
We recommend replacing
document.scriptswithdocument.getElementsByTagName('script')for referring to script elements. This will mitigate the possibility of DOM Clobbering attacks leveraging thenameattribute.Reference
Similar issues for reference:
Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Atro CSRF Middleware Bypass (security.checkOrigin)
CVE-2024-56140 / GHSA-c4pw-33h3-35xw
More information
Details
Summary
A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks.
Details
When the
security.checkOriginconfiguration option is set totrue, Astro middleware will perform a CSRF check. (Source code:github.com/withastro/astro@6031962ab5/packages/astro/src/core/app/middlewares.ts)For example, with the following Astro configuration:
A request like the following would be blocked if made from a different origin:
However, a vulnerability exists that can bypass this security.
Pattern 1: Requests with a semicolon after the
Content-TypeA semicolon-delimited parameter is allowed after the type in
Content-Type.Web browsers will treat a
Content-Typesuch asapplication/x-www-form-urlencoded; abcas a simple request and will not perform preflight validation. In this case, CSRF is not blocked as expected.Pattern 2: Request without
Content-TypeheaderThe
Content-Typeheader is not required for a request. The following examples are sent without aContent-Typeheader, resulting in CSRF.Impact
Bypass CSRF protection implemented with CSRF middleware.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro's server source code is exposed to the public if sourcemaps are enabled
CVE-2024-56159 / GHSA-49w6-73cw-chjr
More information
Details
Summary
A bug in the build process allows any unauthenticated user to read parts of the server source code.
Details
During build, along with client assets such as css and font files, the sourcemap files for the server code are moved to a publicly-accessible folder.
github.com/withastro/astro@176fe9f113/packages/astro/src/core/build/static-build.ts (L139)Any outside party can read them with an unauthorized HTTP GET request to the same server hosting the rest of the website.
While some server files are hashed, making their access obscure, the files corresponding to the file system router (those in
src/pages) are predictably named. For example. the sourcemap file forsrc/pages/index.astrogets nameddist/client/pages/index.astro.mjs.map.PoC
Here is one example of an affected open-source website:
https://creatorsgarten.org/pages/index.astro.mjs.map
The file can be saved and opened using https://evanw.github.io/source-map-visualization/ to reconstruct the source code.
The above accurately mirrors the source code as seen in the repository: https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/index.astro
The above was found as the 4th result (and the first one on Astro 5.0+) when making the following search query on GitHub.com (search results link):
This vulnerability is the root cause of https://github.com/withastro/astro/issues/12703, which links to a simple stackblitz project demonstrating the vulnerability. Upon build, notice the contents of the
dist/client(referred to asconfig.build.clientin astro code) folder. All astro servers make the folder in question accessible to the public internet without any authentication. It contains.mapfiles corresponding to the code that runs on the server.Impact
All server-output (SSR) projects on Astro 5 versions v5.0.3 through v5.0.6 (inclusive), that have sourcemaps enabled, either directly or through an add-on such as sentry, are affected. The fix for server-output projects was released in astro@5.0.7.
Additionally, all static-output (SSG) projects built using Astro 4 versions 4.16.17 or older, or Astro 5 versions 5.0.7 or older, that have sourcemaps enabled are also affected. The fix for static-output projects was released in astro@5.0.8, and backported to Astro v4 in astro@4.16.18.
The immediate impact is limited to source code. Any secrets or environment variables are not exposed unless they are present verbatim in the source code.
There is no immediate loss of integrity within the the vulnerable server. However, it is possible to subsequently discover another vulnerability via the revealed source code .
There is no immediate impact to availability of the vulnerable server. However, the presence of an unsafe regular expression, for example, can quickly be exploited to subsequently compromise the availability.
Remediation
The fix for server-output projects was released in astro@5.0.7, and the fix for static-output projects was released in astro@5.0.8 and backported to Astro v4 in astro@4.16.18. Users are advised to update immediately if they are using sourcemaps or an integration that enables sourcemaps.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:L/SA:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro allows unauthorized third-party images in _image endpoint
CVE-2025-55303 / GHSA-xf8x-j4p2-f749
More information
Details
Summary
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
/_imageendpoint which returns optimized versions of images.The
/_imageendpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using theimage.domainsorimage.remotePatternsoptions).However, a bug in impacted versions of
astroallows 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
Create a new minimal Astro project (
astro@5.13.0).Configure it to use the Node adapter (
@astrojs/node@9.1.0— newer versions are not impacted):Build the site by running
astro build.Run the server, e.g. with
astro preview.Append
/_image?href=//placehold.co/600x400to the preview URL, e.g. http://localhost:4321/_image?href=//placehold.co/600x400The site will serve the image from the unauthorized
placehold.coorigin.Impact
Allows a non-authorized third-party to create URLs on an impacted site’s origin that serve unauthorized image content.
In the case of SVG images, this could include the risk of cross-site scripting (XSS) if a user followed a link to a maliciously crafted SVG.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro's
X-Forwarded-Hostis reflected without validationCVE-2025-61925 / GHSA-5ff5-9fcw-vg88
More information
Details
Summary
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-Hostheader that is reflected when using the recommendedAstro.urlproperty as there is no validation that the value is safe.Details
Astro reflects the value in
X-Forwarded-Hostin output when usingAstro.urlwithout any validation.It is common for web servers such as nginx to route requests via the
Hostheader, and forward on other request headers. As such as malicious request can be sent with both aHostheader and anX-Forwarded-Hostheader where the values do not match and theX-Forwarded-Hostheader is malicious. Astro will then return the malicious value.This could result in any usages of the
Astro.urlvalue in code being manipulated by a request. For example if a user follows guidance and usesAstro.urlfor a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.
Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.
PoC
nvm useyarn run buildnode ./dist/server/entry.mjscurl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'X-Forwarded-HostheaderFor the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above
curlrequest a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.Impact
This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro Development Server has Arbitrary Local File Read
CVE-2025-64757 / GHSA-x3h8-62x9-952g
More information
Details
Summary
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
/packages/astro/src/assets/endpoint/node.tsThe vulnerability exists in the Node.js image endpoint handler used during development mode. The endpoint accepts an
hrefparameter that specifies the path to an image file. In development mode, this parameter is processed without adequate path validation, allowing attackers to specify absolute file paths.Vulnerable Code Location:
packages/astro/src/assets/endpoint/node.tsThe development branch bypasses the security checks that exist in the production code path, which validates that file paths are within the allowed assets directory.
PoC
Attack Prerequisites
astro dev)/_imageendpoint must be accessible to the attackerExploit Steps
Start Astro Development Server:
Craft Malicious Request:
Example Attack:
Demonstration Results
Test Environment: macOS with Astro v5.13.3
Successful Exploitation:
/System/Library/Image Capture/Automatic Tasks/MakePDF.app/Contents/Resources/0blank.jpgstolen-image.pngcontaining processed system imageAttack Payload:
Server Response:
Impact
Confidentiality Impact: HIGH
Integrity Impact: NONE
Availability Impact: NONE
Affected Components
Primary Component
packages/astro/src/assets/endpoint/node.tsloadLocalImage()Secondary Components
packages/astro/src/assets/endpoint/generic.tsSeverity
CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro vulnerable to URL manipulation via headers, leading to middleware and CVE-2025-61925 bypass
CVE-2025-64525 / GHSA-hr2q-hp5q-x767
More information
Details
Summary
In impacted versions of Astro using on-demand rendering, request headers
x-forwarded-protoandx-forwarded-portare insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:x-forwarded-proto)x-forwarded-proto)Details
The
x-forwarded-protoandx-forwarded-portheaders are used without sanitization in two parts of the Astro server code. The most important is in thecreateRequest()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 construct URLs.
By injecting a payload at the protocol level during URL creation (via the
x-forwarded-protoheader), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn't affect (re)routing.If the following header value is injected when requesting the path
/ssr:The complete URL that will be created is:
https://www.malicious-url.com/?tank=://localhost/ssrAs a reminder, URLs are created like this:
The value is injected at the beginning of the string (
${protocol}), and ends with a query?tank=whose value is the rest of the string,://${hostnamePort}${req.url}.This way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.
The same logic applies to
x-forwarded-port, with a few differences.PoC
The PoC will be tested with a minimal repository:
2.16.0)/ssr), the other simulating an admin page (/admin) protected by a middlewareDownload the PoC repository
Middleware-based protected route bypass - x-forwarded-proto only
The middleware has been configured to protect the
/adminroute based on the official documentation:When tryint to access
/adminthe attacker is naturally redirected :The attackr can bypass the middleware path check using a malicious header value:
How is this possible?
Here, with the payload
x:admin?, the attacker can use the URL API parser to their advantage:x:is considered the protocol//, the parser considers there to be no authority, and everything before the?character is therefore considered part of the path:adminDuring a path-based middleware check, the path value begins with a
/:context.url.pathname === "/admin". However, this is not the case with this payload;context.url.pathname === "admin", the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.SSRF
As seen, the request URL is built from untrusted input via the
x-forwarded-protocolheader, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).Example of code reusing the "origin" URL, concatenating it to the API endpoint :
DoS via cache poisoning
If a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.
A
404cab be forced, causing an error on the/ssrpage like this :curl -i -H "x-forwarded-proto: https://localhost/vulnerable?" http://localhost:4321/ssrSame logic applies to
x-forwarded-port:curl -i -H "x-forwarded-port: /vulnerable?" http://localhost:4321/ssrHow is this possible?
The router sees the request for the path
/vulnerable, which does not exist, and therefore returns a404, while the potential CDN sees/ssrand can then cache the404response, consequently serving it to all users requesting the path/ssr.URL pollution
The exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.
If the value of
request.urlis used to create links within the page, this can lead to Stored XSS withx-forwarded-protoand the following value:results in the following URL object:
It is also possible to inject any link, always, if the value of
request.urlis used on the server side to create links.The attacker is more limited with
x-forwarded-portIf the value of
request.urlis used to create links within the page, this can lead to broken links, with the header and the following value:Example of an Astro website:
WAF bypass
For this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section "Exploitation - WAF bypass and escalations". This research deals with a similar case, the difference being that the vulnerable header was
x-forwarded-hostin their case:https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path
Note: A section addressing DoS attacks via cache poisoning using the same vector was also included there.
CVE-2025-61925 complete bypass
It is possible to completely bypass the vulnerability patch related to the
X-Forwarded-Hostheader.By sending
x-forwarded-hostwith an empty value, theforwardedHostnamevariable is assigned an empty string. Then, during the subsequent check, the condition fails becauseforwardedHostnamereturnsfalse, its value being an empty string:Consequently, the implemented check is bypassed. From this point on, since the request has no
host(its value being an empty string), the path value is retrieved by the URL parser to set it as thehost. This is because thehttp/httpsschemes are considered special schemes by the WHATWG URL Standard Specification, requiring anauthority state.From there, the following request on the example SSR application (astro repo) yields an SSRF:
empty
x-forwarded-host+ the targethostin the pathCredits
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro's middleware authentication checks based on url.pathname can be bypassed via url encoded values
CVE-2025-64765 / GHSA-ggxq-hp9w-j794
More information
Details
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 usescontext.url.pathnamewithout 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.
github.com/withastro/astro@ebc4b1cde8/packages/astro/src/vite-plugin-astro-server/request.ts (L40-L44)Consider an application having the following middleware code:
context.url.pathnameis validated , if it's equal to/admintheisAuthedproperty 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.pathnamereturns the raw version which is/%61adminwhile pathname which is used for routing/rendering/admin, this creates a path normalization mismatch.By sending the following request, it's possible to bypass the middleware check
Remediation
Ensure middleware context has the same normalized pathname value that Astro uses internally, because any difference could allow it to bypass such checks. In short maybe something like this
Thank you, let @Sudistark know if any more info is needed. Happy to help :)
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765
CVE-2025-66202 / GHSA-whqg-ppgf-wp8c
More information
Details
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
/%2561dmininstead 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 :
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro vulnerable to reflected XSS via the server islands feature
CVE-2025-64764 / GHSA-wrwg-2hg8-v723
More information
Details
Summary
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 exportp: the transmitted properties, encrypteds: for the slotsSlots 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 reflected XSS on any application, regardless of the component templates used, provided that the server islands is used at least once.
How ?
By default, when a call is made to the endpoint
/_server-islands/[name], the value of the parametereisdefault, pointing to a function exported by the component's module.Upon further investigation, we find that two other values are possible for the component export (param
e) in a typical configuration:urlandfile.filereturns a string value corresponding to the absolute path of the island file. Since the value is of typestring, it fulfills the following condition and leads to this code block:An entire template is created, completely independently, and then returned:
childSlots, the value provided to thesparameter, is injected as a childAll of this is done using
markHTMLString. This allows the injection of any XSS payload, even if the component template intended by the application is initially empty or does not provide for the use of slots.Proof of concept
For our Proof of Concept (PoC), we will use a minimal repository:
Download the PoC repository
Access the following URL and note the opening of the popup, demonstrating the reflected XSS:
http://localhost:4321/_server-islands/ServerTime?e=file&p=&s={%22zhero%22:%22%3Cimg%20src=x%20onerror=alert(0)%3E%22}
The value of the parameter
smust be in JSON format and the payload must be injected at the value level, not the key level :Despite the initial template being empty, it is created because the value of the URL parameter
eis set tofile, as explained earlier. The parent tag is the name of the component's internal route, and its child is the value of the key "zhero" (the name doesn't matter) of the URL parameters.Credits
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro Cloudflare adapter has Stored Cross-site Scripting vulnerability in /_image endpoint
CVE-2025-65019 / GHSA-fvmw-cj7j-j39q
More information
Details
Summary
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) usesisRemoteAllowed()from Astro’s internal helpers, which unconditionally allowsdata:URLs. When the endpoint receives a validdata:URL pointing to a malicious SVG containing JavaScript, and the Cloudflare-specific implementation performs a 302 redirect back to the originaldata: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)output: 'server'and the Cloudflare adapterRoot Cause – Vulnerable Code
File:
node_modules/@astrojs/internal-helpers/src/remote.tsIn the Cloudflare adapter, the
/_imageendpoint contains logic similar to:Because
data:URLs are considered “allowed”, a request such as:https://example.com/_image?href=data:image/svg+xml;base64,PHN2Zy... (base64-encoded malicious SVG)triggers a 302 redirect directly to the
data:URL, causing the browser to render and execute the malicious JavaScript inside the SVG.Proof of Concept (PoC)
output: 'server').(Base64 decodes to:
<svg xmlns="http://www.w3.org/2000/svg"><script>alert('zomasec')</script></svg>)data:URL → browser executes the<script>→alert()fires.Impact
image.domains/image.remotePatternsconfiguration entirelySafe vs Vulnerable Behavior
Other Astro adapters (Node, Vercel, etc.) typically proxy and rasterize SVGs, stripping JavaScript. The Cloudflare adapter currently redirects to remote resources (including
data:URLs), making it uniquely vulnerable.References
data:URL bypass in WordPress: CVE-2025-2575Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Remote allowlist bypass via unanchored matchPathname wildcard
CVE-2026-33769 / GHSA-g735-7g2w-hh3f
More information
Details
Summary
This issue concerns Astro's
remotePatternspath 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
hrefis parsed intotransform.srcand validated viaisRemoteAllowed():Source:
github.com/withastro/astro@e0f1a2b3e4/packages/astro/src/assets/endpoint/generic.ts (L43-L56)isRemoteAllowed()checks eachremotePatternviamatchPattern():Source:
github.com/withastro/astro@e0f1a2b3e4/packages/internal-helpers/src/remote.ts (L15-L21)The vulnerable logic in
matchPathname()usesreplace()without anchoring the prefix for/*patterns:Source:
github.com/withastro/astro@e0f1a2b3e4/packages/internal-helpers/src/remote.ts (L85-L99)Vulnerable code flow:
isRemoteAllowed()evaluatesremotePatternsfor a requested URL.matchPathname()handlespathname: "/img/*"using.replace()on the URL path./evil/img/secretincorrectly matches because/img/is removed even when it's not at the start.PoC
The PoC starts a local attacker server and configures remotePatterns to allow only
/img/*. It then requests the image endpoint with two URLs: an allowed path and a bypass path with/img/in the middle. Both requests returned the SVG payload, showing the path restriction was bypassed.Vulnerable config
Affected pages
This PoC targets the
/_imageendpoint directly; no additional pages are required.PoC Code
Attacker server
PoC Steps
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:PReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: XSS in define:vars via incomplete tag sanitization
CVE-2026-41067 / GHSA-j687-52p2-xcff
More information
Details
Summary
The
defineScriptVarsfunction in Astro's server-side rendering pipeline uses a case-sensitive regex/<\/script>/gto sanitize values injected into inline<script>tags via thedefine:varsdirective. 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
defineScriptVarsatpackages/astro/src/runtime/server/render/util.ts:42-53:This function is called from
renderElementatutil.ts:172-174when a<script>element hasdefine:vars:The regex
/<\/script>/gfails to match three classes of closing script tags that HTML parsers accept per the HTML specification §13.2.6.4:</Script>,</SCRIPT>,</sCrIpT>— HTML tag names are case-insensitive but the regex has noiflag.>:</script >,</script\t>,</script\n>— after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace.</script/>— the tokenizer enters "self-closing start tag" state on/.JSON.stringify()does not escape<,>, or/characters, so all these payloads pass through serialization unchanged.Execution flow: User-controlled input (e.g.,
Astro.url.searchParams) → assigned to a variable → passed viadefine:varson a<script>tag →renderElement→defineScriptVars→ incomplete sanitization → injected into<script>block in HTML response → browser closes the script element early → attacker-controlled HTML parsed and executed.PoC
Step 1: Create an SSR Astro page (
src/pages/index.astro):Step 2: Ensure SSR is enabled in
astro.config.mjs:Step 3: Start the dev server and visit:
Step 4: View the HTML source. The output contains:
The browser's HTML parser matches
</Script>case-insensitively, closing the script block. The<img onerror=alert(document.cookie)>is then parsed as HTML and the JavaScript inonerrorexecutes.Alternative bypass payloads:
Impact
An attacker can execute arbitrary JavaScript in the context of a victim's browser session on any SSR Astro application that passes request-derived data to
define:varson a<script>tag. This is a documented and expected usage pattern in Astro.Exploitation enables:
document.cookie)The vulnerability affects all Astro versions that support
define:varsand is exploitable in any SSR deployment where user input reaches adefine:varsscript variable.Recommended Fix
Replace the case-sensitive exact-match regex with a comprehensive escape that covers all HTML parser edge cases. The simplest correct fix is to escape all
<characters in the JSON output:This is the standard approach used by frameworks like Next.js and Rails. Replacing every
<with\u003cis safe inside JSON string contexts (JavaScript treats\u003cas<at runtime) and eliminates all possible</script>variants including case variations, whitespace, and self-closing forms.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Server island encrypted parameters vulnerable to cross-component replay
CVE-2026-45028 / GHSA-xr5h-phrj-8vxv
More information
Details
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:
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 data (AAD). Each ciphertext now includes context like
props:IslandNameorslots:IslandName, so encrypted data for one component cannot be replayed against a different component, and encrypted props cannot be reused as slots.References
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:PReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Reflected XSS via unescaped slot name
CVE-2026-50146 / GHSA-8hv8-536x-4wqp
More information
Details
Summary
When a component uses a
client:*directive, Astro inserts named slot content into adata-astro-templateattribute 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:376I 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.mjssrc/pages/index.astrosrc/components/Wrapper.jsxPayload:
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!--
This will render in html.
Fix
I suggest leveraging the existing escape function on the slot name.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Host header SSRF in prerendered error page fetch
CVE-2026-54299 / GHSA-2pvr-wf23-7pc7
More information
Details
Summary
Astro SSR apps with prerendered error pages (
/404or/500usingexport const prerender = true) fetch those pages over HTTP at runtime when an error occurs. The URL for this fetch is derived fromrequest.url, which in turn gets its origin from the incomingHostheader. When theHostheader is not validated againstallowedDomains, an attacker can point the fetch at an arbitrary host and read the response.Who is affected
This affects SSR deployments that:
createRequestFromNodeRequestfromastro/app/nodewithapp.render()without overridingprerenderedErrorPageFetch— this includes custom servers built on the public API and third-party adaptersNot affected:
@astrojs/node>= 9.5.4 (reads error pages from disk)@astrojs/cloudflare(uses the ASSETS binding)How it works
createRequestFromNodeRequestbuildsrequest.urlfrom the rawHost/:authorityheader. TheallowedDomainsoption is accepted but only gatesX-Forwarded-For— it does not constrain the URL origin. (The publiccreateRequestdoes fall back tolocalhostfor unvalidated hosts; this internal builder did not.)When
app.render()encounters a 404 or 500 with a prerendered error route,default-handler.tsconstructs the error page URL using the origin fromrequest.urland fetches it viaprerenderedErrorPageFetch, which defaults to globalfetch. The response body is served to the client.An attacker sends a request with
Host: attacker-host:port, triggers an error (e.g., requesting a nonexistent path for a 404), and receives the response from the attacker-controlled host reflected back.Remediation
The error page fetch origin is now validated against
allowedDomainsbefore use. When the host is validated, the original origin is preserved. Otherwise, it falls back tolocalhost. The fetch is also wrapped in a try/catch so that connection failures degrade gracefully to a plain error response.Credit
5ud0 / Tarmo Technologies
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: XSS via Unescaped Attribute Names in Spread Props
CVE-2026-54298 / GHSA-jrpj-wcv7-9fh9
More information
Details
Summary
The
spreadAttributesfunction in Astro's server-side rendering pipeline iterates over object keys and passes them directly toaddAttribute, 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 likeonmousemove,onclick, or break out of the attribute context entirely to inject new elements.Details
The vulnerable function is
addAttributeatpackages/astro/src/runtime/server/render/util.ts:81-141:This function is called from
spreadAttributesatpackages/astro/src/runtime/server/index.ts:91-92:The
toAttributeStringfunction escapes the attribute value, but the attribute namekeyis 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.Execution flow: User controlled object keys (from API, CMS, URL params) are spread onto element via
{...props}. The compiler generatesspreadAttributes(props)which iterates withObject.entries()and callsaddAttribute(value, key). The key is interpolated as` ${key}="${escapedValue}"`. A malicious key breaks attribute context, resulting in XSS.POC
Create an SSR Astro page (
src/pages/index.astro):Enable SSR in
astro.config.mjs(for URL based demo):Note: SSR is not required for the vulnerability to exist. In static builds (default), the attack vector is compromised data sources at build time (API, CMS, database). SSR simply makes the PoC easier to demonstrate via URL parameters.
Start the dev server and visit:
URL encoded:
View the HTML source. The output contains:
The key
x" onmousemove="alert(document.cookie)" ybreaks out of the attribute context. Moving the mouse over the div executes the JavaScript.Impact
An attacker can execute arbitrary JavaScript in the context of a victim's browser session on any Astro application that spreads object props from untrusted sources onto HTML elements. This is a common pattern when integrating with external APIs or CMS systems. Exploitation enables session hijacking via cookie theft, credential theft by injecting fake login forms or keyloggers, defacement of the rendered page, and redirection to attacker controlled domains.
The vulnerability affects all Astro versions that support spread syntax on HTML elements and is exploitable in SSR, SSG (if build time data is compromised), and hybrid deployments.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Cross-site scripting via unescaped transition:* directive values on hydrated islands
CVE-2026-59727 / GHSA-7pw4-f3q4-r2p2
More information
Details
Summary
When a
transition:persist,transition:scope, ortransition:persist-propsdirective 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 is HTML-escaped before serialization — theattrs,props, andoptsassignments all pass throughescapeHTML(). The transition directives, however, were copied verbatim:The
<astro-island>element is serialized viarenderElement('astro-island', island, false)withshouldEscape=false, andtoAttributeString()returns the value unchanged in that mode. As a result there is no downstream re-escaping, and the raw directive value reaches the HTML response. This is the same output sink previously addressed for slot names in GHSA-8hv8-536x-4wqp.The affected directives are:
data-astro-transition-scope(transition:scope)data-astro-transition-persist(transition:persist)data-astro-transition-persist-props(transition:persist-props)Note that
transition:persistis typedboolean | string, so passing a string value is a supported use of the API.Proof of Concept
A component that reflects a query parameter into a transition directive:
Request:
Rendered output (before the fix):
The
"closes the attribute and the injected<img onerror=…>executes in the victim's browser.Impact
Reflected XSS. An attacker who can induce a victim to visit a crafted URL can execute arbitrary script in the victim's session on the origin, subject to the requirement that the target application reflects untrusted input into one of the affected transition directives.
Affected Versions
astro >= 3.10.0, < 7.0.4(introduced in 3.10.0, PR #7861).Patched Versions
astro >= 7.0.4. Fixed in PR #17212 by HTML-escaping transition directive values before they are rendered onto the island element.Workarounds
Do not pass untrusted or request-derived input into
transition:persist,transition:scope, ortransition:persist-props. If such input is required, HTML-escape or strictly validate it before passing it to the directive. Upgrading toastro@7.0.4or later removes the need for manual mitigation.Credits
Reported by @jlgore.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: XSS via unescaped spread attribute names in renderHTMLElement (incomplete fix for CVE-2026-54298)
CVE-2026-59729 / GHSA-f48w-9m4c-m7f5
More information
Details
Summary
The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an
INVALID_ATTR_NAME_CHARguard toaddAttribute()so that spread-prop attribute names containing"' >/=or whitespace are dropped. A second attribute-rendering path,renderHTMLElement()inpackages/astro/src/runtime/server/render/dom.ts, has its own inline attribute loop that does not go throughaddAttribute()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
renderHTMLElementbuilds attributes directly:The attribute name (
attr) is interpolated raw; only the value is escaped viatoAttributeString. By contrast, the hardenedaddAttributeinutil.tsrejects invalid names:renderHTMLElementis reached fromcomponent.tswhen the component is a nativeHTMLElementsubclass:where
_propscarries spread props verbatim.Reachability
The branch only runs when
typeof HTMLElement === 'function'at SSR time. In default Node SSRHTMLElementisundefined, so the branch is dead. It becomes reachable when the SSR runtime exposes a globalHTMLElement(Deno, Bun with a DOM shim, or jsdom/happy-dom in Node) and a class extendingHTMLElementis used directly as an Astro component that receives untrusted-keyed spread props.Proof of Concept
Given malicious spread props:
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: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.Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Reflected XSS via unescaped View Transition animation properties
CVE-2026-73422 / GHSA-4g3v-8h47-v7g6
More information
Details
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
durationcan 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.tsThe generated stylesheet is wrapped in a
<style>element and marked as HTML-safe:Animation properties are added to the stylesheet without escaping:
For string values,
toTimeValue()returns the input unchanged:As a result, a
durationvalue containing</style>can escape from the generated style element.Other
TransitionAnimationproperties, includingeasing,direction,delay,fillMode, andname, are serialized by the same animation builder. The following PoC only relies on the officialfade()helper and itsdurationoption.PoC
Using:
astro@7.0.9@astrojs/node@11.0.2astro.config.mjssrc/pages/index.astroPayload:
open:
The browser interprets
</style>as the end of the generated style element and executes the injected script. An alert dialog is displayed when the page is opened.Impact
An attacker who can control a View Transition animation value can execute arbitrary JavaScript in the origin of the affected Astro application.
The query-based reflected XSS scenario affects on-demand/server-rendered routes, such as:
output: "server";export const prerender = false;Successful exploitation may allow access to sensitive page data and authenticated actions available to the victim.
Suggested Fix
Animation values should be serialized using context-appropriate CSS escaping or validation before being added to the generated stylesheet.
Additionally, content inserted into a raw
<style>element must not be able to contain an HTML end-tag sequence such as</style>. The final generated CSS should be made safe for the HTML raw-text context before it is passed tomarkHTMLString().Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Authorization bypass from missing path-segment boundary check when stripping the configured base
CVE-2026-84376 / GHSA-376h-93r7-7g6f
More information
Details
Summary
Astro stripped a configured
basepath from request pathnames using a string-prefix check that did not verify a path-segment boundary. Withbase: "/app", a request to/appX/adminwas treated as being under the base and resolved internally to the/adminroute, while middleware still observed the public pathname/appX/admin. Middleware that authorizes routes by inspectingcontext.url.pathnamecould therefore be bypassed.Impact
An unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that:
base.context.url.pathname.Because routing and middleware resolved different effective pathnames, a request such as
/appX/admin(or other single-character extensions like/app2/adminor/app-/admin) reached the protected/adminroute without passing the middleware check that guards/app/admin. Astro's authentication guide demonstrates protecting routes in middleware viacontext.url.pathname, so this is a reasonable and expected pattern.Affected versions
astro<= 7.2.3.Patches
Fixed in
astro7.2.4. Base stripping now requires the pathname to equal the base without its trailing slash, or to be followed by a/, so a prefix that does not end on a path-segment boundary is no longer treated as being under the base. Routing andcontext.url.pathnamenow resolve the same pathname.Workarounds
Upgrade to
astro7.2.4 or later. As a mitigation before upgrading, avoid relying solely on prefix checks ofcontext.url.pathnamefor authorization, or reject requests whose pathname does not begin with the configured base followed by a path-segment boundary.Credits
Reported by @Ryoga-exe.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Astro: Remote code execution through AVIF image optimization
GHSA-26w7-cxv4-gfx2
More information
Details
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.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.
⚠️ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
The artifact failure details are included below:
File name: site/package-lock.json
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.