Common Weakness Enumeration

CWE-525

Allowed

Use of Web Browser Cache Containing Sensitive Information

Abstraction: Variant · Status: Incomplete

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.

60 vulnerabilities reference this CWE, most recent first.

GHSA-C57F-MM3J-27Q9

Vulnerability from github – Published: 2026-04-23 14:36 – Updated: 2026-04-27 16:42
VLAI
Summary
Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed
Details

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

// 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 headersCache-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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-23T14:36:03Z",
    "nvd_published_at": "2026-04-24T18:16:28Z",
    "severity": "MODERATE"
  },
  "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 \u2014 regardless of the `if-match` header \u2014 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 - \u003chost location\u003e/_astro/_slug_.UTbyeVfw.css -H \"if-match: xxx\"\n```\n\nIf a 5xx error is not returned, inspect the resources via the browser\u0027s 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\u276f 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(\u0027error\u0027, (err) =\u003e {\n    if (forwardError) {\n        console.error(err.toString());\n        res.writeHead(500);\n        res.end(\u0027Internal server error\u0027);\n        return;\n    }\n    // File not found, forward to the SSR handler\n    ssr();\n});\nstream.on(\u0027headers\u0027, (_res: ServerResponse) =\u003e {\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(\u0027Cache-Control\u0027, \u0027public, max-age=31536000, immutable\u0027);\n    }\n});\nstream.on(\u0027file\u0027, () =\u003e {\n    forwardError = true;\n});\nstream.pipe(res);\n```\n\nLLM analysis:\n\n\u003e `send` handles conditional request headers such as `If-Match` internally. When a file is found but the precondition fails (ETag mismatch), `send`:\n\u003e\n\u003e 1. Emits `file` (the file exists) \u2192 `forwardError = true`\n\u003e 2. Emits `headers` \u2192 `Cache-Control: public, max-age=31536000, immutable` is set on `res`\n\u003e 3. Emits `error` with a `PreconditionFailedError` (status 412)\n\u003e\n\u003e However, the error handler does not inspect the error\u0027s status code:\n\u003e\n\u003e ```js\n\u003e stream.on(\u0027error\u0027, (err) =\u003e {\n\u003e     if (forwardError) {\n\u003e         console.error(err.toString());\n\u003e         res.writeHead(500);   // \u2190 always 500, regardless of the actual error\n\u003e         res.end(\u0027Internal server error\u0027);\n\u003e         return;\n\u003e     }\n\u003e     ssr();\n\u003e });\n\u003e ```\n\u003e\n\u003e Because `Cache-Control` was already set during the `headers` event, the response is sent as:\n\u003e\n\u003e ```\n\u003e HTTP/1.1 500 Internal Server Error\n\u003e Cache-Control: public, max-age=31536000, immutable\n\u003e ```\n\n\n### Impact\n**Cache Poisoning** \u2014 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.",
  "id": "GHSA-c57f-mm3j-27q9",
  "modified": "2026-04-27T16:42:14Z",
  "published": "2026-04-23T14:36:03Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed "
}

GHSA-F3FG-MF2Q-FJ3F

Vulnerability from github – Published: 2025-06-04 21:24 – Updated: 2025-06-04 22:57
VLAI
Summary
NextJS-Auth0 SDK Vulnerable to CDN Caching of Session Cookies
Details

Overview In Auth0 Next.js SDK versions 4.0.1 to 4.6.0, __session cookies set by auth0.middleware may be cached by CDNs due to missing Cache-Control headers.

Am I Affected? You are affected by this vulnerability if you meet the following preconditions:

  1. Applications using the NextJS-Auth0 SDK, versions between 4.0.1 to 4.6.0,
  2. Applications using CDN or edge caching that caches responses with the Set-Cookie header.
  3. If the Cache-Control header is not properly set for sensitive responses.

