chore(deps-major): Update dependency astro to v5 [SECURITY] #11

renovate · 2024-12-21T17:53:44Z

Note: This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
astro (source)	`^2.10.15` → `^5.0.0`

GitHub Vulnerability Alerts

CVE-2024-56140

Summary

A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks.

Details

When the security.checkOrigin configuration option is set to true, Astro middleware will perform a CSRF check. (Source code: https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts)

For example, with the following Astro configuration:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

export default defineConfig({
	output: 'server',
	security: { checkOrigin: true },
	adapter: node({ mode: 'standalone' }),
});

A request like the following would be blocked if made from a different origin:

// fetch API or <form action="https://test.example.com/" method="POST">
fetch('https://test.example.com/', {
	method: 'POST',
	credentials: 'include',
	body: 'a=b',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
});
// => Cross-site POST form submissions are forbidden

However, a vulnerability exists that can bypass this security.

Pattern 1: Requests with a semicolon after the `Content-Type`

A semicolon-delimited parameter is allowed after the type in Content-Type.

Web browsers will treat a Content-Type such as application/x-www-form-urlencoded; abc as a simple request and will not perform preflight validation. In this case, CSRF is not blocked as expected.

fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: 'test',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded; abc' },
});
// => Server-side functions are executed (Response Code 200).

Pattern 2: Request without `Content-Type` header

The Content-Type header is not required for a request. The following examples are sent without a Content-Type header, resulting in CSRF.

// Pattern 2.1 Request without body
fetch('http://test.example.com', { method: 'POST', credentials: 'include' });

// Pattern 2.2 Blob object without type
fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: new Blob(['a=b'], {}),
});

Impact

Bypass CSRF protection implemented with CSRF middleware.

Note

Even with credentials: 'include', browsers may not send cookies due to third-party cookie blocking. This feature depends on the browser version and settings, and is for privacy protection, not as a CSRF measure.

CVE-2024-56159

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.
https://github.com/withastro/astro/blob/176fe9f113fd912f9b61e848b00bbcfecd6d5c2c/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 for src/pages/index.astro gets named dist/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):

path:astro.config.mjs @&#8203;sentry/astro

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 as config.build.client in astro code) folder. All astro servers make the folder in question accessible to the public internet without any authentication. It contains .map files 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.

Network attack vector.
Low attack complexity.
No privileges required.
No interaction required from an authorized user.
Scope is limited to first party. Although the source code of closed-source third-party software may also be exposed.

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.

CVE-2025-55303

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 /_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

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):

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

export default defineConfig({
	adapter: node({ mode: 'standalone' }),
});

Build the site by running astro build.
Run the server, e.g. with astro preview.
Append /_image?href=//placehold.co/600x400 to the preview URL, e.g. http://localhost:4321/_image?href=//placehold.co/600x400
The site will serve the image from the unauthorized placehold.co origin.

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.

CVE-2025-61925

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

Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server
nvm use
yarn run build
node ./dist/server/entry.mjs
curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'
Observe that the response reflects the malicious X-Forwarded-Host header

For 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 curl request 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.

CVE-2025-64757

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

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 specify absolute file paths.

Vulnerable Code Location: packages/astro/src/assets/endpoint/node.ts

// Vulnerable code in development mode
if (import.meta.env.DEV) {
    fileUrl = pathToFileURL(removeQueryString(replaceFileSystemReferences(src)));
} else {
    // Production has proper path validation
    // ... security checks omitted in dev mode
}

The 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 development server must be running (astro dev)
The /_image endpoint must be accessible to the attacker
Target image files must be readable by the Node.js process

Exploit Steps

Start Astro Development Server:

astro dev  # Typically runs on http://localhost:4321

Craft Malicious Request:

GET /_image?href=/[ABSOLUTE_PATH_TO_IMAGE]&w=100&h=100&f=png HTTP/1.1
Host: localhost:4321

Example Attack:

curl "http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png" -o stolen.png

Demonstration Results

Test Environment: macOS with Astro v5.13.3

Successful Exploitation:

Target: /System/Library/Image Capture/Automatic Tasks/MakePDF.app/Contents/Resources/0blank.jpg
Response: HTTP 200 OK, Content-Type: image/png
Exfiltration: 303 bytes (100x100 PNG)
File Created: stolen-image.png containing processed system image

Attack Payload:

http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png

Server Response:

Status: 200 OK
Content-Type: image/png
Content-Length: 303

