Skip to main content
Vulnerability Database/CVE-2024-56140

CVE-2024-56140: Astro Framework CSRF Bypass Vulnerability

CVE-2024-56140 is a CSRF bypass flaw in Astro web framework that allows attackers to circumvent CSRF protection through Content-Type header manipulation. This post explains its impact, affected versions, and mitigation steps.

Published:

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.

typescript
// 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.
bash
# 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.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.