Listen to this Post
The vulnerability arises from an oversight in Hono’s Cache Middleware component, specifically within the `httpCache` function. The middleware is responsible for storing and serving cached HTTP responses. When a response is generated, the middleware checks for certain headers—such as Cache-Control: private, no-store, no-cache, or the presence of a `Set-Cookie` header—and correctly skips caching when these are present. However, it fails to treat the `Vary: Authorization` and `Vary: Cookie` headers as cache-skip signals, as recommended by RFC 9110 and RFC 9111 for per-user content. Consequently, if a developer relies on these `Vary` headers to differentiate responses for authenticated users (e.g., a response that depends on a user’s specific ID or roles), the middleware will still cache the response using a key that is only based on the URL. This means that the first user’s response, complete with their personal data, is stored in a shared cache. When a second user makes a request to the same endpoint but with their own `Authorization` or `Cookie` header, the middleware does not consider these headers in its cache lookup and erroneously serves the first user’s cached response to the second user. This effectively bypasses the intended per-user caching separation, leading to a cache poisoning and information disclosure scenario. The issue is fixed in Hono version 4.12.18, where the middleware now includes the values of `Authorization` and `Cookie` headers in the cache key, ensuring each authenticated user receives their own isolated cache entry.
DailyCVE Form:
Platform: Hono
Version: 4.0.0 – 4.12.16
Vulnerability: Information Disclosure
Severity: Medium
Date: 2024-08-29
Prediction: 2024-09-29
Analytics under What Undercode Say:
Simulate a vulnerable cache response with Vary: Authorization curl -X GET https://api.example.com/user/profile -H "Authorization: Bearer user123" Another user requests the same URL with a different auth token curl -X GET https://api.example.com/user/profile -H "Authorization: Bearer user456" (The second user may receive the first user's cached data) Check cache headers in response curl -I https://api.example.com/user/profile -H "Authorization: Bearer user123"
Exploit:
An attacker can force a victim to make a request to a vulnerable endpoint that caches responses based only on the URL. They then make the same request with their own credentials. If the cache middleware does not incorporate `Authorization` or `Cookie` headers into its cache key, they will receive the victim’s cached response, potentially exposing sensitive data.
Protection from this CVE:
To mitigate this issue, upgrade Hono to version 4.12.18 or later. In this version, the `CacheMiddleware` automatically includes `Authorization` and `Cookie` header values in the cache key, isolating per-user responses. If immediate upgrade is not possible, set `Cache-Control: private` on all user-specific endpoints to prevent caching at the shared cache level.
Impact:
Successful exploitation leads to the disclosure of personally identifiable information (PII) and other user-specific data. An attacker can view another user’s private profile information, session data, or any content that varies per user. This can result in serious privacy breaches, account takeover, and unauthorized access to user-specific resources.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
