CVE-2026-44457

What it actually does

Hono versions prior to 4.12.18 contain an information disclosure flaw in the Cache Middleware. The middleware can cache authenticated or personalized HTTP responses even when the response includes `Vary: Authorization` or `Vary: Cookie`, headers that indicate the response depends on user-specific credentials or cookies. Because the cache key does not properly account for these per-user variance signals, content generated for one user may be returned to another user who later requests the same resource. The flaw does not directly allow code execution, data modification, or service disruption, but it can expose sensitive user-specific application data through incorrect cache reuse.

Why it matters to the business

Applications using affected Hono Cache Middleware may unintentionally disclose one user’s private information to another user. Depending on what the cached routes return, this could expose account details, profile data, session-dependent content, API responses, or other confidential business information. The CVSS score indicates moderate severity, EPSS is currently low, and it is not listed in CISA KEV, but the issue is important for any application that caches authenticated responses because exploitation is network-accessible, low-complexity, and does not require attacker privileges if the vulnerable route is reachable.

How an attack unfolds

An attacker identifies a Hono-based application using the vulnerable Cache Middleware on routes that return personalized content. A legitimate or victim user first requests a cacheable authenticated endpoint, causing the application to generate a response containing user-specific data and headers such as `Vary: Authorization` or `Vary: Cookie`. In vulnerable versions, the middleware may still store that response in a shared cache instead of skipping caching or varying the cache entry by credential-bearing headers. The attacker then sends a request for the same URL, potentially without the same authorization token or cookie, and receives the cached response originally generated for another user. The attacker can repeat this across predictable endpoints to collect data accidentally served from cache. There is no public exploit maturity indicated, but the exploitation logic is straightforward wherever affected caching behavior is exposed.

How to fix it

Upgrade Hono to version 4.12.18 or later. If exact package management is used, update the `hono` dependency so the resolved installed version is at least `4.12.18`, regenerate lockfiles, rebuild, and redeploy affected services. Review all uses of Hono Cache Middleware, especially on authenticated routes, and ensure personalized responses are not stored in shared caches. As a defense-in-depth measure, disable caching for routes that depend on `Authorization`, `Cookie`, session state, or user identity; use `Cache-Control: private, no-store` where appropriate; and purge any shared cache entries that may contain personalized content. If upstream reverse proxies, CDNs, or service-worker caches are present, verify they also respect credential-based variance and do not cache authenticated responses incorrectly.

How to confirm the fix worked

Confirm that all deployed Hono applications resolve to version 4.12.18 or later using package manager inspection such as `npm ls hono`, `pnpm why hono`, `yarn why hono`, lockfile review, or software composition analysis. Test affected routes by making the same request path with two different users or authorization contexts and verifying that responses are not shared across users. Specifically test endpoints that return `Vary: Authorization` or `Vary: Cookie` and confirm the Cache Middleware skips caching or produces distinct behavior that prevents cross-user disclosure. Inspect response headers for safe caching directives on authenticated content, such as `Cache-Control: private` or `no-store`, and confirm shared caches have been purged after remediation.

Typical attack path

1. Identify an application or API built with Hono and using Cache Middleware.
2. Find routes that return user-specific or authenticated content and are configured for caching.
3. Trigger or wait for a victim or legitimate user to request a target route, causing their personalized response to be cached.
4. Request the same route using a different session, different credentials, or no credentials depending on application behavior.
5. Observe whether the response contains another user’s data, account context, or session-dependent content.
6. Repeat requests against other cacheable authenticated endpoints to enumerate additional exposed data.

How to detect it

To determine whether the issue was already exploited, review application, reverse proxy, CDN, and edge-cache logs for cache hits on endpoints that require authentication or return personalized data. Focus on routes served by Hono Cache Middleware before the upgrade to 4.12.18. Look for the same URL being requested by different users, sessions, source IPs, authorization contexts, or cookie values with cache-hit responses and identical response sizes or ETags. Investigate responses on authenticated endpoints where request headers include `Authorization` or `Cookie` and response headers include `Vary: Authorization` or `Vary: Cookie`, especially if the response was still served from cache. Search for suspicious enumeration patterns such as one client repeatedly requesting many authenticated URLs shortly after other users accessed them. If detailed response logging or WAF body capture exists, compare whether user identifiers, account names, email addresses, or tenant-specific content in responses do not match the requester’s authenticated identity. Also review CDN/proxy cache analytics for unexpectedly high hit ratios on authenticated routes.

• Vary: Authorization
• Vary: Cookie
• Authorization: Bearer
• Cookie:
• Cache-Control: public
• Cache-Control: max-age
• X-Cache: HIT
• X-Cache: Hit
• CF-Cache-Status: HIT
• Age:
• hono
• node_modules/hono
• "hono"
• "version": "4.12.17"
• "version": "4.12.16"
• "version": "4.12.15"

What your security team should do

• Prioritize upgrading Hono to 4.12.18 or later in all applications using Cache Middleware.
• Inventory Hono services and identify routes where Cache Middleware is applied to authenticated, cookie-based, or personalized responses.
• Temporarily disable Cache Middleware or bypass caching on user-specific routes until upgrades are deployed and validated.
• Purge application, proxy, CDN, and edge caches that may have stored personalized responses from vulnerable versions.
• Add regression tests that request the same cached endpoint with different users and fail if cross-user content is returned.
• Review access logs for repeated requests to authenticated cacheable endpoints from different sessions or clients that received identical response sizes or cache-hit behavior.
• Update secure coding guidance to prohibit shared caching of responses dependent on `Authorization`, `Cookie`, or session state unless cache keys are explicitly isolated per user.