CVE-2024-56140 Overview
CVE-2024-56140 is a Cross-Site Request Forgery (CSRF) protection bypass [CWE-352] affecting the Astro web framework. The flaw exists in Astro's CSRF middleware when security.checkOrigin is set to true. Attackers can bypass origin validation by appending a semicolon-delimited parameter to the Content-Type header, such as application/x-www-form-urlencoded; abc. Browsers still treat these values as simple requests and skip preflight validation. Additionally, the middleware fails to enforce checks when the Content-Type header is omitted entirely. The maintainers addressed the issue in version 4.16.17.
Critical Impact
Attackers can forge cross-origin state-changing requests against Astro applications that rely on the built-in CSRF middleware, leading to unauthorized actions performed in the victim's authenticated session.
Affected Products
- Astro framework versions prior to 4.16.17
- Node.js-based Astro deployments using security.checkOrigin: true
- Any Astro application relying on the built-in createOriginCheckMiddleware for CSRF protection
Discovery Timeline
- 2024-12-18 - CVE-2024-56140 published to the National Vulnerability Database (NVD)
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-56140
Vulnerability Analysis
The vulnerability resides in createOriginCheckMiddleware inside packages/astro/src/core/app/middlewares.ts. The middleware compared the incoming Content-Type header against an allowlist of form-like content types using an exact includes check. When a request supplied a value such as application/x-www-form-urlencoded; charset=UTF-8 or application/x-www-form-urlencoded; abc, the string no longer matched the allowlist. The middleware then skipped the origin comparison and forwarded the request to the handler.
Browsers still classify these Content-Type values as simple requests under the Cross-Origin Resource Sharing (CORS) specification. That means no preflight OPTIONS request is issued, and the browser sends the cross-origin POST, PUT, PATCH, or DELETE with the victim's cookies attached. A second bypass path exists when a request omits the Content-Type header entirely, because the middleware only executed its origin logic when the header was present.
Root Cause
The root cause is improper input parsing. The middleware performed a case-normalized string match on the entire header value instead of parsing the media type and stripping trailing parameters. Combined with the missing-header branch, both conditions allow requests to reach state-changing handlers without an origin check.
Attack Vector
An attacker hosts a malicious page that a signed-in Astro user visits. The page submits an HTML form or issues a fetch request to the target Astro application with a crafted Content-Type header containing a trailing parameter, or with no Content-Type at all. The browser attaches session cookies, the CSRF check is bypassed, and the handler processes the forged action.
// Patch from packages/astro/src/core/app/middlewares.ts
// Source: https://github.com/withastro/astro/commit/e7d14c374b9d45e27089994a4eb72186d05514de
export function createOriginCheckMiddleware(): MiddlewareHandler {
return defineMiddleware((context, next) => {
const { request, url } = context;
- const contentType = request.headers.get('content-type');
- if (contentType) {
- if (FORM_CONTENT_TYPES.includes(contentType.toLowerCase())) {
- const forbidden =
- (request.method === 'POST' ||
- request.method === 'PUT' ||
- request.method === 'PATCH' ||
- request.method === 'DELETE') &&
- request.headers.get('origin') !== url.origin;
- if (forbidden) {
- return new Response(`Cross-site ${request.method} form submissions are forbidden`, {
- status: 403,
- });
- }
+ if (request.method === "GET") {
+ return next();
+ }
+ const sameOrigin =
+ (request.method === 'POST' ||
+ request.method === 'PUT' ||
+ request.method === 'PATCH' ||
+ request.method === 'DELETE') &&
+ request.headers.get('origin') === url.origin;
+
+ const hasContentType = request.headers.has('content-type')
+ if (hasContentType) {
+ const formLikeHeader = hasFormLikeHeader(request.headers.get('content-type'));
The patched code inverts the logic: non-GET requests must match the origin, and the Content-Type value is parsed through hasFormLikeHeader rather than compared against a static list.
Detection Methods for CVE-2024-56140
Indicators of Compromise
- Inbound POST, PUT, PATCH, or DELETE requests with Content-Type values that include trailing parameters such as application/x-www-form-urlencoded; abc targeting Astro endpoints.
- State-changing requests to Astro applications that carry an Origin header not matching the application's own origin.
- State-changing requests missing the Content-Type header while still supplying session cookies.
Detection Strategies
- Inspect web server, reverse-proxy, or WAF logs for cross-origin write requests where Origin differs from Host and the Content-Type contains a semicolon-delimited parameter.
- Alert on non-GET requests to Astro routes that lack a Content-Type header, since well-behaved clients set the header for form and JSON submissions.
- Compare deployed Astro versions across your inventory against the fixed release 4.16.17 using Software Bill of Materials (SBOM) tooling.
Monitoring Recommendations
- Log full request headers on Astro endpoints that mutate data and retain them long enough to reconstruct CSRF attempts.
- Track referrer and origin distributions per authenticated route to surface anomalous cross-origin activity.
- Correlate authentication events with subsequent state-changing requests to identify sessions abused by a third-party origin.
How to Mitigate CVE-2024-56140
Immediate Actions Required
- Upgrade Astro to version 4.16.17 or later across all environments running the framework.
- Audit application dependency manifests (package.json, package-lock.json, pnpm-lock.yaml) to confirm no transitive pins hold Astro below the fixed version.
- Review recent access logs for suspicious cross-origin POST, PUT, PATCH, or DELETE traffic against sensitive endpoints.
Patch Information
The fix is committed in Astro commit e7d14c3 and shipped in Astro 4.16.17. See the GHSA-c4pw-33h3-35xw advisory for maintainer guidance. The patched middleware requires an origin match for all non-GET methods and parses the Content-Type media type before comparing it to the form-like allowlist.
Workarounds
- No official workarounds exist per the maintainer advisory; upgrading is the supported remediation.
- As a compensating control, enforce origin validation at a reverse proxy or WAF for state-changing methods until the upgrade is deployed.
- Require and validate a custom CSRF token header on sensitive endpoints, which forces browsers to issue a preflight and blocks cross-origin submissions.
# Upgrade Astro to the patched release
npm install astro@4.16.17
# Or with pnpm / yarn
pnpm add astro@4.16.17
yarn add astro@4.16.17
# Verify the installed version
npm ls astro
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

