CVE-2026-39407

What it actually does

Hono versions prior to 4.12.12 contain a path handling inconsistency between route matching middleware and serveStatic. Authorization middleware bound to protected route patterns such as /admin/* can fail to match request paths containing repeated slashes, while serveStatic normalizes or resolves those same paths to the intended static file location. As a result, an unauthenticated remote attacker may bypass route-based access controls and read static files that were intended to be protected. The impact is limited to confidentiality of exposed static content; the vulnerability does not directly provide code execution, data modification, or denial of service.

Why it matters to the business

Applications using Hono to serve protected static files may unintentionally expose sensitive files such as admin assets, internal documents, configuration-adjacent artifacts, or bundled application content. Although the CVSS and EPSS values indicate moderate severity and currently low observed exploitation likelihood, the issue is remotely exploitable without authentication and is easy to test, so internet-facing applications should be reviewed and upgraded. The issue is not listed in CISA KEV and is not currently associated with ransomware campaigns.

How an attack unfolds

An attacker first identifies a Hono-based application that serves static files behind route-specific authorization middleware, for example middleware applied only to /admin/* or a similar protected path. The attacker then requests protected static resources using repeated slashes in the URL path. Because the router and middleware matching logic may treat the repeated-slash path differently from the static file resolver, the authorization middleware may not execute, while serveStatic still resolves the request to the normalized protected file path. If the target file exists and is served by serveStatic, the attacker receives the file contents without satisfying the expected authorization check.

How to fix it

Upgrade Hono to version 4.12.12 or later. If Hono is brought in transitively, update the top-level dependency or lockfile so the resolved Hono package is at least 4.12.12. As a defense-in-depth measure, avoid relying solely on route-pattern middleware to protect static files; enforce authorization inside the static file handling path or place sensitive files outside the web-served directory. Normalize and reject malformed paths containing repeated slashes before routing, and configure upstream proxies or web servers to normalize or block such requests consistently. Review deployments for any protected static directories exposed through serveStatic and confirm they are not reachable without authentication.

How to confirm the fix worked

Confirm the deployed Hono package version is 4.12.12 or newer using the package manager lockfile, runtime dependency inventory, or software composition analysis tooling. Test affected routes by requesting known protected static resources with repeated slashes in multiple positions and verify the response remains 401, 403, or the intended authenticated behavior rather than returning file content. Compare behavior before and after upgrade for paths such as /protected/file, /protected//file, and //protected/file. Add automated regression tests for protected static paths containing repeated slashes to ensure authorization middleware cannot be bypassed in future changes.

Typical attack path

1. Identify a Hono application or JavaScript service exposing static content over HTTP.
2. Probe for protected static paths such as admin, private, protected, internal, or assets directories.
3. Send requests that insert repeated slashes into the path, such as /admin//file or //admin/file.
4. Observe whether responses differ from the normally protected path, especially 200 responses where 401, 403, or redirect responses are expected.
5. Enumerate accessible static filenames and download any exposed content.
6. Use exposed files to support further reconnaissance, credential discovery, application mapping, or targeted attacks.

How to detect it

To determine whether exploitation has already occurred, review HTTP access logs, application logs, CDN/WAF logs, reverse proxy logs, and load balancer logs for requests containing repeated slashes in the URL path, especially targeting protected static directories. Focus on unauthenticated requests that returned HTTP 200, 206, or unusually large response sizes where the normal path would return 401, 403, or a login redirect. Compare user agent, source IP, request path, status code, response size, and authentication context. Investigate bursts of repeated-slash probes across common protected prefixes such as admin, private, protected, internal, static, assets, or files. If sensitive static content was exposed, correlate subsequent activity from the same source addresses for credential use, administrative probing, or access to newly discovered endpoints. There are no known public threat actors or ransomware campaigns associated with this vulnerability based on the provided information.

• GET //admin/
• GET /admin//
• POST //admin/
• GET //private/
• GET /private//
• GET //protected/
• GET /protected//
• GET //internal/
• GET /internal//
• GET //static/
• GET /static//
• GET //assets/
• GET /assets//
• GET //files/
• GET /files//
• "GET //*"
• "GET /*//*"
• " 200 " with request path containing "//admin/"
• " 200 " with request path containing "/admin//"
• " 200 " with request path containing "//private/"
• " 200 " with request path containing "/private//"
• " 200 " with request path containing "//protected/"
• " 200 " with request path containing "/protected//"

What your security team should do

• Inventory applications and services using Hono, especially internet-facing JavaScript APIs or edge applications that serve static files.
• Prioritize upgrade of Hono to 4.12.12 or later for applications using serveStatic with route-based authorization middleware.
• Search access logs for repeated-slash requests to protected static path prefixes and investigate any successful 200 responses.
• Review static file placement and move sensitive content outside publicly served directories wherever possible.
• Add application-layer or proxy-layer path normalization and rejection rules for ambiguous paths containing repeated slashes.
• Create regression tests that verify protected static content remains inaccessible when paths contain repeated slashes.
• Monitor dependency scanners for downstream packages that bundle or pin vulnerable Hono versions.