CVE-2026-126355: Cross-Site Request Forgery Protection Bypass via Hyperlink Auditing in Hono

Hono is a lightweight web application framework designed for JavaScript runtimes, including Cloudflare Workers, Fastly Compute, Deno, Bun, AWS Lambda, and Node.js. It provides built-in middleware modules to handle common security controls, including Cross-Site Request Forgery (CSRF) protection via the hono/csrf package. The csrf() middleware is responsible for inspecting incoming state-changing HTTP requests and rejecting unauthorized cross-origin submissions before they reach application route handlers.

In versions prior to 4.13.16, the csrf() middleware contains a validation bypass classified under CWE-352 (Cross-Site Request Forgery). When evaluating incoming requests, the middleware filters requests by HTTP method and Content-Type header before verifying the Origin and Sec-Fetch-Site headers. The regular expression responsible for matching Content-Type headers only accounted for the three MIME types historically associated with HTML <form> submissions: application/x-www-form-urlencoded, multipart/form-data, and text/plain.

This filtering logic failed to account for HTML5 hyperlink auditing, a browser feature invoked via the ping attribute on HTML anchor (<a>) elements. When a user clicks an anchor tag containing a ping attribute in a Chromium-based browser, the browser dispatches an asynchronous HTTP POST request with Content-Type: text/ping to the specified destination without performing a Cross-Origin Resource Sharing (CORS) preflight (OPTIONS) check.

Because text/ping did not match Hono's Content-Type regular expression, the csrf() middleware treated the request as non-CSRF-capable and skipped Origin and Sec-Fetch-Site validation entirely. Consequently, an attacker can induce an authenticated user to click a link on an external site and trigger unauthorized state-changing operations on vulnerable Hono endpoints.

The root cause of CVE-2026-126355 is an incomplete regular expression allowlist in src/middleware/csrf/index.ts that relies on the assumption that only CORS-safelisted form MIME types can be sent cross-origin without triggering a preflight check. Under the WHATWG Fetch standard, browsers enforce a CORS OPTIONS preflight for cross-origin requests unless the request qualifies as a "simple request" using methods GET, HEAD, or POST alongside application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Based on this specification, Hono's CSRF middleware assumed that any cross-origin POST request carrying a different Content-Type (such as application/json) would require a CORS preflight, which the server would reject unless explicitly permitted by CORS policy. Therefore, Hono selectively enforced origin verification only when isRequestedByFormElementRe matched the incoming Content-Type header:

However, the HTML specification defines hyperlink auditing outside the standard fetch() and XMLHttpRequest request pipelines. When an anchor element includes a ping attribute (<a href="..." ping="https://target.example/api/action">), compliant browsers transmit a background POST request with the static payload PING and the header Content-Type: text/ping. Because this request is initiated directly by browser navigation mechanics rather than client-side JavaScript, the browser does not execute a CORS preflight request.

When this text/ping request arrived at a Hono server prior to version 4.13.16, the middleware first confirmed the method was not GET, HEAD, or OPTIONS. It then evaluated isRequestedByFormElementRe.test('text/ping'), which returned false. Because the conditions inside the if statement were joined by logical AND (&&) operators, the expression short-circuited to false, bypassing both isAllowedSecFetchSite() and isAllowedOrigin() and passing execution directly to await next().

In Hono versions < 4.13.16, the CSRF middleware implementation in src/middleware/csrf/index.ts defined the regular expression isRequestedByFormElementRe to identify requests requiring CSRF protection:

const isSafeMethodRe = /^(GET|HEAD|OPTIONS)$/
// VULNERABLE: Only matches standard HTML form Content-Types, omitting text/ping
const isRequestedByFormElementRe =
  /^\b(application\/x-www-form-urlencoded|multipart\/form-data|text\/plain)\b/i
 
export const csrf = (options?: CSRFOptions): MiddlewareHandler => {
  return async function csrf(c, next) {
    if (
      !isSafeMethodRe.test(c.req.method) &&
      // Short-circuits to false when Content-Type is 'text/ping'
      isRequestedByFormElementRe.test(c.req.header('content-type') || 'text/plain') &&
      !(await isAllowedSecFetchSite(c.req.header('sec-fetch-site'), c)) &&
      !(await isAllowedOrigin(c.req.header('origin'), c))
    ) {
      return c.text('Forbidden', 403)
    }
    await next()
  }
}

In commit bf16471913b5199212dac33f5d170f94745dd26a (released in v4.13.16), the maintainers renamed isRequestedByFormElementRe to isCsrfContentTypeRe and updated the regular expression non-capturing group under the text/ prefix to match both plain and ping:

File: src/middleware/csrf/index.ts
@@ -26,8 +26,8 @@ interface CSRFOptions {
 }
 
 const isSafeMethodRe = /^(GET|HEAD|OPTIONS)$/
