GHSA-ch52-4w7c-c8xp (CVE-2026-93748) claim of bogus report by repo owner

[MikeMcC399]

Advisory: GHSA-ch52-4w7c-c8xp
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-ch52-4w7c-c8xp/GHSA-ch52-4w7c-c8xp.json
Title: http-cache-semantics max-stale handling can disclose cross-user cached responses
CVE: CVE-2026-93748
Repo: https://github.com/kornelski/http-cache-semantics

@kornelski writes in kornelski/http-cache-semantics#56 (comment)

---

This report is bogus. The RFC explicitly allows sharing of responses with cookies, as unwise as that may be:

https://www.rfc-editor.org/rfc/rfc9111.html#section-7.3

Note that the Set-Cookie response header field [COOKIE] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers that wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.

The poster is mistaken in assuming that max-age could be used to prevent sharing of cache entries. "security-zeroed cache entries" is a made-up term. Sharing of responses between users is prevented with Cache-control: private, not by tweaking freshness of shareable responses.

---

Please review and consider withdrawing the advisory!

[mazze93]

Independent re-test of GHSA-ch52-4w7c-c8xp, offered as evidence for both sides of the dispute. We tested 20 published releases (3.3.3 through 4.3.0, tarballs verified against registry dist.shasum) on Node 22.23.3.

The advisory's specific claim (Set-Cookie + max-stale): the behavior reproduces from 3.4.0 through 4.3.0. A shared policy for max-age=60 + Set-Cookie reports maxAge() === 0, yet a request carrying max-stale is served the stored response. However, RFC 9111 §7.3 states that Set-Cookie "does not inhibit caching", and §5.2.1.2 permits serving stale responses to a client that sends max-stale. maxAge() === 0 for cookied shared responses is the library's own conservative default, not an in-protocol prohibition. On the RFC text, we agree with the maintainer that this specific behavior is not a vulnerability in the library.

A narrower, RFC-grounded defect does exist in the same code path: a request's max-stale overrides response directives that RFC 9111 §4.2.4 says forbid serving stale content without validation: shared-cache proxy-revalidate (§5.2.2.8), shared-cache s-maxage (§5.2.2.10) and unqualified no-cache (§5.2.2.4). must-revalidate is handled correctly. satisfiesWithoutRevalidation() shows this in 3.4.0 through 4.3.0 (3.3.3 predates max-stale support), and evaluateRequest() (4.2.0+) returns the cached response without revalidation. It is publicly discussed in the title of kornelski/http-cache-semantics#56 and addressed by open PR kornelski/http-cache-semantics#63. Its security impact depends on an origin relying on those directives to force per-request validation (for example, an authorization check). It is not the cross-user Set-Cookie scenario the advisory describes.

If the advisory is kept, we'd suggest rewriting it around the directive defect rather than Set-Cookie. If it's withdrawn, the directive issue is better tracked upstream as a bug.