CVE-2026-126356: Multipart Form Validation Bypass in Hono Web Framework

Hono is a lightweight web application framework designed to operate across JavaScript runtimes supporting Web Standards and the Fetch API, including Cloudflare Workers, Deno, Bun, and Node.js. To enforce schema and input integrity on incoming HTTP requests, Hono provides a built-in validation middleware accessed via validator('form', callback). This middleware intercepts incoming form submissions, parses the request body, and passes the extracted key-value pairs to a developer-defined validation function or schema validator before the main route handler executes.

In Hono versions 4.5.1 through 4.13.15, the validator('form') middleware exhibits an input validation flaw classified under CWE-20 (Improper Input Validation) and CWE-1471 (Insufficiently Controlled Parser Differential). The middleware determines whether to parse an incoming request body as multipart data by matching the HTTP Content-Type header against an internal regular expression (multipartRegex). Because this regular expression was written to match only a strict subset of valid multipart/form-data headers, any deviation in parameter ordering, additional MIME parameters, or extra whitespace causes the pattern match to fail.

When multipartRegex fails to match the Content-Type header, the validator middleware skips body parsing entirely and invokes the validation callback with an empty JavaScript object ({}). However, when the request proceeds to the downstream route handler, methods such as c.req.parseBody() or c.req.formData() rely on the underlying runtime's native Fetch API parser. Because standard runtime parsers adhere to RFC 2046 and RFC 7231, they successfully parse the multipart payload despite the extra parameters or whitespace, exposing completely unvalidated fields to the application's business logic.

> [!NOTE] > This vulnerability specifically impacts multipart/form-data requests. Form submissions encoded as application/x-www-form-urlencoded are evaluated by a separate regular expression that already accounted for arbitrary parameters and whitespace, rendering them unaffected.

The root cause of CVE-2026-126356 is a discrepancy between how Hono's validation layer identifies multipart requests and how the underlying JavaScript runtime parses them. Within src/validator/validator.ts, Hono inspects the Content-Type header of incoming requests when validator('form') is registered on a route. Prior to version 4.13.16, the regular expression responsible for identifying multipart/form-data headers was defined with strict positional and character constraints.