Fix Upgrade auth0/nextjs-auth0 to v4.6.1.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@auth0/nextjs-auth0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.1"
            },
            {
              "fixed": "4.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-04T21:24:52Z",
    "nvd_published_at": "2025-06-04T21:15:40Z",
    "severity": "HIGH"
  },
  "details": "**Overview**\nIn Auth0 Next.js SDK versions 4.0.1 to 4.6.0, __session cookies set by auth0.middleware may be cached by CDNs due to missing Cache-Control headers.\n\n**Am I Affected?**\nYou are affected by this vulnerability if you meet the following preconditions:\n\n1. Applications using the NextJS-Auth0 SDK, versions between 4.0.1 to 4.6.0,\n2. Applications using CDN or edge caching that caches responses with the Set-Cookie header.\n3. If the Cache-Control header is not properly set for sensitive responses.\n\n**Fix**\nUpgrade auth0/nextjs-auth0 to v4.6.1.",
  "id": "GHSA-f3fg-mf2q-fj3f",
  "modified": "2025-06-04T22:57:21Z",
  "published": "2025-06-04T21:24:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/nextjs-auth0/security/advisories/GHSA-f3fg-mf2q-fj3f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/nextjs-auth0/commit/12a62ca596db3b0827b39a4b865b882423e7cb1e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/nextjs-auth0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NextJS-Auth0 SDK Vulnerable to CDN Caching of Session Cookies"
}

GHSA-F3H8-6QJ8-RP34

Vulnerability from github – Published: 2026-01-26 18:31 – Updated: 2026-01-28 21:31
VLAI
Details

Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) serve sensitive administrative content without appropriate cache-control directives. As a result, browsers may store credential-bearing responses locally, exposing them to subsequent unauthorized access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-26T18:16:41Z",
    "severity": "MODERATE"
  },
  "details": "Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) serve sensitive administrative content without appropriate cache-control directives. As a result, browsers may store credential-bearing responses locally, exposing them to subsequent unauthorized access.",
  "id": "GHSA-f3h8-6qj8-rp34",
  "modified": "2026-01-28T21:31:19Z",
  "published": "2026-01-26T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24437"
    },
    {
      "type": "WEB",
      "url": "https://www.tendacn.com/product/W30E"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/tenda-w30e-v2-missing-cache-controls-for-credential-bearing-pages"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FW5R-6M3X-RH7P

Vulnerability from github – Published: 2024-09-04 18:12 – Updated: 2024-11-18 16:27
VLAI
Summary
Flask-AppBuilder's login form allows browser to cache sensitive fields
Details

Impact

Auth DB login form default cache directives allows browser to locally store sensitive data. This can be an issue on environments using shared computer resources.

Patches

Upgrade flask-appbuilder to version 4.5.1

Workarounds

If upgrading is not possible configure your web server to send the following HTTP headers for /login: "Cache-Control": "no-store, no-cache, must-revalidate, max-age=0" "Pragma": "no-cache" "Expires": "0"

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "flask-appbuilder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-04T18:12:16Z",
    "nvd_published_at": "2024-09-04T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAuth DB login form default cache directives allows browser to locally store sensitive data. This can be an issue on environments using shared computer resources.\n\n### Patches\nUpgrade flask-appbuilder to version 4.5.1\n\n### Workarounds\nIf upgrading is not possible configure your web server to send the following HTTP headers for /login:\n\"Cache-Control\": \"no-store, no-cache, must-revalidate, max-age=0\"\n\"Pragma\": \"no-cache\"\n\"Expires\": \"0\" \n",
  "id": "GHSA-fw5r-6m3x-rh7p",
  "modified": "2024-11-18T16:27:09Z",
  "published": "2024-09-04T18:12:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dpgaspar/Flask-AppBuilder/security/advisories/GHSA-fw5r-6m3x-rh7p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45314"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpgaspar/Flask-AppBuilder/commit/3030e881d2e44f4021764e18e489fe940a9b3636"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dpgaspar/Flask-AppBuilder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flask-AppBuilder\u0027s login form allows browser to cache sensitive fields "
}

GHSA-G849-X577-8J36

Vulnerability from github – Published: 2023-11-06 15:30 – Updated: 2023-11-06 15:30
VLAI
Details

