http-cache-semantics EUVD-2026-83255

Requires http-cache-semantics to be used as a SHARED cache serving multiple distinct clients/users (not a private per-user cache), AND an origin server that returns a wildcard Vary header (Vary: *) on a cacheable response containing sensitive per-user data. The attacker must request a URL that another client previously fetched and that is still present in the cache. Limiting factors: exploitation is non-deterministic (CVSS AT:P/AC:H) since it depends on live cache state, cache freshness/eviction, and the origin actually emitting wildcard Vary; it does not affect private/single-user cache deployments and yields only confidentiality impact (no integrity or availability effect). No authentication or user interaction is required against a vulnerable shared-cache deployment.

The vendor CVSS 4.0 base score is 8.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N), driven almost entirely by high confidentiality impact on a network-reachable, unauthenticated path - but tempered by AC:H and AT:P, which correctly reflect that exploitation is conditional and non-deterministic rather than a straightforward request. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis'; the only exploitation evidence is a VulnCheck advisory and an upstream GitHub issue (#57) documenting the flaw. The realistic risk is materially lower than the 8.2 headline suggests: this is a logic bug in a caching helper library, and impact only materializes when the library is used as a genuinely shared cache across multiple users AND an origin emits a wildcard Vary response - the AC:H/AT:P metrics encode exactly this gating. The pure-confidentiality profile (VI:N/VA:N) means no integrity or availability consequence. Bottom line: a real, credible cross-client information-disclosure issue worth patching promptly given the library's enormous transitive footprint, but not an internet-wide, mass-automatable emergency in the absence of active exploitation or POC.

A shared HTTP cache built on http-cache-semantics stores a response that an origin marked with a wildcard Vary header (Vary: *), which per RFC should never be reused across requests; because _varyMatches() does a byte-for-byte comparison instead of treating the wildcard as non-matching, the cache treats a later request for the same URL as a hit. An attacker requests a URL previously fetched by a different user and receives that other user's cached, potentially sensitive response. No public exploit code is identified; success depends on origin behavior and cache state (reflected in CVSS AC:H/AT:P).