CWE-1471
Weakness Allowed-with-ReviewInsufficiently Controlled Parser Differential
Abstraction: Class · Status: Incomplete
The product uses a common specification or format that is shared between multiple components or entities, but the components have different parsers that can interpret the same input in different, security-relevant ways.
Mapping guidance
This CWE Entry is a Class and might have lower-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Modes of introduction
The product's components might be required to follow a specification that is incomplete in ways that do not sufficiently cover security expectations, and/or allows for implementation-specific variations that may be security-critical.
Detection methods
Automated Dynamic Analysis
The different product components or entities could be tested using inputs with a variety of manipulations, such as differences in capitalization, whitespace, "boundary" tags, etc. The behavior of each component could be evaluated to see if the inputs are handled consistently.
Content history
Suggested coverage with Parser Weakness Enumeration
2 vulnerabilities reference this CWE, most recent first.
CVE-2026-126356 (GCVE-0-2026-126356)
Vulnerability from cvelistv5 – Published: 2026-11-12 22:16 – Updated: 2026-11-13 00:36| URL | Tags |
|---|---|
| https://github.com/honojs/hono/security/advisorie… | x_refsource_CONFIRM |
| https://github.com/honojs/hono/commit/d88fab37241… | x_refsource_MISC |
| https://github.com/honojs/hono/releases/tag/v4.13.16 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-126356",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-13T00:36:28.247312Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T00:36:43.157Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "hono",
"vendor": "honojs",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.5.1, \u003c 4.13.16"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Hono is a Web application framework that provides support for any JavaScript runtime. From 4.5.1 until 4.13.16, validator(\u0027form\u0027) uses a strict whole-header pattern that fails to recognize multipart/form-data when its Content-Type includes another legal parameter or extra whitespace after a semicolon. The validation callback receives an empty object even though c.req.parseBody() or c.req.formData() can still parse and expose all submitted fields to the handler. An unauthenticated client can therefore bypass allow-list or required-field checks when the application relies on the form validator and its callback accepts an empty object. application/x-www-form-urlencoded requests are not affected. This issue is fixed in version 4.13.16."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20: Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1471",
"description": "CWE-1471: Insufficiently Controlled Parser Differential",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-12T22:17:35.051Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/honojs/hono/security/advisories/GHSA-4h7h-rv7c-7m2v",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/honojs/hono/security/advisories/GHSA-4h7h-rv7c-7m2v"
},
{
"name": "https://github.com/honojs/hono/commit/d88fab372415277a9e540e895650943dd08eef4a",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/honojs/hono/commit/d88fab372415277a9e540e895650943dd08eef4a"
},
{
"name": "https://github.com/honojs/hono/releases/tag/v4.13.16",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/honojs/hono/releases/tag/v4.13.16"
}
],
"source": {
"advisory": "GHSA-4h7h-rv7c-7m2v",
"discovery": "UNKNOWN"
},
"title": "Hono: `validator(\u0027form\u0027)` skips validation for `multipart/form-data` requests with extra parameters"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-126356",
"datePublished": "2026-11-12T22:16:37.256Z",
"dateReserved": "2026-11-10T21:12:01.227Z",
"dateUpdated": "2026-11-13T00:36:43.157Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-4H7H-RV7C-7M2V
Vulnerability from github – Published: 2026-11-12 23:30 – Updated: 2026-11-12 23:30Summary
validator('form') only recognizes a multipart/form-data Content-Type that carries nothing but a single boundary parameter. A request with another legal parameter, such as charset, or with extra whitespace after the ; is not recognized as a form. The validation callback then receives an empty object, while c.req.parseBody() still parses the body as a form.
Details
The check that decides whether a request body is a form was written as a strict pattern over the whole Content-Type value. Any parameter list that does not look exactly like ; boundary=... fails 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 still read all submitted fields through c.req.parseBody() or c.req.formData().
application/x-www-form-urlencoded is not affected. Only the multipart/form-data branch has the strict pattern.
This issue arises when an application relies on validator('form') to reject or restrict fields and the validation callback does not fail on an empty object.
Impact
An unauthenticated client can send form fields that the form validator never sees, by adding a legal parameter to the Content-Type header.
This may lead to:
- Allow-list or required-field checks in the validator being skipped
- Fields the application intended to reject reaching the handler
This issue affects applications that use validator('form') with multipart/form-data requests and whose validation callback accepts an empty object.
Workarounds
Reject an empty object in the validator('form') callback, or validate the result of await c.req.parseBody() in the handler.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.13.15"
},
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "4.5.1"
},
{
"fixed": "4.13.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-126356"
],
"database_specific": {
"cwe_ids": [
"CWE-1471",
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-12T23:30:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`validator(\u0027form\u0027)` only recognizes a `multipart/form-data` `Content-Type` that carries nothing but a single `boundary` parameter. A request with another legal parameter, such as `charset`, or with extra whitespace after the `;` is not recognized as a form. The validation callback then receives an empty object, while `c.req.parseBody()` still parses the body as a form.\n\n### Details\n\nThe check that decides whether a request body is a form was written as a strict pattern over the whole `Content-Type` value. Any parameter list that does not look exactly like `; boundary=...` fails 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 still read all submitted fields through `c.req.parseBody()` or `c.req.formData()`.\n\n`application/x-www-form-urlencoded` is not affected. Only the `multipart/form-data` branch has the strict pattern.\n\nThis issue arises when an application relies on `validator(\u0027form\u0027)` to reject or restrict fields and the validation callback does not fail on an empty object.\n\n### Impact\n\nAn unauthenticated client can send form fields that the `form` validator never sees, by adding a legal parameter to the `Content-Type` header.\n\nThis may lead to:\n\n- Allow-list or required-field checks in the validator being skipped\n- Fields the application intended to reject reaching the handler\n\nThis issue affects applications that use `validator(\u0027form\u0027)` with `multipart/form-data` requests and whose validation callback accepts an empty object.\n\n### Workarounds\n\nReject an empty object in the `validator(\u0027form\u0027)` callback, or validate the result of `await c.req.parseBody()` in the handler.",
"id": "GHSA-4h7h-rv7c-7m2v",
"modified": "2026-11-12T23:30:45Z",
"published": "2026-11-12T23:30:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-4h7h-rv7c-7m2v"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/d88fab372415277a9e540e895650943dd08eef4a"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.13.16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hono: `validator(\u0027form\u0027)` skips validation for `multipart/form-data` requests with extra parameters"
}
Mitigation
If possible, ensure that the same parser is used by each component.
No CAPEC attack patterns related to this CWE.