-const isRequestedByFormElementRe =
-  /^\b(application\/x-www-form-urlencoded|multipart\/form-data|text\/plain)\b/i
+const isCsrfContentTypeRe =
+  /^\b(application\/x-www-form-urlencoded|multipart\/form-data|text\/(?:plain|ping))\b/i
 
 /**
  * CSRF Protection Middleware for Hono.
@@ -138,7 +138,7 @@ export const csrf = (options?: CSRFOptions): MiddlewareHandler => {
   return async function csrf(c, next) {
     if (
       !isSafeMethodRe.test(c.req.method) &&
-      isRequestedByFormElementRe.test(c.req.header('content-type') || 'text/plain') &&
+      isCsrfContentTypeRe.test(c.req.header('content-type') || 'text/plain') &&
       !(await isAllowedSecFetchSite(c.req.header('sec-fetch-site'), c)) &&
       !(await isAllowedOrigin(c.req.header('origin'), c))
     ) {

The regular expression uses the leading word boundary anchor ^\b and trailing word boundary \b with the case-insensitive flag i. This ensures that text/ping, Text/Ping, and parameterized headers such as text/ping; charset=utf-8 all match isCsrfContentTypeRe and proceed to Sec-Fetch-Site and Origin verification.

> [!NOTE] > Fix Completeness Assessment: While expanding the allowlist to include text/ping resolves the hyperlink auditing vector, relying on a blocklist/allowlist of Content-Type values to gate CSRF validation remains fragile if browser specifications introduce additional preflight-exempt MIME types in the future, or if an endpoint accepts requests with an empty or unrecognized Content-Type sent via other browser mechanisms. However, because c.req.header('content-type') || 'text/plain' defaults missing headers to 'text/plain', requests omitting Content-Type entirely are still properly checked.

Exploiting CVE-2026-126355 requires a specific set of environmental and application conditions, reflected in the High Attack Complexity (AC:H) and User Interaction Required (UI:R) metrics of its CVSS v3.1 vector:

1. Target Application Design: Because a browser-generated ping request always sends the static body PING, the target Hono route cannot rely on structured request bodies (such as parsed JSON or form fields) to determine the action. Instead, the endpoint must execute state-changing logic based solely on the URL path (e.g., POST /api/items/42/delete), query parameters (e.g., POST /api/account?action=deactivate), or ambient session state (e.g., POST /api/session/logout).
2. Browser Support: The victim must use a browser that has hyperlink auditing enabled by default. Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, Opera) enable <a ping> by default. Mozilla Firefox disables hyperlink auditing by default (browser.send_pings = false).
3. Cookie Transmission Context: For the cross-origin ping request to carry the victim's authentication cookies, either the target application's session cookie must be configured with SameSite=None; Secure, or the attacker must host the malicious link on a same-site origin (such as a compromised subdomain sub.target.com targeting api.target.com, where SameSite=Lax cookies are still transmitted on POST requests).

Consider a Hono application that exposes a state-changing endpoint protected by csrf():

import { Hono } from 'hono'
import { csrf } from 'hono/csrf'
 
const app = new Hono()
app.use('*', csrf())
 
app.post('/api/account/delete', (c) => {
  // Performs state mutation based on authenticated session cookie
  return c.text('Account deleted')
})
 
export default app

An attacker hosts the following HTML document on an external origin (https://attacker.example) or a sibling subdomain:

<!DOCTYPE html>
<html>
<body>
  <a href="https://attacker.example/landing" ping="https://target.example/api/account/delete">
    Continue to Article
  </a>
</body>
</html>

When an authenticated user clicks the anchor link in a Chromium browser, the browser navigates to https://attacker.example/landing while simultaneously transmitting the following background HTTP request:

POST /api/account/delete HTTP/1.1
Host: target.example
Content-Type: text/ping
Ping-From: https://attacker.example/
Ping-To: https://target.example/api/account/delete
Origin: https://attacker.example
Sec-Fetch-Site: cross-site
Cookie: session_id=VALID_SESSION_TOKEN
Content-Length: 4
 
PING

On Hono < 4.13.16, the csrf() middleware inspects Content-Type: text/ping, fails to match isRequestedByFormElementRe, ignores Sec-Fetch-Site: cross-site and Origin: https://attacker.example, and executes the /api/account/delete handler.

The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N. The primary impact is to Integrity (I:H), as an attacker can force an authenticated victim to execute arbitrary state-changing POST requests within the scope of the victim's session on vulnerable endpoints.

Confidentiality (C:N) is unaffected because HTML5 hyperlink auditing requests are strictly write-only operations from the initiator's perspective. The browser does not expose the HTTP response headers or body of a ping request to the initiating page's DOM or JavaScript context. Similarly, Availability (A:N) is not directly impacted at the framework level unless the targeted application endpoint itself triggers a resource deletion or service disruption action.

The practical exposure of a Hono deployment depends heavily on cookie policies and API conventions. Modern browsers default unset SameSite cookie attributes to SameSite=Lax, which prevents cookies from being attached to cross-site POST requests, including <a ping>. However, applications that explicitly set SameSite=None; Secure (common in federated login flows, embedded iframes, or cross-domain single-page applications) or applications deployed in multi-tenant subdomain environments (where an attacker controls a sibling subdomain within the same eTLD+1 boundary) remain exposed to exploitation.

The primary remediation is to upgrade the hono package to version 4.13.16 or later, which updates src/middleware/csrf/index.ts to inspect Origin and Sec-Fetch-Site headers on text/ping requests.

npm install hono@^4.13.16
# or
pnpm update hono
# or
bun update hono

If an immediate framework upgrade is not feasible, developers can implement a custom pre-middleware handler to explicitly block or validate text/ping requests before they reach route handlers:

import { createMiddleware } from 'hono/factory'
 
const blockCrossOriginPing = createMiddleware(async (c, next) => {
  const contentType = c.req.header('content-type') || ''
  const secFetchSite = c.req.header('sec-fetch-site')
  if (/^text\/ping\b/i.test(contentType) && secFetchSite !== 'same-origin') {
    return c.text('Forbidden', 403)
  }
  await next()
})
 
app.use('*', blockCrossOriginPing)

As defense-in-depth measures, engineering teams should also apply the following architectural controls:

• Enforce Strict SameSite Cookie Policies: Configure session cookies with SameSite=Lax or SameSite=Strict unless cross-site cookie transmission is strictly required by application architecture.
• Require Structured Request Bodies for State Mutation: Avoid designing POST endpoints that mutate state based solely on URL path or query parameters. Require structured application/json payloads and validate the Content-Type header on the receiving route.