Repository navigation
GHSA-ch52-4w7c-c8xp (CVE-2026-93748) claim of bogus report by repo owner #10139
Description
Activity
- added a commit that references this issue
on Oct 4, 2026 - added a commit that references this issue
on Oct 4, 2026 - added a commit that references this issue
on Oct 4, 2026 - added a commit that references this issue
on Oct 4, 2026 - added a commit that references this issue
on Oct 5, 2026 - added a commit that references this issue
on Oct 6, 2026 - added a commit that references this issue
on Oct 7, 2026 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-CookiereportsmaxAge() === 0, yet a request carryingmax-staleis served the stored response. However, RFC 9111 §7.3 states thatSet-Cookie"does not inhibit caching", and §5.2.1.2 permits serving stale responses to a client that sendsmax-stale.maxAge() === 0for 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-staleoverrides response directives that RFC 9111 §4.2.4 says forbid serving stale content without validation: shared-cacheproxy-revalidate(§5.2.2.8), shared-caches-maxage(§5.2.2.10) and unqualifiedno-cache(§5.2.2.4).must-revalidateis handled correctly.satisfiesWithoutRevalidation()shows this in 3.4.0 through 4.3.0 (3.3.3 predatesmax-stalesupport), andevaluateRequest()(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-userSet-Cookiescenario 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.- added a commit that references this issue
on Oct 7, 2026 - added a commit that references this issue
on Oct 7, 2026 - added a commit that references this issue
on Oct 7, 2026 - added a commit that references this issue
on Oct 7, 2026
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
The poster is mistaken in assuming that
max-agecould be used to prevent sharing of cache entries. "security-zeroed cache entries" is a made-up term. Sharing of responses between users is prevented withCache-control: private, not by tweaking freshness of shareable responses.Please review and consider withdrawing the advisory!