Impact

Confidentiality Impact: HIGH

Scope: Any image file readable by the Node.js process
Exfiltration Method: Complete file contents via HTTP response (transformed to PNG)

Integrity Impact: NONE

The vulnerability only allows reading files, not modification

Availability Impact: NONE

No direct impact on system availability
Potential for resource exhaustion through repeated large image requests

Affected Components

Primary Component

File: packages/astro/src/assets/endpoint/node.ts
Function: loadLocalImage()
Lines: Development mode branch (~25-35)

Secondary Components

File: packages/astro/src/assets/endpoint/generic.ts
Impact: Uses different code path, not directly vulnerable
Note: Implements proper remote allowlist validation

CVE-2025-64764

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 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 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 parameter e is default, 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: url and file. file returns a string value corresponding to the absolute path of the island file. Since the value is of type string, it fulfills the following condition and leads to this code block:

An entire template is created, completely independently, and then returned:

the absolute path name is sanitized and then injected as the tag name
childSlots, the value provided to the s parameter, is injected as a child

All 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:

Latest Astro version at the time (5.15.6)
Use of Island servers, with a completely empty component, to demonstrate what we explained previously

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 s must 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 e is set to file, 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 parameter s.

Credits

Allam Rachid (zhero;)
Allam Yasser (inzo)

CVE-2025-64765

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

/** The main logic to route dev server requests to pages in Astro. */
export async function handleRequest({
    pipeline,
    routesList,
    controller,
    incomingRequest,
    incomingResponse,
}: HandleRequest) {
    const { config, loader } = pipeline;
    const origin = `${loader.isHttps() ? 'https' : 'http'}://${
        incomingRequest.headers[':authority'] ?? incomingRequest.headers.host
    }`;

    const url = new URL(origin + incomingRequest.url);
    let pathname: string;
    if (config.trailingSlash === 'never' && !incomingRequest.url) {
        pathname = '';
    } else {
        // We already have a middleware that checks if there's an incoming URL that has invalid URI, so it's safe
        // to not handle the error: packages/astro/src/vite-plugin-astro-server/base.ts
        pathname = decodeURI(url.pathname); // here this url is for routing/rendering
    }

    // Add config.base back to url before passing it to SSR
    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname; // this is used for middleware context

Consider an application having the following middleware code:

import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const isAuthed = false;  // simulate no auth
  if (context.url.pathname === "/admin" && !isAuthed) {
    return context.redirect("/");
  }
  return next();
});

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

GET /%61dmin HTTP/1.1
Host: localhost:3000

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

        pathname = decodeURI(url.pathname);
    }

    // Add config.base back to url before passing it to SSR
-    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname;
+    url.pathname = removeTrailingForwardSlash(config.base) + decodeURI(url.pathname);

Thank you, let @Sudistark know if any more info is needed. Happy to help :)

CVE-2025-65019

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) 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: node_modules/@astrojs/internal-helpers/src/remote.ts

export function isRemoteAllowed(src: string, ...): boolean {
  if (!URL.canParse(src)) {
    return false;
  }
  const url = new URL(src);

  // Data URLs are always allowed 
  if (url.protocol === 'data:') {
    return true;
  }

  // Non-http(s) protocols are never allowed
  if (!['http:', 'https:'].includes(url.protocol)) {
    return false;
  }
  // ... further http/https allow-list checks
}

In the Cloudflare adapter, the /_image endpoint contains logic similar to:

	const href = ctx.url.searchParams.get('href');
	if (!href) {
		// return error 
	}

	if (isRemotePath(href)) {
		if (isRemoteAllowed(href, imageConfig) === false) {
			// return error
		} else {
            //redirect to return the image 
			return Response.redirect(href, 302);
		}
	}

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)

Create a minimal Astro project with Cloudflare adapter (output: 'server').
Deploy to Cloudflare Pages or Workers.
Request the image endpoint with the following payload:

https://yoursite.com/_image?href=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ+YWxlcnQoJ3pvbWFzZWMnKTwvc2NyaXB0Pjwvc3ZnPg==

(Base64 decodes to: <svg xmlns="http://www.w3.org/2000/svg"><script>alert('zomasec')</script></svg>)

The endpoint returns a 302 redirect to the data: URL → browser executes the <script> → alert() fires.

Impact

