GHSA-v8w9-8mx6-g223: Prototype Pollution in Hono parseBody Utility

The vulnerability resides within the parseBody utility of the Hono web framework, affecting versions prior to 4.12.7. This utility processes incoming HTTP request bodies, specifically handling multipart/form-data and application/x-www-form-urlencoded payloads. When developers enable the { dot: true } configuration option, the parser attempts to convert flat keys containing dot characters into nested JavaScript objects.

This functionality facilitates the processing of complex form submissions by automatically structuring the resulting data object. For example, a key submitted as user.name=admin is parsed into a structured object { user: { name: 'admin' } }. The implementation constructs this nested object dynamically by iterating over the dot-separated segments of the key.

However, the implementation historically lacked sufficient input validation on the parsed key segments. This omission creates an attack surface where maliciously crafted keys can manipulate the object construction logic. By providing specific built-in JavaScript property names as key segments, an attacker can coerce the parser into modifying the base object prototype rather than the intended data structure.

This flaw is classified under CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes). Because the parseBody utility processes untrusted input directly from incoming HTTP requests, the vulnerability is reachable over the network without authentication, provided the target endpoint utilizes the vulnerable configuration.

The root cause of the vulnerability exists in the handleParsingNestedValues function within Hono's src/utils/body.ts. When parseBody is invoked with the dot: true option, the framework processes form data keys by splitting them at the . character. The function then iterates over these segments to traverse an existing object or create new nested objects dynamically.

During this traversal, the code accesses properties using bracket notation, effectively executing operations equivalent to target[segment] = current_value. Before the implementation of the patch, the function performed no sanitization or blocklisting on the segment strings. This allowed special property names, most notably __proto__, to be evaluated as valid object keys.

When the traversal logic encounters the __proto__ segment, it accesses the prototype of the current object. In JavaScript, modifying the __proto__ property of an object modifies the global Object.prototype. Any properties subsequently appended during the traversal are written directly to the global prototype object.

Consequently, these injected properties become immediately accessible on almost all JavaScript objects within the Node.js runtime, as standard objects inherit from Object.prototype. This runtime-wide modification corrupts the expected state of the application and alters the behavior of loops, property checks, and configuration evaluations throughout the system.

The vulnerability was addressed in Hono version 4.12.7 via commit ef902257e0beacbb83d2a9549b3b83e03514a6fe. The maintainers introduced an explicit validation check within the handleParsingNestedValues function to intercept malicious key traversal before object instantiation occurs.

The patched implementation introduces a regular expression designed to identify the presence of the __proto__ string either at the beginning of the key or immediately following a dot separator. The relevant code addition is shown below:

if (/(?:^|\.)__proto__\./.test(key)) {
  return
}

This defensive check operates early in the parsing sequence. If the incoming key string evaluates to true against the regex, the function returns immediately, discarding the payload and preventing the traversal logic from executing. This ensures that strings like __proto__.polluted or nested.__proto__.polluted are safely ignored by the parser.

While this patch successfully mitigates the primary vector utilizing the __proto__ string, it relies on a blocklist approach rather than a safelist approach. The regex explicitly targets the specific sequence associated with prototype access, but it does not account for alternative mechanisms of accessing the object prototype in JavaScript.

Exploiting this vulnerability requires an attacker to send a specially crafted HTTP request to a Hono application endpoint that utilizes parseBody with the { dot: true } option. The attack vector is typically a POST, PUT, or PATCH request containing either multipart/form-data or application/x-www-form-urlencoded body content.

The attacker constructs a payload where the form data key includes the __proto__ property followed by the desired property to inject. For example, submitting the key __proto__.isAdmin with the value true executes the attack. The vulnerable parsing logic traverses to Object.prototype and sets the isAdmin property to the string 'true'.

The following is a Proof of Concept snippet demonstrating the underlying mechanics based on the Hono testing suite:

const data = new FormData()
data.append('__proto__.polluted', 'malicious')
const req = createRequest(FORM_URL, 'POST', data)
const result = await parseBody(req, { dot: true })

Following the execution of this payload on an unpatched server, evaluating ({}).polluted anywhere in the application returns 'malicious' instead of undefined. An attacker leverages this state change to exploit logic flaws elsewhere in the application, specifically targeting components that fail to use Object.hasOwn() or hasOwnProperty() when iterating over object keys.

The successful exploitation of this Prototype Pollution vulnerability compromises the internal state of the Node.js runtime environment. Because JavaScript objects universally inherit from Object.prototype, injecting arbitrary properties alters the baseline behavior of the entire application globally.

The immediate impact is typically a Denial of Service (DoS). By overwriting standard methods like toString or injecting properties into critical configuration objects used by the framework or third-party libraries, an attacker causes the application to crash or behave unpredictably during routine request processing.

In specific architectural setups, Prototype Pollution escalates to Remote Code Execution (RCE) or authentication bypass. If the application or its dependencies utilize uninitialized objects for security configurations, database query construction, or template rendering, the injected prototype properties manipulate these downstream operations. The exact impact depends strictly on the presence of exploitable 'gadgets' within the application's codebase.

The primary remediation for this vulnerability is upgrading the hono package to version 4.12.7 or later. Organizations unable to upgrade immediately mitigate the issue by avoiding the { dot: true } configuration. Calling parseBody(c, { dot: false }), or simply omitting the option to rely on the default behavior, entirely removes the vulnerable code path.

Analysis of the implemented patch reveals a potential weakness regarding fix completeness. The regex /(?:^|\.)__proto__\./.test(key) strictly filters the __proto__ string. However, a well-known alternative vector for Prototype Pollution in JavaScript utilizes the constructor.prototype chain to achieve the same result.

An attacker submitting a key such as a.constructor.prototype.polluted=malicious bypasses the regex check. The traversal logic accesses form['a']['constructor']['prototype'], which refers directly to Object.prototype, and assigns the malicious value. This vector remains viable because the blocklist does not filter the constructor property.

Developers utilizing Hono must be aware of this residual risk. While version 4.12.7 blocks the primary attack vector documented in the advisory, defense-in-depth practices dictate strict validation of all incoming payload keys and utilizing Object.create(null) for configuration objects where appropriate.