CVE-2026-69207

What it actually does

Hono versions prior to 4.12.34 contain a regular expression denial-of-service flaw in the built-in CORS middleware, hono/cors. When cors() is used with allowHeaders unset or empty, the middleware processes the attacker-controlled Access-Control-Request-Headers value during CORS preflight OPTIONS requests using a whitespace-tolerant regular expression with quadratic backtracking behavior. A long header value containing excessive whitespace can consume significant CPU time. In single-threaded or event-loop-based JavaScript runtimes, this can block the request-processing thread and delay or stall unrelated concurrent requests. The flaw affects availability only; it does not directly allow data disclosure, authentication bypass, or code execution.

Why it matters to the business

Public web services using vulnerable Hono CORS middleware can be made slow or temporarily unavailable by unauthenticated network requests. Because exploitation requires only crafted HTTP preflight requests and no credentials, internet-facing APIs and applications may experience degraded user experience, failed transactions, missed service-level objectives, increased infrastructure load, and operational incidents. The issue is recently published, is not currently listed in CISA KEV, and has no reported mature exploitation in the provided data, but remediation should still be prioritized for exposed services because denial-of-service conditions can be triggered cheaply and repeatedly.

How an attack unfolds

An attacker identifies an application or API built with Hono that uses the default or vulnerable CORS configuration where cors() is enabled and allowHeaders is unset or empty. The attacker sends an HTTP OPTIONS preflight request containing an Access-Control-Request-Headers header with a very long sequence of whitespace or whitespace-heavy content. The vulnerable regular expression attempts to parse the header and enters expensive backtracking behavior, causing CPU consumption that grows quadratically with the header length. If the runtime processes requests on a shared event loop or single execution thread, that one request can delay other requests. By sending repeated crafted preflight requests, the attacker can keep the service CPU-bound and make the application slow or unresponsive.

How to fix it

Upgrade Hono to version 4.12.34 or later wherever hono/cors is used. If immediate upgrade is not possible, configure cors() with a non-empty allowHeaders value so the vulnerable parsing path is not reached. Also consider enforcing conservative maximum HTTP header sizes at the reverse proxy, load balancer, CDN, or application server; rate-limit OPTIONS requests; and apply request timeouts or WAF rules for abnormal Access-Control-Request-Headers values with excessive whitespace. These mitigations reduce exposure but should not replace upgrading to the fixed version.

How to confirm the fix worked

Confirm package manifests and lockfiles resolve Hono to version 4.12.34 or later. Review application code for imports or usage of hono/cors and verify that any remaining older deployments either do not use cors() or explicitly set a non-empty allowHeaders option. Test exposed endpoints by sending normal CORS preflight requests and confirming expected behavior. For defensive validation, send a controlled long whitespace-heavy Access-Control-Request-Headers value in a non-production or authorized test environment and verify it no longer causes elevated CPU, long response times, event-loop stalls, or worker saturation. Also confirm upstream controls reject or limit oversized headers as intended.

Typical attack path

1. Discover an internet-facing Hono-based web application or API endpoint that responds to CORS preflight requests.
2. Send an OPTIONS request with CORS-related headers, including Origin and Access-Control-Request-Method, to reach the CORS middleware path.
3. Include an Access-Control-Request-Headers header containing an unusually long whitespace-heavy value.
4. Trigger excessive regular expression backtracking in vulnerable hono/cors middleware when allowHeaders is unset or empty.
5. Repeat requests, potentially from one or more clients, to consume CPU and block or delay normal request processing.
6. Cause service latency, timeouts, or temporary unavailability for legitimate users.

How to detect it

Review HTTP access logs, reverse proxy logs, CDN/WAF logs, and application logs for unusual volumes of OPTIONS requests, especially requests containing Origin, Access-Control-Request-Method, and very large or whitespace-heavy Access-Control-Request-Headers values. Correlate these requests with spikes in CPU utilization, event-loop lag, worker saturation, request latency, upstream timeout errors, and increased 5xx or 499/504 responses. Look for repeated preflight requests from the same IP address, autonomous system, user agent, or distributed sources with similar header structure. In application telemetry, investigate slow request traces where the route is an OPTIONS request and time is spent before normal route handling. Because exploitation may leave no file artifact, network and HTTP-layer telemetry are the primary evidence sources.

• OPTIONS requests with unusually large Access-Control-Request-Headers header values
• Access-Control-Request-Headers header containing long runs of spaces or tabs
• Access-Control-Request-Headers:
• Repeated HTTP OPTIONS requests including both Origin and Access-Control-Request-Method headers
• Spikes in OPTIONS request volume followed by elevated CPU utilization
• HTTP 504 responses correlated with OPTIONS preflight requests
• HTTP 503 responses correlated with OPTIONS preflight requests
• upstream timed out while reading response header from upstream
• request header too large
• 431 Request Header Fields Too Large

What your security team should do

• Inventory applications and services using Hono, especially internet-facing APIs and serverless or single-threaded JavaScript runtimes.
• Prioritize upgrading Hono to 4.12.34 or later in all affected services.
• Search code for hono/cors usage with cors() where allowHeaders is unset, omitted, empty, or dynamically empty.
• Apply temporary mitigations: set a non-empty allowHeaders list, reduce maximum header size, rate-limit OPTIONS requests, and block anomalously whitespace-heavy Access-Control-Request-Headers values.
• Monitor application latency, CPU saturation, event-loop delay, 4xx/5xx rates, and spikes in OPTIONS requests while patches are rolling out.
• Add regression tests for CORS preflight handling with large or malformed Access-Control-Request-Headers values.
• Because this is newly published, track package advisories and exploit telemetry for changes in exploitation maturity or active abuse.