A flaw was found In 3Scale Admin Portal. If a user logs out from the personal tokens page and then presses the back button in the browser, the tokens page is rendered from the browser cache.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-06T13:15:10Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found In 3Scale Admin Portal. If a user logs out from the personal tokens page and then presses the back button in the browser, the tokens page is rendered from the browser cache.",
  "id": "GHSA-g849-x577-8j36",
  "modified": "2023-11-06T15:30:32Z",
  "published": "2023-11-06T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4910"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-4910"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2238498"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GGCG-QQQW-C8FF

Vulnerability from github – Published: 2025-06-03 18:30 – Updated: 2025-06-03 18:30
VLAI
Details

IBM QRadar Suite Software 1.10.12.0 through 1.11.2.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 allows web pages to be stored locally which can be read by another user on the system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-1334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-03T16:15:22Z",
    "severity": "MODERATE"
  },
  "details": "IBM QRadar Suite Software 1.10.12.0 through 1.11.2.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 allows web pages to be stored locally which can be read by another user on the system.",
  "id": "GHSA-ggcg-qqqw-c8ff",
  "modified": "2025-06-03T18:30:41Z",
  "published": "2025-06-03T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1334"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7235432"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPRJ-976F-W257

Vulnerability from github – Published: 2025-06-18 18:30 – Updated: 2025-06-18 18:30
VLAI
Details

IBM Sterling B2B Integrator and IBM Sterling File Gateway 6.0.0.0 through 6.1.2.6 and 6.2.0.0 through 6.2.0.4 could allow a local user to obtain sensitive information from a user’s web browser cache due to not using a suitable caching policy.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-1348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T17:15:28Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling B2B Integrator and IBM Sterling File Gateway 6.0.0.0 through 6.1.2.6 and 6.2.0.0 through 6.2.0.4 could allow a local user to obtain sensitive information from a user\u2019s web browser cache due to not using a suitable caching policy.",
  "id": "GHSA-gprj-976f-w257",
  "modified": "2025-06-18T18:30:32Z",
  "published": "2025-06-18T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1348"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7237068"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HQ75-XG7R-RX6C

Vulnerability from github – Published: 2025-07-11 17:09 – Updated: 2025-07-11 17:09
VLAI
Summary
Better Call routing bug can lead to Cache Deception
Details

Summary

Using a CDN that caches (/**/*.png, /**/*.json, /**/*.css, etc...) requests, a cache deception can emerge. This could lead to unauthorized access to user sessions and personal data when cached responses are served to other users.

Details

The vulnerability occurs in the request processing logic where path sanitization is insufficient. The library splits the path using config.basePath but doesn't properly validate the remaining path components. This allows specially crafted requests that appear to be static assets (like /api/auth/get-session/api/auth/image.png assuming config.basePath=/api/auth) to bypass typical CDN cache exclusion rules while actually returning sensitive data.

The problematic code here:

    const processRequest = async (request: Request) => {
        const url = new URL(request.url);
        const path = config?.basePath ? url.pathname.split(config.basePath)[1] : url.pathname;

Since this library is largely coupled with better-auth, it becomes more clear why this can be dangerous with an example request:

image

Impact

This is a cache deception vulnerability affecting better-call users with CDN caching enabled. which can expose sensitive data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-call"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-11T17:09:53Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nUsing a CDN that caches (`/**/*.png`, `/**/*.json`, `/**/*.css`, etc...) requests, a cache deception can emerge. This could lead to unauthorized access to user sessions and personal data when cached responses are served to other users.\n\n### Details\n\nThe vulnerability occurs in the request processing logic where path sanitization is insufficient. The library splits the path using `config.basePath` but doesn\u0027t properly validate the remaining path components. This allows specially crafted requests that appear to be static assets (like `/api/auth/get-session/api/auth/image.png` assuming `config.basePath`=`/api/auth`) to bypass typical CDN cache exclusion rules while actually returning sensitive data.\n\nThe problematic code [here](https://github.com/Bekacru/better-call/blob/8b6f13e24fad7f4666a582601517bb3232d4f4af/src/router.ts#L124):\n```js\n\tconst processRequest = async (request: Request) =\u003e {\n\t\tconst url = new URL(request.url);\n\t\tconst path = config?.basePath ? url.pathname.split(config.basePath)[1] : url.pathname;\n```\n\nSince this library is largely coupled with `better-auth`, it becomes more clear why this can be dangerous with an example request:\n\n\u003cimg width=\"800\" alt=\"image\" src=\"https://github.com/user-attachments/assets/2ab7c4dd-0700-4f59-863f-79f2b5edbb37\" /\u003e\n\n### Impact\n\nThis is a cache deception vulnerability affecting `better-call` users with CDN caching enabled. which can expose sensitive data.",
  "id": "GHSA-hq75-xg7r-rx6c",
  "modified": "2025-07-11T17:09:53Z",
  "published": "2025-07-11T17:09:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Bekacru/better-call/security/advisories/GHSA-hq75-xg7r-rx6c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Bekacru/better-call/commit/7c7d31b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Bekacru/better-call"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Better Call routing bug can lead to Cache Deception"
}