Specifically, the vulnerable regular expression ^multipart\/form-data(;\s?boundary=[a-zA-Z0-9'"()+_,\-./:=?]+)?$ enforced two non-standard limitations on the HTTP header format:

1. Parameter Exclusivity and Ordering: The pattern required the boundary directive to be the sole parameter following the multipart/form-data media type. Under RFC 2046 Section 5.1 and RFC 7231 Section 3.1.1.1, media types may include additional parameters such as charset (e.g., Content-Type: multipart/form-data; charset=utf-8; boundary=Example), and parameters may appear in any order.
2. Whitespace Rigidity: The pattern used \s? immediately after the semicolon delimiter, permitting at most a single whitespace character. RFC 7230 permits optional whitespace (OWS), meaning zero or more spaces or horizontal tabs (; boundary=Example) are valid according to HTTP specifications.

When a request containing either multiple spaces after the semicolon or an auxiliary parameter like charset=utf-8 reaches the middleware, both multipartRegex.test(contentType) and urlencodedRegex.test(contentType) evaluate to false. Instead of rejecting the request with a 400 Bad Request or 415 Unsupported Media Type status, the validator defaults to an unpopulated value object ({}) and passes it directly to the user's validation callback.

The parser differential manifests when the validation callback completes and calls next(). Downstream handlers frequently access form inputs by calling await c.req.parseBody() or await c.req.formData(), rather than reading strictly from c.req.valid('form'), or the validation callback itself only asserts constraints on properties if they are present (such as blocklisting specific values or validating optional fields). Because the underlying runtime (such as Node.js undici, Bun, Deno, or Cloudflare Workers) uses an RFC-compliant MIME parser, it ignores the extra whitespace or auxiliary parameters, extracts the multipart boundary, and populates the form data structure with the attacker's payload.

The vulnerability was introduced in commit 0535579de5af90319165304be409ea9b7d5d47f3 (released in Hono 4.5.1) and resolved in commit d88fab372415277a9e540e895650943dd08eef4a (released in Hono 4.13.16). Inspection of src/validator/validator.ts reveals that jsonRegex and urlencodedRegex were already constructed to accept arbitrary sequences of semicolon-delimited parameters and variable whitespace, whereas multipartRegex had been hardcoded to look exclusively for a single boundary parameter.

// Vulnerable definitions in src/validator/validator.ts (prior to 4.13.16)
const jsonRegex = /^application\/([a-z-\.]+\+)?json(;\s*[a-zA-Z0-9\-]+\=([^;]+))*$/i
 
// FLAW: Only allows 0 or 1 space (\s?) and only matches a single 'boundary=' parameter
const multipartRegex = /^multipart\/form-data(;\s?boundary=[a-zA-Z0-9'"()+_,\-./:=?]+)?$/i
 
const urlencodedRegex = /^application\/x-www-form-urlencoded(;\s*[a-zA-Z0-9\-]+\=([^;]+))*$/i

In commit d88fab372415277a9e540e895650943dd08eef4a, the maintainers aligned multipartRegex with the structure used by urlencodedRegex and jsonRegex:

--- a/src/validator/validator.ts
+++ b/src/validator/validator.ts
@@ -22,7 +22,7 @@ export type ValidationFunction<
 ) => OutputType | TypedResponse | Promise<OutputType> | Promise<TypedResponse>
 
 const jsonRegex = /^application\/([a-z-\.]+\+)?json(;\s*[a-zA-Z0-9\-]+\=([^;]+))*$/i
-const multipartRegex = /^multipart\/form-data(;\s?boundary=[a-zA-Z0-9'"()+_,\-./:=?]+)?$/i
+const multipartRegex = /^multipart\/form-data(;\s*[a-zA-Z0-9\-]+\=([^;]+))*$/i
 const urlencodedRegex = /^application\/x-www-form-urlencoded(;\s*[a-zA-Z0-9\-]+\=([^;]+))*$/i
 
 export type ExtractValidationResponse<VF> = VF extends (value: any, c: any) => infer R

The updated pattern (;\s*[a-zA-Z0-9\-]+\=([^;]+))* makes two critical adjustments:

1. It replaces \s? with \s*, allowing zero or more whitespace characters after each semicolon.
2. It replaces the literal boundary=... requirement with a repeating group ([a-zA-Z0-9\-]+\=([^;]+))*, allowing any number of valid parameter key-value pairs in any order.

To verify the fix, the commit added regression tests in src/validator/validator.test.ts testing three distinct header permutations that previously bypassed validation:

// Added in src/validator/validator.test.ts
it('Should validate multipart/form-data with extra parameters', async () => {
  const formData = new FormData()
  formData.append('foo', 'bar')
  const source = new Request('http://localhost/post', { method: 'POST', body: formData })
  const boundary = source.headers.get('Content-Type')!.replace(/^multipart\/form-data;\s*/, '')
  for (const contentType of [
    `multipart/form-data; ${boundary}; charset=utf-8`, // Extra parameter after boundary
    `multipart/form-data; charset=utf-8; ${boundary}`, // Extra parameter before boundary
    `multipart/form-data;  ${boundary}`,               // Multiple spaces after semicolon
  ]) {
    const res = await app.request('/post', {
      method: 'POST',
      body: await source.clone().arrayBuffer(),
      headers: {
        'content-type': contentType,
      },
    })
    expect(res.status).toBe(200)
    expect(await res.json()).toEqual({
      foo: 'bar',
    })
  }
})

Regarding fix completeness, aligning multipartRegex with urlencodedRegex significantly narrows the parser differential for standard parameter lists. However, one subtle edge case remains in the regex (;\s*[a-zA-Z0-9\-]+\=([^;]+))*: if a client sends a trailing semicolon without a parameter (e.g., multipart/form-data; boundary=xyz;) or includes quoted string parameters containing an embedded semicolon (e.g., param="a;b"), the regex may still fail to match while lenient runtime parsers might still accept the body. Therefore, applications should also ensure they consume validated data strictly via c.req.valid('form') rather than re-invoking c.req.parseBody() in the route handler.

Exploiting CVE-2026-126356 requires no authentication or special privileges, provided the target endpoint is accessible to the client and utilizes validator('form'). Two application-level conditions are necessary for a successful bypass:

1. The validation callback or schema attached to validator('form') must permit an empty object ({}). This commonly occurs when endpoints validate optional profile attributes, implement blocklists against restricted field values (e.g., checking if (value.role === 'admin')), or use schema definitions where all fields have default or optional modifiers.
2. The downstream route handler must parse the request body using c.req.parseBody() or c.req.formData() instead of exclusively relying on the empty object returned by c.req.valid('form').

Consider the following vulnerable Hono endpoint designed to prevent users from escalating their privilege role during a profile update:

import { Hono } from 'hono'
import { validator } from 'hono/validator'
 
const app = new Hono()
 
app.post(
  '/profile',
  validator('form', (value, c) => {
    // Security check intended to block administrative role assignment
    if (value.role && value.role === 'admin') {
      return c.text('Unauthorized role modification', 403)
    }
    return value
  }),
  async (c) => {
    // Handler reads parsed body from the underlying runtime
    const body = await c.req.parseBody()
    return c.json({ status: 'updated', user: body })
  }
)

In a standard request where Content-Type: multipart/form-data; boundary=----Boundary is sent with a role=admin field, multipartRegex matches, value is populated with { role: 'admin' }, and the validator returns a 403 Forbidden response.

To bypass this restriction, an attacker modifies the Content-Type header by inserting either a second space after the semicolon or a benign parameter such as charset=utf-8:

POST /profile HTTP/1.1
Host: target.example.com
Content-Type: multipart/form-data; charset=utf-8; boundary=----WebKitFormBoundaryDummyBoundary
Content-Length: 184
 
------WebKitFormBoundaryDummyBoundary
Content-Disposition: form-data; name="role"
 
admin
------WebKitFormBoundaryDummyBoundary
Content-Disposition: form-data; name="username"
 
attacker
------WebKitFormBoundaryDummyBoundary--

When Hono processes this crafted request:

1. validator('form') tests multipart/form-data; charset=utf-8; boundary=----WebKitFormBoundaryDummyBoundary against multipartRegex, which returns false.
2. The validator passes {} as value to the callback.
3. Inside the callback, value.role evaluates to undefined, bypassing the if (value.role && value.role === 'admin') check.
4. Execution proceeds to the route handler, where await c.req.parseBody() invokes the runtime's multipart parser.
5. The runtime parser processes the boundary normally and returns { role: 'admin', username: 'attacker' }, completing the unauthorized state modification.

CVE-2026-126356 is rated with a CVSS v3.1 base score of 5.3 (Medium) under the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. The attack vector is Network (AV:N) with Low attack complexity (AC:L), requiring neither privileges (PR:N) nor user interaction (UI:N). The primary impact is on Integrity (I:L), as attackers can supply unvalidated or prohibited form fields to application handlers without affecting confidentiality (C:N) or availability (A:N).

The concrete security impact depends on the business logic protected by validator('form'). In applications that use the form validator for mass-assignment protection, field sanitization, or input allow-listing while subsequently reading from c.req.parseBody() or c.req.formData(), an attacker can inject arbitrary form fields or file uploads. This can lead to unauthorized privilege escalation (e.g., overwriting internal user flags or roles), stored Cross-Site Scripting (XSS) if HTML sanitization occurs inside the validator callback, or business logic manipulation.

Conversely, applications are not impacted if they meet either of the following criteria:

• The validation schema strictly requires at least one mandatory field (causing the validator to reject the empty {} object with a 400 Bad Request error).
• The downstream route handler exclusively accesses form data via c.req.valid('form') and never calls c.req.parseBody() or c.req.formData() directly (in which case the handler only receives the empty {} object).

All runtime adapters built around Hono's core request handling—including @hono/node-server, @hono/bun, @hono/deno, @hono/cloudflare-workers, @hono/vercel, @hono/aws-lambda, and @hono/netlify—inherit this vulnerability when running affected versions of the core hono package.

The primary remediation is to upgrade the hono dependency to version 4.13.16 or later, which includes commit d88fab372415277a9e540e895650943dd08eef4a updating multipartRegex to handle extra whitespace and additional MIME parameters.

# Using npm
npm install hono@^4.13.16
 
# Using pnpm
pnpm update hono@^4.13.16
 
# Using Bun
bun add hono@^4.13.16

In addition to upgrading the framework, developers should adopt two architectural practices to eliminate parser differential risks across Hono endpoints:

1. Consume Only Validated Data: Route handlers should always retrieve validated form inputs via c.req.valid('form') rather than re-parsing the raw request via c.req.parseBody() or c.req.formData(). This ensures the handler operates on the exact data structure inspected by the validator.

app.post(
  '/profile',
  validator('form', (value, c) => {
    if (!value || Object.keys(value).length === 0) {
      return c.text('Empty or malformed form payload', 400)
    }
    if (value.role === 'admin') {
      return c.text('Unauthorized role modification', 403)
    }
    return value
  }),
  async (c) => {
    // SAFE: Accesses the exact object returned by the validator
    const body = c.req.valid('form')
    return c.json({ status: 'updated', user: body })
  }
)

2. Reject Empty Objects in Validation Callbacks: If an immediate package upgrade is not feasible, update custom validation callbacks and schema definitions (such as Zod or Valibot schemas) to explicitly reject empty objects (Object.keys(value).length === 0) on endpoints expecting form fields. Furthermore, edge proxies or Web Application Firewalls (WAFs) can be configured to block or normalize multipart/form-data headers that contain multiple semicolons or non-boundary parameters.