CVE-2026-93750: 
Grafana vulnerability analysis and mitigation

CVE-2026-93750 is a cache validation vulnerability in the http-cache-semantics Node.js library (versions through 4.2.0) that allows unauthenticated network attackers to receive cached HTTP responses intended for other users. The flaw resides in the _varyMatches() function, which performs a byte-for-byte string comparison to detect Vary: * wildcards, failing to handle semantically equivalent but non-canonical forms. It was disclosed on September 17–18, 2026, via a GitHub issue and subsequently published to the NVD and GitHub Advisory Database. The vulnerability carries a CVSS v3.1 score of 5.9 (Medium) and a CVSS v4.0 score of 8.2 (High) (GitHub Advisory, GitHub Issue).

The root cause is an interpretation conflict (CWE-436) combined with improper use of cache containing sensitive information (CWE-524) in _varyMatches() at index.js:287–305. The function guards against Vary: * using an exact string equality check (this._resHeaders.vary === '*'), so any semantically equivalent but byte-different value — such as '* ' (trailing space), ' *' (leading space), or '*,' (trailing comma) — bypasses the wildcard block and falls through to per-field matching. Additionally, if the Vary field name is a JavaScript prototype property (e.g., constructor), both the incoming request headers and the stored request headers inherit the same Object.prototype value, causing the comparison to vacuously return equal. A public proof-of-concept script (poc4_vary.js) demonstrating all bypass variants is available on GitHub (GitHub Issue, Vulnerable Code).

Successful exploitation enables cross-client information disclosure: a shared cache using this library can serve a response the origin explicitly marked Vary: * ("never reuse") to a different client than the one for whom it was computed. Sensitive per-user data stored in cached responses — such as session tokens, personal data, or user-specific API responses — may be exposed to unauthorized parties. There is no integrity or availability impact; the vulnerability is purely a confidentiality breach, but the disclosed data could be chained into further attacks such as session hijacking or privilege escalation (GitHub Issue, GitHub Advisory).

A public proof-of-concept (PoC) exploit is available on GitHub as a standalone Node.js script that demonstrates the bypass locally using the vulnerable library (GitHub Issue). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.35–0.445%, placing it in roughly the 36th percentile for exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires specific preconditions: the target must use a shared cache backed by http-cache-semantics ≤ 4.2.0, and the origin server must emit cacheable responses with a non-canonical Vary: * header form (GitHub Advisory, Feedly).

1. Reconnaissance: Identify applications using http-cache-semantics ≤ 4.2.0 as a shared cache layer (e.g., Node.js proxies, CDN middleware, or caching libraries such as make-fetch-happen, cacheable-request/got, or npm/registry-fetch).
2. Trigger initial cache population: Cause or wait for Client A to make a request (e.g., GET /resource with accept-encoding: gzip) that results in the origin server responding with a cacheable response (cache-control: max-age=600) and a non-canonical Vary header such as '* ', ' *', '*,', or 'constructor' instead of the canonical '*'.
3. Exploit the bypass: As Client B (with different request headers, e.g., accept-encoding: br), send a request to the same URL. The _varyMatches() function performs an exact string check (this._resHeaders.vary === '*'), which fails for non-canonical forms, and falls through to per-field matching where the fields resolve vacuously (undefined === undefined for whitespace variants, or prototype-inherited values for constructor).
4. Receive cross-client cached response: The cache's satisfiesWithoutRevalidation() returns true for Client B's request, and the shared cache serves Client A's cached response — including any sensitive per-user content — to Client B.
5. Extract sensitive data: Parse the received response for session tokens, personal data, or other user-specific information that was intended only for Client A (GitHub Issue).

• Network: Repeated requests from different client IPs or user agents to the same URL in rapid succession, particularly where responses should be user-specific; unexpected cache hits for requests with differing Accept-Encoding or other Vary-relevant headers.
• Logs: Application or proxy logs showing satisfiesWithoutRevalidation returning true for requests with different header values than the originally cached request; cache hit logs for resources that should never be reused (Vary: * responses).
• Application Behavior: Users receiving responses containing data belonging to other users (e.g., wrong session content, foreign user profile data); cache entries persisting for endpoints that should always be fetched fresh.
• Dependency Audit: Presence of http-cache-semantics version ≤ 4.2.0 in node_modules or package-lock.json of Node.js applications using shared caching (GitHub Issue).

The recommended fix is to update http-cache-semantics to a version that includes the security patch addressing the _varyMatches() logic (see GitHub Advisory for the patched version once released). As a workaround, consumers of the library can canonicalize the Vary header value to a bare * before storing responses, and reject responses whose Vary field names are not simple tokens. Developers should also guard per-field header lookups with Object.prototype.hasOwnProperty.call(req.headers, name) or use null-prototype maps to prevent prototype chain collisions. Monitor application logs for anomalous cache-hit patterns on user-specific resources (GitHub Issue, Red Hat Bugzilla).

Red Hat has tracked this vulnerability via their security response process (Bugzilla bug 2538846) and classified it as medium severity (Red Hat Bugzilla). Microsoft has also acknowledged the vulnerability through their Security Response Center (Microsoft MSRC). The vulnerability was reported by researcher waydeshio via a detailed GitHub issue with a clear technical write-up and PoC, and has been picked up by standard vulnerability tracking feeds including VulnDB and Tenable Nessus (detection ID 348653) (GitHub Issue).