GHSA-HQ8F-55FX-PQV7

Vulnerability from github – Published: 2023-02-01 21:30 – Updated: 2023-02-09 18:30
VLAI
Details

IBM ICP4A - Automation Decision Services 18.0.0, 18.0.1, 18.0.2, 19.0.1, 19.0.2, 19.0.3, 20.0.1, 20.0.2, 20.0.3, 21.0.1, 21.0.2, 21.0.3, 22.0.1, and 22.0.2 allows web pages to be stored locally which can be read by another user on the system. IBM X-Force ID: 244504.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-01T19:15:00Z",
    "severity": "LOW"
  },
  "details": "IBM ICP4A - Automation Decision Services 18.0.0, 18.0.1, 18.0.2, 19.0.1, 19.0.2, 19.0.3, 20.0.1, 20.0.2, 20.0.3, 21.0.1, 21.0.2, 21.0.3, 22.0.1, and 22.0.2 allows web pages to be stored locally which can be read by another user on the system. IBM X-Force ID: 244504.",
  "id": "GHSA-hq8f-55fx-pqv7",
  "modified": "2023-02-09T18:30:29Z",
  "published": "2023-02-01T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23469"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/244504"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6857999"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HRP6-W4V2-8737

Vulnerability from github – Published: 2022-05-17 05:05 – Updated: 2023-03-27 16:14
VLAI
Summary
Rack-Cache caches sensitive headers
Details

The Rack::Cache rubygem 0.3.0 through 1.1 caches Set-Cookie and other sensitive headers, which allows attackers to obtain sensitive cookie information, hijack web sessions, or have other unspecified impact by accessing the cache.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack-cache"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2012-2671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-27T16:14:33Z",
    "nvd_published_at": "2012-06-17T03:41:00Z",
    "severity": "MODERATE"
  },
  "details": "The Rack::Cache rubygem 0.3.0 through 1.1 caches Set-Cookie and other sensitive headers, which allows attackers to obtain sensitive cookie information, hijack web sessions, or have other unspecified impact by accessing the cache.",
  "id": "GHSA-hrp6-w4v2-8737",
  "modified": "2023-03-27T16:14:33Z",
  "published": "2022-05-17T05:05:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2671"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rtomayko/rack-cache/pull/52"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rtomayko/rack-cache/commit/2e3a64d07daac4c757cc57620f2288e865a09b90"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.novell.com/show_bug.cgi?id=763650"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=824520"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rtomayko/rack-cache/blob/master/CHANGES"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack-cache/CVE-2012-2671.yml"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081812.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/06/06/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/06/06/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Rack-Cache caches sensitive headers"
}

Mitigation
Architecture and Design

Protect information stored in cache.

Mitigation
Implementation

Use a restrictive caching policy for forms and web pages that potentially contain sensitive information, such as "no-cache" in the Cache-Control header.

Mitigation
Architecture and Design

Do not store unnecessarily sensitive information in the cache.

Mitigation
Architecture and Design

Consider using encryption in the cache.

CAPEC-37: Retrieve Embedded Sensitive Data

An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.