CVE-2026-41322: Astro Cache Poisoning Due To Incorrect Vulnerability
MODERATECVE-2026-41322 is a MODERATE (CVSS 5.3) cache poisoning due to incorrect vulnerability (CWE-525: Use of Web Browser Cache Containing Sensitive Information) affecting Astro libraries in the npm ecosystem. The issue involves cache poisoning due to incorrect error handling when if-match header is malformed. Remediation is available by upgrading affected packages to version 10.0.5.
CVE-2026-41322 at a Glance
Security Impact
CVSS: 5.3
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
How to Fix CVE-2026-41322
To remediate this vulnerability, upgrade all affected Astro dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
npm install @astrojs/node@10.0.5
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
npm ls @astrojs/node
How to Check if You Are Affected
To determine whether your Node.js application is affected by CVE-2026-41322, inspect your project dependencies using npm:
npm ls @astrojs/node
Analyze the terminal output to locate any version of Astro in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 10.0.5), your application is affected.
Note: The npm ls @astrojs/node command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-525: Use of Web Browser Cache Containing Sensitive Information, where the web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached. In Astro, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-41322 Affected Astro Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
@astrojs/node
|
npm |
< 10.0.5
|
10.0.5
|
References
Frequently Asked Questions
What is CVE-2026-41322?
Which Astro versions are affected?
What version fixes CVE-2026-41322?
Is @astrojs/node affected?
What is the CVSS score of CVE-2026-41322?
What CWE is associated with CVE-2026-41322?
How can I check npm dependencies for CVE-2026-41322?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-c57f-mm3j-27q9",
"modified" : "2026-04-27T16:42:14Z",
"published" : "2026-04-23T14:36:03Z",
"aliases" : [ "CVE-2026-41322" ],
"summary" : "Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed ",
"details" : "### Summary\nRequesting a static JS/CSS resource from the `_astro` path with an incorrect or malformed `if-match` header returns a `500` error with a one-year cache lifetime instead of `412` in some cases. As a result, all subsequent requests to that file — regardless of the `if-match` header — will be served a 5xx error instead of the file until the cache expires.\n\nSending an incorrect or malformed `if-match` header should always return a `412` error without any cache headers, which is not the current behavior.\n\n### Affected Versions\n- `astro@5.14.1`\n- `@astrojs/node@9.4.4`\n\n### Proof of Concept\n\nRun the following command:\n\n```\ncurl -s -o /dev/null -D - <host location>/_astro/_slug_.UTbyeVfw.css -H \"if-match: xxx\"\n```\n\nIf a 5xx error is not returned, inspect the resources via the browser's web inspector and select another CSS/JS file to request until a 5xx error is returned. The behavior generally defaults to a 5xx response. Note that all static files are immutable, so the cache must be purged or disabled to reproduce reliably.\n\nA response similar to the following is expected from CloudFront:\n\n```\nHTTP/2 500 \ncontent-type: text/html\ncontent-length: 166541\ndate: Thu, 09 Apr 2026 12:53:08 GMT\nlast-modified: Wed, 21 Jan 2026 13:40:08 GMT\netag: \"a68349e96c2faf8861c330aeb548441a\"\nx-amz-server-side-encryption: AES256\naccept-ranges: bytes\nserver: AmazonS3\nx-cache: Error from cloudfront\nvia: 1.1 3591be88662e5675a9dc1cc4e0a9c392.cloudfront.net (CloudFront)\nx-amz-cf-pop: ZRH55-P2\nx-amz-cf-id: Rg--RIYCKcA55GZqZXdvu-VTvpxBFFVzV4LBIcKq5pB_hktcrhYbKg==\n```\n\nThe above is not the real server output but the AWS error response triggered when the pods return a 5xx. Below is the output of the same `curl` command issued directly against a pod in Kubernetes:\n\n```\n❯ curl -s -o /dev/null -D - -H \"Host: tagesanzeiger.ch\" 127.0.0.1:3333/_astro/InstallPrompt.astro_astro_type_script_index_0_lang.C0M4llHG.js -H \"if-match: xxx\"\n\nHTTP/1.1 500 Internal Server Error\nCache-Control: public, max-age=31536000, immutable\nAccept-Ranges: bytes\nLast-Modified: Tue, 07 Apr 2026 07:08:03 GMT\nETag: W/\"560-19d66c50c38\"\nContent-Type: text/javascript; charset=utf-8\nDate: Tue, 07 Apr 2026 08:23:54 GMT\nConnection: keep-alive\nKeep-Alive: timeout=5\nTransfer-Encoding: chunked\n```\n\nThis demonstrates that the pod itself returns a `5xx` error instead of `412`. In addition, the response includes a `Cache-Control: public, max-age=31536000, immutable` header.\n\nBecause the testing setup configures `if-match` as part of the cache key, the exploit no longer affects the production application. Prior to that change, the CDN Point of Presence would become cache-poisoned, and any client visiting the affected pages without cached files through the same PoP would receive broken pages. This was reproduced by creating test URLs and visiting them in a browser only after triggering the exploit. The exploited resources returned `5xx` errors instead of the original CSS/JS content, breaking the application.\n\n### Details\nThe findings were analyzed with an LLM, which identified the following file as the likely source: [serve-static.ts](https://github.com/withastro/astro/blob/main/packages/integrations/node/src/serve-static.ts)\n\n```js\n// Lines 129-153\n\nlet forwardError = false;\n\nstream.on('error', (err) => {\n if (forwardError) {\n console.error(err.toString());\n res.writeHead(500);\n res.end('Internal server error');\n return;\n }\n // File not found, forward to the SSR handler\n ssr();\n});\nstream.on('headers', (_res: ServerResponse) => {\n // assets in dist/_astro are hashed and should get the immutable header\n if (normalizedPathname.startsWith(`/${app.manifest.assetsDir}/`)) {\n // This is the \"far future\" cache header, used for static files whose name includes their digest hash.\n // 1 year (31,536,000 seconds) is convention.\n // Taken from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable\n _res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');\n }\n});\nstream.on('file', () => {\n forwardError = true;\n});\nstream.pipe(res);\n```\n\nLLM analysis:\n\n> `send` handles conditional request headers such as `If-Match` internally. When a file is found but the precondition fails (ETag mismatch), `send`:\n>\n> 1. Emits `file` (the file exists) → `forwardError = true`\n> 2. Emits `headers` → `Cache-Control: public, max-age=31536000, immutable` is set on `res`\n> 3. Emits `error` with a `PreconditionFailedError` (status 412)\n>\n> However, the error handler does not inspect the error's status code:\n>\n> ```js\n> stream.on('error', (err) => {\n> if (forwardError) {\n> console.error(err.toString());\n> res.writeHead(500); // ← always 500, regardless of the actual error\n> res.end('Internal server error');\n> return;\n> }\n> ssr();\n> });\n> ```\n>\n> Because `Cache-Control` was already set during the `headers` event, the response is sent as:\n>\n> ```\n> HTTP/1.1 500 Internal Server Error\n> Cache-Control: public, max-age=31536000, immutable\n> ```\n\n\n### Impact\n**Cache Poisoning** — An attacker can force edge servers to cache an error page instead of the actual content, rendering one or more assets unavailable to legitimate users until the cache expires.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "npm",
"name" : "@astrojs/node"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "10.0.5"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/withastro/astro/security/advisories/GHSA-c57f-mm3j-27q9"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41322"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/withastro/astro"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-525" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-04-23T14:36:03Z",
"nvd_published_at" : "2026-04-24T18:16:28Z"
}
}