The Infinite Fallback: How Hono Leaked Your Cloudflare KV Keys

Serverless environments like Cloudflare Workers are brilliant for compute, but they are notoriously awkward when it comes to the simple act of serving a JPEG. You don't have a filesystem. You have a distributed Key-Value (KV) store that pretends to be a filesystem. Enter Hono, the lightweight framework designed to make this headache go away.

Hono's serve-static middleware is the bridge. It takes a URL request (like /images/logo.png), looks up that path in a generated ASSET_MANIFEST (a JSON map created at build time), and finds the corresponding unique key in the KV store (something like logo.a1b2c3d4.png). It’s a clean, efficient abstraction.

But here is the rub: abstractions leak. When you rely on a middleware to decide what is public and what is private based solely on a lookup table, the logic governing that lookup had better be bulletproof. In CVE-2026-24473, that logic was about as bulletproof as a wet paper towel.

The vulnerability resides in the classic developer impulse to be 'helpful' or 'flexible'. In the Cloudflare Workers adapter, the code needs to translate a request path into a KV key. The developers anticipated a scenario where a user might request a path that exactly matches a KV key, even if it wasn't explicitly listed in the build-time manifest.

So, they implemented a fallback. If the requested path wasn't found in the ASSET_MANIFEST, the code shrugged and said, "Eh, maybe the path is the key?" and tried to fetch it anyway. This turned the middleware from a strict whitelist (only serve what is in the manifest) into a 'try everything' proxy.

This is a textbook example of fail-open logic. By allowing the raw user input to be used directly as a lookup key for the storage backend, the application implicitly trusted that the user would only ask for things they were supposed to see. In the security world, we call this 'optimism', and it is usually fatal.

Let's look at the smoking gun. The vulnerability lived in src/adapter/cloudflare-workers/utils.ts. It’s almost poetic how small the bug is.

// The Vulnerable Logic
export const getContentFromKVAsset = async (
  path: string,
  options?: Partial<ServeStaticOptions>
) => {
  const ASSET_MANIFEST = options?.manifest || __STATIC_CONTENT_MANIFEST
  
  // HERE IS THE BUG:
  const key = ASSET_MANIFEST[path] || path
  
  if (!key) {
    return null
  }
  // ... fetch content from KV using 'key' ...
}

Do you see it? const key = ASSET_MANIFEST[path] || path. That double pipe || operator is doing a lot of heavy lifting. It says: "If the path is in the manifest, use the mapped key. Otherwise, just use the path itself."

An attacker requests /secrets.json. The manifest obviously doesn't have an entry for /secrets.json. The code evaluates ASSET_MANIFEST['/secrets.json'], gets undefined, hits the || operator, and sets key to '/secrets.json'. It then happily queries the KV store for that key. If your build process accidentally uploaded a config file to the KV store, or if you share the KV namespace with other application logic, Hono just served it on a silver platter.

Exploiting this requires a bit of guessing, but in the world of Cloudflare Workers, namespaces are often reused to save money or simplify config. A developer might create a single KV namespace called MY_APP_DATA and throw everything in there: static assets, session data, and feature flags.

The Attack Chain:

1. Recon: The attacker notices the site is running Hono on Cloudflare (headers or behavior usually give this away).
2. Fuzzing: The attacker starts requesting common filenames that shouldn't be public but might exist in a backend storage context: .env, config.json, manifest.json, __STATIC_CONTENT_MANIFEST.
3. Execution: The attacker sends GET /config.json.
   • The middleware checks the legitimate asset manifest. It's not there.
   • The middleware falls back to using config.json as the KV key.
   • The Cloudflare runtime returns the value associated with that key.

This bypasses the entire concept of the ASSET_MANIFEST acting as an access control list. It essentially turns the serve-static middleware into a generic Key-Value gateway for anyone with a web browser.

The fix is as simple as the bug. The Hono team removed the fallback logic. If it's not in the manifest, it doesn't exist. Period.

Here is the diff from commit cf9a78db4d0a19b117aee399cbe9d3a6d9bfd817:

--- a/src/adapter/cloudflare-workers/utils.ts
+++ b/src/adapter/cloudflare-workers/utils.ts
@@ -36,7 +36,7 @@ export const getContentFromKVAsset = async (
     ASSET_NAMESPACE = __STATIC_CONTENT
   }
 
-  const key = ASSET_MANIFEST[path] || path
+  const key = ASSET_MANIFEST[path]
   if (!key) {
     return null
   }

By removing || path, the variable key becomes undefined if the lookup fails. The subsequent check if (!key) return null triggers, and the request harmlessly 404s. This restores the 'Default Deny' posture that security components should have had from the start.