CVE-2026-93748: 
Grafana vulnerability analysis and mitigation

CVE-2026-93748 is a cross-user cache disclosure vulnerability in the http-cache-semantics JavaScript library (versions through 4.2.0) that allows unauthenticated attackers to retrieve cached session credentials belonging to other users. The flaw arises when the library's evaluateRequest() method improperly honors client-supplied Cache-Control: max-stale directives for shared-cache entries that were deliberately zeroed for security reasons (e.g., responses containing Set-Cookie without public, or responses with proxy-revalidate). It was disclosed on September 17–18, 2026, via a GitHub issue and subsequently published to the NVD and GitHub Advisory Database. Affected versions are all releases up to and including 4.2.0. The vulnerability carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, GitHub Issue).

The root cause is classified as CWE-524 (Use of Cache Containing Sensitive Information). The library's maxAge() method correctly returns 0 for shared responses carrying Set-Cookie without Cache-Control: public, and for responses with proxy-revalidate, specifically to prevent cross-user cache reuse. However, the evaluateRequest() stale-serving branch only checks for must-revalidate before honoring a client's max-stale directive — it does not separately track the security-motivated zero-lifetime prohibitions. As a result, an attacker who sends a request with a sufficiently large Cache-Control: max-stale value causes the library to evaluate allowsStaleWithoutRevalidation as true and serve the cached entry, including its Set-Cookie header, to a different user. The vulnerable logic resides in index.js at lines L425–L441 and L603–L623 (GitHub Issue, Source L425, Source L603).

Successful exploitation results in a high-severity confidentiality breach: an unauthenticated remote attacker can obtain another user's Set-Cookie session credentials from a shared cache, enabling full session hijacking without any interaction from the victim. There is no integrity or availability impact. The exposure is limited to deployments using http-cache-semantics in shared/proxy cache mode (the default shared: true configuration), and requires that the shared cache retain the security-zeroed entry and consult satisfiesWithoutRevalidation() or evaluateRequest() at read time — the documented usage pattern. Successful session theft could enable lateral movement within authenticated application contexts (Github Advisory, GitHub Issue).

No confirmed in-the-wild exploitation has been observed, and no weaponized exploit code is publicly available; the referenced GitHub issue is classified as a security advisory/bug report rather than a working exploit (GitHub Issue). The NVD SSVC assessment notes the vulnerability is automatable and has a PoC-level exploitation classification. The EPSS score is approximately 0.4–0.53%, placing it in roughly the 42nd percentile for exploitation probability within 30 days. The CVE status is listed as "Deferred" and it is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (Github Advisory).

1. Reconnaissance: Identify applications or proxy services using http-cache-semantics version ≤ 4.2.0 in shared cache mode. This library is used by packages such as make-fetch-happen, cacheable-request (used by got), and npm/registry-fetch, so any Node.js proxy or caching layer built on these may be vulnerable.
2. Trigger victim's request: Wait for or induce a legitimate user to make a request to a target URL that results in a response containing a Set-Cookie header without Cache-Control: public (or with proxy-revalidate). The library will store this entry in the shared cache with maxAge() = 0.
3. Craft malicious request: As an unauthenticated attacker, send an HTTP GET request to the same URL with a large max-stale value in the Cache-Control request header, e.g.:

   GET /target-url HTTP/1.1
   Host: vulnerable-proxy.example.com
   Cache-Control: max-stale=999999

4. Bypass security zeroing: The library's evaluateRequest() finds the stale entry, evaluates allowsStaleWithoutRevalidation as true (since must-revalidate is absent and max-stale exceeds the staleness), and returns the cached response — including the victim's Set-Cookie header.
5. Hijack session: Extract the Set-Cookie value from the response and use it to authenticate as the victim user in subsequent requests to the application (GitHub Issue, Source L425).

• Network: HTTP requests to shared cache endpoints containing Cache-Control: max-stale with unusually large values (e.g., max-stale=999999 or max-stale=86400000) from clients that do not normally send such directives; repeated requests to the same URL from different source IPs with max-stale headers shortly after a legitimate user's request.
• Logs: Proxy or application access logs showing cache HIT responses to requests bearing Cache-Control: max-stale for URLs that serve authenticated content (e.g., login endpoints, session-establishing endpoints); responses to these requests that include Set-Cookie headers in the logged response.
• Application: Anomalous session activity — authenticated sessions originating from IP addresses or user agents inconsistent with the legitimate account holder, occurring shortly after a cache entry was populated.

The primary remediation is to update http-cache-semantics to a version beyond 4.2.0 once a patched release is available from the maintainer. As an immediate workaround, consumers of the library should strip Set-Cookie headers from responses before caching them in shared deployments, refuse to store proxy-revalidate responses, or explicitly ignore client max-stale directives in shared cache configurations. Alternatively, initializing CachePolicy with shared: false prevents the vulnerability in single-user cache contexts. Operators should also review any downstream packages (e.g., make-fetch-happen, cacheable-request) that depend on this library and apply updates as they become available (Github Advisory, GitHub Issue).

A Mastodon post by security researcher @hugovalters noted the vulnerability shortly after disclosure. Red Hat opened a Bugzilla tracking entry (bug #2538111) and published a CVE advisory page, indicating downstream impact assessment for Red Hat products. Microsoft also published an advisory entry via MSRC. Community discussion has been limited, with no major media coverage or widespread researcher commentary identified at this time (RedHat CVE, MSRC).