HONO · GHSA-92p4-j3wq-jmqx · Package
FIX → 4.13.18
Hono's validator('json') and validator('form') middleware fail to read the request body when the Content-Type header is legal but formatted differently, such as extra whitespace or a trailing semicolon. The validation callback then receives an empty object while the handler still reads the full body, so an attacker can send fields the validator was meant to reject.
first public Nov 11, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications built on Hono 4.5.1 through 4.13.17 that use validator('json') or validator('form') to reject or restrict fields, and whose validation callback accepts an empty object. Apps that do not use these validators, or whose callbacks fail on an empty object, are not exposed by this path.
Not affected if callback-rejects-empty-object, hono-outside-affected-range, no-json-or-form-validator
Who cares api, hono, node, npm
npm ls honovalidator('json') or validator('form') and confirm whether the callback rejects or restricts fields or accepts an empty objectUpgrade to 4.13.18
4.13.18validator('json') and validator('form') decide whether to read the request body by matching the whole Content-Type value against a strict pattern. A value that is legal but formatted differently, such as whitespace before ;, a trailing ;, or a parameter name with an underscore, does not match. The validation callback then receives an empty object, while c.req.json() and c.req.parseBody() in the handler still read the body.
GHSA-4h7h-rv7c-7m2v fixed this for a multipart/form-data value with extra parameters. The same problem remained for other parameter formats and for application/json.
The media type and its parameters were checked together with one pattern per target. Anything outside the pattern, including application/json ; charset=utf-8, multipart/form-data; boundary=x; and , failed the check. When it fails, the middleware does not read the body and passes an empty object to the validation callback. If the callback accepts an empty object, the request proceeds to the handler, which can read all submitted fields.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
application/x-www-form-urlencoded; x_y=1The validator now takes the media type as the part before the first ;, trimmed and lowercased, and decides on that alone. This is the same rule c.req.parseBody() uses, so the two can no longer disagree about the same request. Structured JSON suffixes such as application/vnd.api+json and subtypes containing digits are accepted as JSON.
This issue arises when an application relies on validator('json') or validator('form') to reject or restrict fields and the validation callback does not fail on an empty object.
An unauthenticated client can send JSON or form fields that the validator never sees, by formatting the Content-Type header differently.
This may lead to:
This issue affects applications that use validator('json') or validator('form') and whose validation callback accepts an empty object.