Repository navigation
GHSA-ch52-4w7c-c8xp (CVE-2026-93748) claim of bogus report by repo owner #10139
Description
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!
Activity
fix(deps): http-cache-semantics を 4.3.0 に更新して npm audit の失敗を解消する
chore(deps): update all non-major dependencies to v2026.9.15 (#185)
revert(deps): drop the http-cache-semantics 4.3.0 override
fix(security): clear Trivy reds for http-cache-semantics and braces (#…
fix(deps): cite GHSA-f27v-pv5m-c5g6 as the operative advisory (BLO-39…
Bump http-cache-semantics to 4.3.0 (Dependabot #27)
chore(deps)!: update dependencies securely (#787)
fix(deps): replace http-cache-semantics 4.2.0 with vendored 4.3.1 (CV…
CVE-2026-93748: http-cache-semantics max-stale handling can disclose …
fix: brace-expansion / http-cache-semantics / source-map-js の advisor…
mazze93 commentedon 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.chore(deps): bump http-cache-semantics to 4.3.0 to clear the max-stal…
chore(deps): resolve dependency vulnerabilities (2026-10-06) (#551)
fix(security): remediate high-severity advisories in the DSH runtime …
security: pin http-cache-semantics to 4.3.0 in angular-demo-app
mrgrain commentedon Oct 13, 2026
@MikeMcC399 GitHub is not the issuer of the CVE. You might need to take this up with VulnCheck who is the CNA issuing it.
MikeMcC399 commentedon Oct 13, 2026
Thanks for the hint! I'm only a consumer of the module through transient dependencies, so I won't take this further.
https://www.npmjs.com/package/http-cache-semantics/v/4.3.0, published on Oct 4, 2026, would stop CVE-2026-93748 being reported, since it lists affected versions as "<= 4.2.0".
[FIX] Bump http-cache-semantics to 4.3.0 in /docs-site (GHSA-ch52-4w7…
chore(security): renew braces audit exception, drop dead http-cache-s…
chore(site): clear the Dependabot alerts of the site lockfile (#274)
Bump @percy/cli to 1.32.11 to remove http-cache-semantics