GHSA-g6gw-c38x-mqfc: Medium severity npm/hono vulnerability

Published Sep 8, 2026
·
Updated

Summary

When parseBody() expands dot-separated form field names into nested objects, it does not limit the nesting depth or the total number of objects created. A request body well within a normal size limit can therefore allocate an object graph far larger than the request itself, and concurrent requests can exhaust the heap and terminate the process.

Details

Each dot-separated segment of a field name creates an intermediate object. Neither the segments within a single field name nor the total across a request was bounded, and empty segments were preserved, so a field name could encode one nesting level per byte.

Both shapes produce the effect: a single deeply dotted field name, and a large number of shallowly dotted ones within one body. A request body size limit does not prevent it, because the amplification happens after the body has been accepted.

Dot-notation parsing is not enabled by default.

Impact

An attacker who can reach an endpoint that parses request bodies with dot-notation enabled can send concurrent requests whose memory cost is disproportionate to their size.

This may lead to:

- exhaustion of the JavaScript heap and termination of the server process - the service remaining unavailable until it is restarted

This issue affects applications that explicitly enable dot-notation parsing. Applications using the default behaviour are not affected.

Affected Software

1 affected componentFixes available
npm/hono<4.13.5
4.13.5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/hono to a version that resolves this vulnerability.

    Fixed in 4.13.5
  2. Configuration

    Disable dot-notation parsing in parseBody() (dot-notation parsing is not enabled by default; only apps that explicitly enable it are affected).

    parseBody() dot-notation parsing = disable
  3. Compensating control

    Use compensating request-handling controls to limit concurrent requests reaching the endpoint that parses request bodies with dot-notation enabled (the issue is triggered by concurrent requests that allocate disproportionately large object graphs after body acceptance).

  4. Operational

    After mitigation, restart the affected server processes to restore availability if they were terminated due to JavaScript heap exhaustion.

Event History

Sep 8, 2026
Advisory Published
via GitHub·09:23 PM
Data Sourced
via GitHub·09:23 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Are applications using the default body-parsing configuration exposed?

No. Dot-notation parsing is not enabled by default. Exposure requires an endpoint that parses request bodies with dot-notation enabled.

2

What does an attacker need to exploit this issue?

An attacker needs network access to an endpoint that accepts request bodies and has dot-notation parsing enabled. No authentication or user interaction is indicated by the supplied severity vector.

3

Will a normal request-body size limit prevent exploitation?

No. The amplification occurs after the request body has been accepted, so a body within the configured size limit can still create a disproportionately large object graph. Concurrent malicious requests can exhaust the JavaScript heap and terminate the server process.

4

What request patterns should be treated as suspicious while mitigation is pending?

Look for form field names containing very long dot-separated paths, including empty path segments, or bodies containing many shallow dot-separated field names. These patterns can create excessive intermediate objects despite small request sizes.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203