Reflected/Strored XSS (depending on application usage)
Session hijacking (access to cookies, localStorage, etc.)
Account takeover when combined with CSRF
Data exfiltration to attacker-controlled servers
Bypasses image.domains / image.remotePatterns configuration entirely

Safe 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

Vulnerable function: https://github.com/withastro/astro/blob/main/packages/internal-helpers/src/remote.ts
Similar data: URL bypass in WordPress: CVE-2025-2575

CVE-2025-66202

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 :

if (containsEncodedCharacters(pathname)) {
            // Multi-level encoding detected - reject request
            return new Response(
                'Bad Request: Multi-level URL encoding is not allowed',
                {
                    status: 400,
                    headers: { 'Content-Type': 'text/plain' }
                }
            );
        }

Minor Changes

#14543 9b3241d Thanks @matthewp! - Adds two new adapter configuration options assetQueryParams and internalFetchHeaders to the Adapter API.

Official and community-built adapters can now use client.assetQueryParams to specify query parameters that should be appended to asset URLs (CSS, JavaScript, images, fonts, etc.). The query parameters are automatically appended to all generated asset URLs during the build process.

Adapters can also use client.internalFetchHeaders to specify headers that should be included in Astro's internal fetch calls (Actions, View Transitions, Server Islands, Prefetch).

This enables features like Netlify's skew protection, which requires the deploy ID to be sent with both internal requests and asset URLs to ensure client and server versions match during deployments.
#14489 add4277 Thanks @dev-shetty! - Adds a new Copy to Clipboard button to the error overlay stack trace.

When an error occurs in dev mode, you can now copy the stack trace with a single click to more easily share it in a bug report, a support thread, or with your favorite LLM.
#14564 5e7cebb Thanks @florian-lefebvre! - Updates astro add cloudflare to scaffold more configuration files

Running astro add cloudflare will now emit wrangler.jsonc and public/.assetsignore, allowing your Astro project to work out of the box as a worker.

Patch Changes

#14591 3e887ec Thanks @matthewp! - Adds TypeScript support for the components prop on MDX Content component when using await render(). Developers now get proper IntelliSense and type checking when passing custom components to override default MDX element rendering.
#14598 7b45c65 Thanks @delucis! - Reduces terminal text styling dependency size by switching from kleur to picocolors
#13826 8079482 Thanks @florian-lefebvre! - Adds the option to specify in the preload directive which weights, styles, or subsets to preload for a given font family when using the experimental Fonts API:
```
---
import { Font } from 'astro:assets';
---

<Font
  cssVariable="--font-roboto"
  preload={[{ subset: 'latin', style: 'normal' }, { weight: '400' }]}
/>
```
Variable weight font files will be preloaded if any weight within its range is requested. For example, a font file for font weight 100 900 will be included when 400 is specified in a preload object.

`v5.14.8`

Compare Source

Patch Changes

#14590 577d051 Thanks @matthewp! - Fixes image path resolution in content layer collections to support bare filenames. The image() helper now normalizes bare filenames like "cover.jpg" to relative paths "./cover.jpg" for consistent resolution behavior between markdown frontmatter and JSON content collections.

`v5.14.7`

Compare Source

Patch Changes

#14582 7958c6b Thanks @florian-lefebvre! - Fixes a regression that caused Actions to throw errors while loading
#14567 94500bb Thanks @matthewp! - Fixes the actions endpoint to return 404 for non-existent actions instead of throwing an unhandled error
#14566 946fe68 Thanks @matthewp! - Fixes handling malformed cookies gracefully by returning the unparsed value instead of throwing

When a cookie with an invalid value is present (e.g., containing invalid URI sequences), Astro.cookies.get() now returns the raw cookie value instead of throwing a URIError. This aligns with the behavior of the underlying cookie package and prevents crashes when manually-set or corrupted cookies are encountered.
#14142 73c5de9 Thanks @P4tt4te! - Updates handling of CSS for hydrated client components to prevent duplicates
#14576 2af62c6 Thanks @aprici7y! - Fixes a regression that caused Astro.site to always be undefined in getStaticPaths()

`v5.14.6`

Compare Source

Patch Changes

#14562 722bba0 Thanks @erbierc! - Fixes a bug where the behavior of the "muted" HTML attribute was inconsistent with that of other attributes.
#14538 51ebe6a Thanks @florian-lefebvre! - Improves how Actions are implemented
#14548 6cdade4 Thanks @ascorbic! - Removes support for the maxAge property in cacheHint objects returned by live loaders.

