CVE-2026-41322: Astro Cache Poisoning Due To Incorrect Vulnerability

MODERATE
Advisory Identifier: GHSA-c57f-mm3j-27q9
CVSS 5.3
CWE-525
Published
Advisory Summary

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

CVE Identifier CVE-2026-41322
GHSA Identifier GHSA-c57f-mm3j-27q9
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-525: Use of Web Browser Cache Containing Sensitive Information
Affected Product Astro
Package Ecosystem npm
Published Date
Last Updated

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

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (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.

@astrojs/node fixed: 10.0.5
npm install @astrojs/node@10.0.5
Verify Direct and Transitive Dependencies

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

### Summary Requesting 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. Sending an incorrect or malformed `if-match` header should always return a `412` error without any cache headers, which is not the current behavior. ### Affected Versions - `astro@5.14.1` - `@astrojs/node@9.4.4` ### Proof of Concept Run the following command: ``` curl -s -o /dev/null -D - <host location>/_astro/_slug_.UTbyeVfw.css -H "if-match: xxx" ``` If 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. A response similar to the following is expected from CloudFront: ``` HTTP/2 500 content-type: text/html content-length: 166541 date: Thu, 09 Apr 2026 12:53:08 GMT last-modified: Wed, 21 Jan 2026 13:40:08 GMT etag: "a68349e96c2faf8861c330aeb548441a" x-amz-server-side-encryption: AES256 accept-ranges: bytes server: AmazonS3 x-cache: Error from cloudfront via: 1.1 3591be88662e5675a9dc1cc4e0a9c392.cloudfront.net (CloudFront) x-amz-cf-pop: ZRH55-P2 x-amz-cf-id: Rg--RIYCKcA55GZqZXdvu-VTvpxBFFVzV4LBIcKq5pB_hktcrhYbKg== ``` The 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: ``` ❯ 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" HTTP/1.1 500 Internal Server Error Cache-Control: public, max-age=31536000, immutable Accept-Ranges: bytes Last-Modified: Tue, 07 Apr 2026 07:08:03 GMT ETag: W/"560-19d66c50c38" Content-Type: text/javascript; charset=utf-8 Date: Tue, 07 Apr 2026 08:23:54 GMT Connection: keep-alive Keep-Alive: timeout=5 Transfer-Encoding: chunked ``` This 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. Because 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. ### Details The 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) ```js // Lines 129-153 let forwardError = false; stream.on('error', (err) => { if (forwardError) { console.error(err.toString()); res.writeHead(500); res.end('Internal server error'); return; } // File not found, forward to the SSR handler ssr(); }); stream.on('headers', (_res: ServerResponse) => { // assets in dist/_astro are hashed and should get the immutable header if (normalizedPathname.startsWith(`/${app.manifest.assetsDir}/`)) { // This is the "far future" cache header, used for static files whose name includes their digest hash. // 1 year (31,536,000 seconds) is convention. // Taken from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable _res.setHeader('Cache-Control', 'public, max-age=31536000, immutable'); } }); stream.on('file', () => { forwardError = true; }); stream.pipe(res); ``` LLM analysis: > `send` handles conditional request headers such as `If-Match` internally. When a file is found but the precondition fails (ETag mismatch), `send`: > > 1. Emits `file` (the file exists) → `forwardError = true` > 2. Emits `headers` → `Cache-Control: public, max-age=31536000, immutable` is set on `res` > 3. Emits `error` with a `PreconditionFailedError` (status 412) > > However, the error handler does not inspect the error's status code: > > ```js > stream.on('error', (err) => { > if (forwardError) { > console.error(err.toString()); > res.writeHead(500); // ← always 500, regardless of the actual error > res.end('Internal server error'); > return; > } > ssr(); > }); > ``` > > Because `Cache-Control` was already set during the `headers` event, the response is sent as: > > ``` > HTTP/1.1 500 Internal Server Error > Cache-Control: public, max-age=31536000, immutable > ``` ### Impact **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.

CVE-2026-41322 Affected Astro Versions

1 component(s)
Fixed Versions:
10.0.5
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?
CVE-2026-41322 is a security vulnerability in Astro involving Cache Poisoning due to incorrect error handling when if-match header is malformed under CWE-525: Use of Web Browser Cache Containing Sensitive Information.
Which Astro versions are affected?
Affected versions include releases prior to 10.0.5 across affected packages: @astrojs/node.
What version fixes CVE-2026-41322?
Upgrading to 10.0.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @astrojs/node affected?
Yes, @astrojs/node is affected in releases prior to 10.0.5. Upgrade your dependency to 10.0.5 or later.
What is the CVSS score of CVE-2026-41322?
CVE-2026-41322 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2026-41322?
CVE-2026-41322 is classified under CWE-525: Use of Web Browser Cache Containing Sensitive Information (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.).
How can I check npm dependencies for CVE-2026-41322?
Run the dependency tree command: 'npm ls @astrojs/node'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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"
  }
}