CVE-2026-47676

What it actually does

Hono versions prior to 4.12.21 contain an input canonicalization flaw in app.mount(). The mounted route prefix is stripped using the raw URL pathname, while route matching is performed on the percent-decoded pathname. When a request path contains percent-encoded multi-byte characters, these two representations can have different lengths or character boundaries, causing Hono to remove the prefix at the wrong offset before forwarding the request to the mounted sub-application. The most likely technical consequence is incorrect request routing or exposure of routes within a mounted application that were not intended to be reachable through that external path. The CVSS vector indicates network exploitability without authentication or user interaction, with limited confidentiality impact and no direct integrity or availability impact.

Why it matters to the business

Applications using Hono mounted sub-applications may unintentionally expose endpoints or content because specially crafted URLs can be interpreted differently by the framework than developers expect. In practical terms, this can lead to unauthorized access to low-sensitivity data, unexpected behavior in API gateways or nested applications, and increased risk where mounted apps rely on path structure for access separation. The issue is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploitation signal, so it is generally a patch-priority issue rather than an emergency response item unless the application uses app.mount() for security boundaries or sensitive internal routes.

How an attack unfolds

An attacker sends an unauthenticated HTTP request to a Hono application that uses app.mount() to delegate a URL prefix to a mounted sub-application. The attacker places percent-encoded multi-byte characters in or near the mounted prefix portion of the path. Hono first matches routes against the decoded path, but app.mount() strips the prefix from the raw, encoded pathname. Because the raw and decoded paths do not align byte-for-byte, the prefix can be removed at an incorrect position. The mounted sub-application then receives a path different from the one the developer intended, potentially causing it to resolve a route, static asset, or handler that should not have been reachable through that external URL. Successful exploitation depends on the application’s route layout and whether mounted paths protect or segment sensitive functionality.

How to fix it

Upgrade Hono to version 4.12.21 or later. If dependency pinning is used, ensure the resolved package version is actually 4.12.21 or newer in the lockfile and deployed artifact. Rebuild and redeploy applications after upgrading. As interim mitigation, avoid relying on app.mount() path boundaries as a security control, especially for sensitive routes; place authentication and authorization checks inside the mounted sub-application as well as at the parent application layer. Consider rejecting or normalizing suspicious percent-encoded multi-byte characters in path prefixes at an upstream proxy or edge layer if immediate upgrade is not possible, but treat this only as a temporary compensating control.

How to confirm the fix worked

Confirm exposure by checking whether deployed applications use Hono versions earlier than 4.12.21 and whether app.mount() is used. Validate remediation by inspecting package manager output and lockfiles to confirm Hono resolves to 4.12.21 or later, then run routing tests with percent-encoded multi-byte characters around mounted prefixes to verify that mounted sub-applications receive the expected path. Include regression tests that compare routing behavior for raw encoded paths and decoded Unicode-equivalent paths. For production validation, review access logs for encoded UTF-8 path probes and confirm they no longer trigger unexpected handlers or responses after upgrade.

Typical attack path

1. Identify a public Hono application or API that uses mounted sub-applications through app.mount().
2. Map visible route prefixes and infer mounted application boundaries from responses, redirects, error messages, or route behavior.
3. Send crafted requests containing percent-encoded multi-byte UTF-8 sequences in or near the mount prefix.
4. Observe whether the application routes the request inconsistently, returns unexpected handlers, or exposes content from the mounted sub-application.
5. Refine encoded path payloads to reach routes or assets that are normally hidden, misrouted, or intended to be protected by path-based separation.
6. Extract any accessible data or application behavior exposed through the incorrectly forwarded path.

How to detect it

Review HTTP access logs, CDN/WAF logs, reverse proxy logs, and application request logs for requests containing percent-encoded multi-byte UTF-8 sequences, especially against paths that correspond to mounted sub-applications. Focus on unusual 200, 30x, or nonstandard responses for URLs that should normally return 404 or be blocked. Look for repeated probing with variations of encoded Unicode bytes around known mount prefixes, followed by successful access to routes, static files, or API responses in the mounted application. If application logs include route handler names or matched routes, compare the externally requested path with the route ultimately handled by the mounted application; mismatches may indicate attempted or successful exploitation. Because this vulnerability is routing-logic dependent and has no universal post-exploitation artifact, detection should emphasize abnormal encoded-path requests and unexpected handler resolution rather than host-level indicators.

• %E0%
• %E1%
• %E2%
• %E3%
• %E4%
• %E5%
• %E6%
• %E7%
• %E8%
• %E9%
• %EA%
• %EB%
• %EC%
• %ED%
• %EE%
• %EF%
• %F0%
• %F1%
• %F2%
• %F3%
• %F4%
• %C2%
• %C3%
• app.mount(

What your security team should do

• Inventory applications and services using the Hono framework, prioritizing internet-facing APIs and edge/serverless deployments.
• Identify code paths using app.mount(), especially where mounted route prefixes separate public, private, admin, internal, static, or tenant-scoped functionality.
• Upgrade Hono to 4.12.21 or later and verify the deployed lockfile/runtime artifact uses the fixed version.
• Add application-level authorization inside mounted sub-applications rather than depending only on parent path prefixes for access control.
• Add regression tests for percent-encoded multi-byte paths around mount prefixes.
• Search historical web access logs for encoded multi-byte path probing against Hono services.
• If immediate patching is delayed, apply temporary edge filtering or normalization for suspicious encoded path patterns near sensitive mount prefixes.