⚠️ Breaking change for experimental live content collections only

Feedback showed that this did not make sense to set at the loader level, since the loader does not know how long each individual entry should be cached for.

If your live loader returns cache hints with maxAge, you need to remove this property:

return {
  entries: [...],
  cacheHint: {
    tags: ['my-tag'],
-   maxAge: 60,
    lastModified: new Date(),
  },
};

#13520 a31edb8 Thanks @openscript! - Adds a new property routePattern available to GetStaticPathsOptions

This provides the original, dynamic segment definition in a routing file path (e.g

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

| datasource | package | from | to | | ---------- | ------- | ------- | ------ | | npm | astro | 2.10.15 | 5.15.9 |

renovate bot added the security label Dec 21, 2024

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from 91cac9d to 41a9671 Compare December 30, 2024 04:30

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from c110e4c to bcb547c Compare January 6, 2025 06:11

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 2 times, most recently from c708169 to 0bd6f24 Compare January 13, 2025 10:12

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from cc94025 to 425250e Compare January 27, 2025 04:57

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from 425250e to b7984e0 Compare January 27, 2025 10:13

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from b7984e0 to 071ebd3 Compare August 10, 2025 14:46

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from 071ebd3 to fb0452d Compare August 19, 2025 18:45

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from fb0452d to 5785fe3 Compare September 2, 2025 23:47

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from 5785fe3 to e95453c Compare September 25, 2025 20:31

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from e95453c to a0b21a2 Compare October 11, 2025 00:49

renovate bot changed the title ~~chore(deps-major): Update dependency astro to v4 [SECURITY]~~ chore(deps-major): Update dependency astro to v5 [SECURITY] Oct 11, 2025

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from a0b21a2 to 9101b52 Compare October 21, 2025 10:15

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 9 times, most recently from 709cedc to 721cd85 Compare November 17, 2025 09:14

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from 721cd85 to e6a3d78 Compare November 18, 2025 16:08

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 4 times, most recently from 1f0be23 to 8df57ec Compare November 24, 2025 10:40

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 4 times, most recently from 0511d33 to d43bb37 Compare December 8, 2025 04:54

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from 0107149 to 983215b Compare December 15, 2025 04:40

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from 7fa4767 to 6204881 Compare December 22, 2025 08:51

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 3 times, most recently from a0ee911 to e1e0e0d Compare December 31, 2025 17:07

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 4 times, most recently from 0b3e368 to ebbe651 Compare January 12, 2026 05:50

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 2 times, most recently from 66e26fc to b1a4d60 Compare January 19, 2026 04:38

renovate bot force-pushed the renovate/npm-astro-vulnerability branch 4 times, most recently from 0073cc3 to 9838ecb Compare January 26, 2026 04:25

chore(deps-major): Update dependency astro to v5 [SECURITY]

946ddd8

| datasource | package | from | to | | ---------- | ------- | ------- | ------ | | npm | astro | 2.10.15 | 5.15.9 |

renovate bot force-pushed the renovate/npm-astro-vulnerability branch from 9838ecb to 946ddd8 Compare January 26, 2026 10:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps-major): Update dependency astro to v5 [SECURITY] #11

chore(deps-major): Update dependency astro to v5 [SECURITY] #11

Uh oh!

renovate bot commented Dec 21, 2024 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

chore(deps-major): Update dependency astro to v5 [SECURITY] #11

Are you sure you want to change the base?

chore(deps-major): Update dependency astro to v5 [SECURITY] #11

Uh oh!

Conversation

renovate bot commented Dec 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Details

Pattern 1: Requests with a semicolon after the Content-Type

Pattern 2: Request without Content-Type header

Impact

Summary

Details

PoC

Impact

Remediation

Summary

Details

Proof of Concept

Impact

Summary

Details

PoC

Impact

Summary

Details

PoC

Attack Prerequisites

Exploit Steps

Demonstration Results

Impact

Confidentiality Impact: HIGH

Integrity Impact: NONE

Availability Impact: NONE

Affected Components

Primary Component

Secondary Components

Summary

Details

Proof of concept

Credits

Authentication Bypass via Double URL Encoding in Astro

Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794

Summary

Fix

Release Notes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

⚠️ Breaking change for experimental live content collections only

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

renovate bot commented Dec 21, 2024 •

edited

Loading

Pattern 1: Requests with a semicolon after the `Content-Type`

Pattern 2: Request without `Content-Type` header