GHSA-gq3j-xvxp-8hrf

What it actually does

Hono's basicAuth and bearerAuth middleware compared supplied credentials with expected secrets using non-constant-time string comparison. An observer who can measure many authentication responses may distinguish matching versus non-matching prefixes of a password or bearer token from small latency differences, weakening the secrecy of those credentials. The issue is a cryptographic side channel, not remote code execution, injection, or authentication bypass by itself. Impact is limited to endpoints that use these middlewares and to secrets compared in that path. Network jitter, rate limits, and short-circuiting elsewhere in the stack often reduce practical leak rate.

Why it matters to the business

Practical risk is low for most internet-facing apps: CVSS is 3.7, exploit maturity is none, the issue is not in KEV, and no ransomware use is reported. A successful campaign would still require high-volume probing against a live login or API token check and would more often look like credential stuffing than a one-shot breach. Residual concern is concentrated where Hono protects high-value admin APIs, long-lived bearer tokens, or shared basic-auth secrets, and where npm lockfiles pin hono below 4.11.10. Failure to patch mainly increases exposure to slow credential recovery rather than immediate outage or data-destruction events.

How an attack unfolds

An attacker identifies an HTTP endpoint protected by Hono basicAuth or bearerAuth. They send large numbers of authentication requests while varying one character (or byte) of the password or token at a time and recording response latency and status. Statistical comparison of timings is used to infer which prefix is closer to the stored secret. The process is repeated until a usable credential is recovered, after which the attacker authenticates normally. Success depends on low-noise timing, absence of lockouts, and the secret being compared directly in the vulnerable middleware. No public weaponization or named threat-actor use is indicated.

How to fix it

Upgrade the hono npm package to 4.11.10 or later, which adds timing-safe comparison in basicAuth and bearerAuth. Rebuild and redeploy so production lockfiles and container images no longer resolve an affected version. If an immediate upgrade is blocked, mitigate by putting authentication behind a constant-time verifier of your own, enabling strict rate limiting and account lockout on 401s, preferring short-lived tokens over static basic-auth secrets, and terminating auth at a gateway that does not exhibit the same comparison behavior. Rotate any long-lived basic-auth passwords or bearer tokens that were compared by unpatched middleware.

How to confirm the fix worked

Inspect package-lock.json, yarn.lock, or pnpm-lock.yaml and confirm hono is 4.11.10 or newer in every deployed artifact. In CI, fail builds that resolve hono < 4.11.10. After deploy, exercise basicAuth and bearerAuth success and failure paths and confirm the running process loads the patched package (for example via npm ls hono). Code review should show credential comparison going through a constant-time primitive rather than early-exit string equality. Do not attempt to validate by running a timing exploit against production.

Typical attack path

1. Locate an application using Hono basicAuth or bearerAuth on a reachable HTTP endpoint.
2. Confirm authentication failures return distinguishable responses without aggressive lockout.
3. Submit many crafted Authorization (Basic or Bearer) requests while measuring response latency.
4. Use timing differences to infer successive bytes of the compared secret.
5. Authenticate with the recovered credential and access whatever the middleware was meant to protect.

How to detect it

Timing-based credential recovery leaves no distinctive payload and is unlikely to appear as a named exploit in EDR. Hunt instead for high-volume authentication failures against Hono-protected routes: bursts of HTTP 401 from a single client to endpoints that use Basic or Bearer auth, slowly changing Authorization header values, and unusually uniform request spacing consistent with measurement rather than interactive login. Review access and reverse-proxy logs around those endpoints, WAF or API-gateway auth metrics, and application logs that record middleware auth failures. Correlate with later successful logins from the same source using previously unseen credentials. Absence of such patterns does not prove the side channel was unused, only that noisy brute-force-style probing was not observed.

What your security team should do

• Inventory all services that depend on the hono npm package and identify those using basicAuth or bearerAuth.
• Upgrade hono to 4.11.10 or later and ship the change through the normal release pipeline.
• Rotate static basic-auth secrets and long-lived bearer tokens that were verified on unpatched versions.
• Enforce authentication rate limits, anomaly detection on repeated 401s, and lockouts where product constraints allow.
• Add a dependency-policy or SCA rule that flags hono versions below 4.11.10.
• Treat remaining exposure as a credential-hardening issue rather than an emergency KEV-style outage.