GHSA-v8w9-8mx6-g223

What it actually does

The flaw is an improper input validation issue in the Hono npm package affecting request body parsing when parseBody({ dot: true }) is used. In that mode, attacker-controlled field names containing dot notation can be interpreted as nested object paths, and the special JavaScript key __proto__ is not safely blocked. A crafted request body can therefore modify Object.prototype or otherwise influence the prototype chain, causing prototype pollution. Depending on how the application later uses parsed body objects, this may lead to unexpected property injection, authorization or logic bypasses, denial of service, unsafe configuration changes, or secondary vulnerabilities in downstream code that trusts inherited properties.

Why it matters to the business

Applications built with vulnerable Hono versions may process malicious form or request-body input in a way that changes application behavior beyond the individual request. The practical business risk depends heavily on how parseBody({ dot: true }) is used and whether polluted properties influence security decisions, configuration, routing, templating, serialization, or persistence logic. Although the CVSS score is moderate and there is no known KEV listing or reported exploit maturity, Hono is a web framework component, so affected internet-facing services should be upgraded promptly to avoid hard-to-debug application behavior, service instability, or security control bypasses.

How an attack unfolds

An attacker identifies an endpoint implemented with Hono that parses attacker-supplied request bodies using parseBody({ dot: true }). The attacker submits a crafted body containing a field name that uses dot notation and the __proto__ key, such as a form parameter intended to set a property on the JavaScript prototype chain. The vulnerable parser accepts and expands the key into an object path instead of rejecting it as dangerous. Once parsed, the resulting object can pollute prototypes, making attacker-chosen properties appear on ordinary objects through inheritance. The attacker then attempts to trigger application code paths that read those inherited properties, potentially altering authorization checks, feature flags, validation decisions, object merges, or other application logic. Exploitability and impact are application-specific and depend on whether polluted properties are used in sensitive contexts.

How to fix it

Upgrade Hono to version 4.12.7 or later. For npm-based projects, update the direct dependency and regenerate the lockfile so deployed artifacts resolve to a fixed version. If immediate upgrade is not possible, avoid using parseBody({ dot: true }) on untrusted input, reject or strip dangerous keys such as __proto__, prototype, and constructor before parsing or merging objects, and ensure object handling uses safe patterns such as Object.create(null), own-property checks, and hardened merge utilities. Treat mitigations as temporary; the preferred fix is to consume the patched Hono release.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts use hono version 4.12.7 or later. Check package.json and lockfiles such as package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, or yarn.lock for older hono versions. Run software composition analysis or npm audit-equivalent tooling after dependency updates. Review code for parseBody({ dot: true }) usage and verify that endpoints accepting untrusted body input either run on the fixed package or reject prototype-related keys. Where feasible, perform a safe validation test in a non-production environment by submitting a body parameter containing __proto__ dot notation and confirming that it does not modify Object.prototype or introduce inherited properties on newly created objects.

Typical attack path

1. Find a web endpoint using a vulnerable version of the Hono npm package.
2. Determine or infer that the endpoint accepts body data parsed with parseBody({ dot: true }).
3. Send a crafted request body containing dot-notation parameters with a __proto__ segment.
4. Cause the parser to expand the malicious key into a prototype-polluting object structure.
5. Trigger downstream application behavior that reads inherited properties from ordinary objects.
6. Use the resulting behavior change to attempt logic bypass, service disruption, or further exploitation.

How to detect it

There are no public reports of active exploitation or KEV listing for this advisory, so detection should focus on suspicious request patterns and post-exploitation symptoms in applications using vulnerable Hono versions. Review HTTP access logs, reverse proxy logs, WAF logs, application request logs, and API gateway logs for parameters or multipart/form fields containing __proto__, constructor.prototype, prototype, or dot-notation attempts to set inherited JavaScript properties. Look for unusual 500 errors, unexpected authorization outcomes, validation bypasses, changes in feature or configuration flags, or request sequences where a suspicious body submission is followed by abnormal application behavior. If request body logging is not available, inspect WAF telemetry, endpoint traces, APM spans, and error logs around endpoints known to call parseBody({ dot: true }). In forensic testing, check whether application runtime behavior indicates prototype pollution, such as ordinary newly created objects unexpectedly containing attacker-supplied inherited properties, but avoid running destructive tests in production.

• __proto__
• constructor.prototype
• prototype.constructor
• __proto__.polluted
• __proto__[polluted]
• constructor.prototype.polluted
• prototype.polluted
• parseBody({ dot: true })

What your security team should do

• Inventory applications using the Hono npm package and prioritize internet-facing services or APIs that parse request bodies.
• Upgrade all affected applications to hono 4.12.7 or later and redeploy from clean builds.
• Search codebases for parseBody({ dot: true }) and review exposed endpoints that accept form, multipart, or URL-encoded body input.
• Add input validation or middleware to block __proto__, prototype, and constructor keys in request bodies, especially for services that cannot be upgraded immediately.
• Run dependency scanning in CI/CD to prevent reintroduction of vulnerable Hono versions.
• Review application logic for unsafe use of inherited properties; prefer Object.hasOwn, hasOwnProperty.call, or equivalent own-property validation for security-sensitive decisions.
• Monitor web logs for suspicious request parameters containing prototype pollution payloads.