Summary
A remotely triggerable denial-of-service vulnerability exists in the find-my-way HTTP router when used with Node.js HTTP/2 servers.
Crafted HTTP/2 method values that collide with JavaScript object properties can cause lookup() to crash the process, allowing an attacker to repeatedly terminate the service with malformed requests.
A remotely triggerable denial-of-service vulnerability exists in the find-my-way HTTP router when used with Node.js HTTP/2 servers.
Crafted HTTP/2 method values that collide with JavaScript object properties can cause lookup() to crash the process, allowing an attacker to repeatedly terminate the service with malformed requests.
Affected context
This vulnerability appears in applications that:
- Use the find-my-way router in versions prior to 9.7.0
- Run on top of Node.js HTTP/2 server APIs rather than plain HTTP/1.1
- Accept client-controlled HTTP method values without constraining them to known safe verbs
The issue is specific to environments where HTTP/2 allows method tokens that can overlap with JavaScript object prototype properties, and where the router relies on plain object indexing for method dispatch without additional guarding.
This vulnerability appears in applications that:
- Use the find-my-way router in versions prior to 9.7.0
- Run on top of Node.js HTTP/2 server APIs rather than plain HTTP/1.1
- Accept client-controlled HTTP method values without constraining them to known safe verbs
The issue is specific to environments where HTTP/2 allows method tokens that can overlap with JavaScript object prototype properties, and where the router relies on plain object indexing for method dispatch without additional guarding.
Exploit preconditions
- Attack surface: Public-facing or internal HTTP/2 endpoints wired through find-my-way.
- Required access: Ability to send arbitrary HTTP/2 requests to the affected server; no prior authentication is typically required.
- Trigger point: Router lookup phase when lookup() passes req.method into find(), causing find() to index this.trees[method] on a plain JavaScript object.
- Why exploitation is possible: HTTP/2 method values such as
constructor,toString, or__proto__are interpreted as property names on the router's internal object. Instead of returningundefined, inherited properties are returned and treated as valid routing nodes, leading to a crash when code accesses expected node fields likecurrentNode.prefix.length.
- Attack surface: Public-facing or internal HTTP/2 endpoints wired through find-my-way.
- Required access: Ability to send arbitrary HTTP/2 requests to the affected server; no prior authentication is typically required.
- Trigger point: Router lookup phase when lookup() passes req.method into find(), causing find() to index this.trees[method] on a plain JavaScript object.
- Why exploitation is possible: HTTP/2 method values such as
constructor,toString, or__proto__are interpreted as property names on the router's internal object. Instead of returningundefined, inherited properties are returned and treated as valid routing nodes, leading to a crash when code accesses expected node fields likecurrentNode.prefix.length.
Why this happens
The underlying bug stems from insufficient validation and normalization of input used as an object key, combined with the semantics of JavaScript object inheritance.
The router stores method-specific radix trees in a plain object (this.trees) and directly indexes it with req.method from HTTP/2 requests.
Because this.trees is not protected from prototype pollution semantics and not backed by a null-prototype map, malicious method tokens that overlap with built-in property names resolve to inherited values rather than being treated as missing entries.
This maps to CWE-20: Improper Input Validation, as untrusted protocol data is not constrained to an expected set of HTTP verbs before being used in internal dispatch logic, and to CWE-248: Uncaught Exception, since the unexpected value leads to an unhandled error that terminates the process.
The underlying bug stems from insufficient validation and normalization of input used as an object key, combined with the semantics of JavaScript object inheritance.
The router stores method-specific radix trees in a plain object (this.trees) and directly indexes it with req.method from HTTP/2 requests.
Because this.trees is not protected from prototype pollution semantics and not backed by a null-prototype map, malicious method tokens that overlap with built-in property names resolve to inherited values rather than being treated as missing entries.
This maps to CWE-20: Improper Input Validation, as untrusted protocol data is not constrained to an expected set of HTTP verbs before being used in internal dispatch logic, and to CWE-248: Uncaught Exception, since the unexpected value leads to an unhandled error that terminates the process.
Potential impact
- Remote attackers can repeatedly crash the Node.js process, causing sustained denial of service.
- Disruption of all HTTP/2 endpoints that rely on the vulnerable router instance.
- Potential cascading outages if the affected service is a dependency for other microservices.
- Increased operational load from required restarts, health-check flapping, or autoscaling storms in response to repeated crashes.
- Remote attackers can repeatedly crash the Node.js process, causing sustained denial of service.
- Disruption of all HTTP/2 endpoints that rely on the vulnerable router instance.
- Potential cascading outages if the affected service is a dependency for other microservices.
- Increased operational load from required restarts, health-check flapping, or autoscaling storms in response to repeated crashes.
General mitigation guidance
Effective mitigation generally focuses on reducing trust in protocol-level inputs and hardening internal dispatch structures:
- Constrain HTTP method handling to a strict allowlist (e.g., GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) before passing methods into routing logic.
- Normalize and sanitize method tokens, rejecting or dropping requests with unexpected or non-standard method names, especially those overlapping with JavaScript object/property names.
- Use defensive data structures for routing tables, such as objects created with a null prototype or Maps, to avoid collisions with inherited properties.
- Introduce safe-guard checks before dereferencing internal routing nodes, ensuring values have the expected shape before accessing properties like
prefix.length. - Deploy process-level resilience patterns (graceful restarts, circuit breakers, rate limiting) to reduce the impact of unexpected crashes while code-level fixes are applied.
Effective mitigation generally focuses on reducing trust in protocol-level inputs and hardening internal dispatch structures:
- Constrain HTTP method handling to a strict allowlist (e.g., GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) before passing methods into routing logic.
- Normalize and sanitize method tokens, rejecting or dropping requests with unexpected or non-standard method names, especially those overlapping with JavaScript object/property names.
- Use defensive data structures for routing tables, such as objects created with a null prototype or Maps, to avoid collisions with inherited properties.
- Introduce safe-guard checks before dereferencing internal routing nodes, ensuring values have the expected shape before accessing properties like
prefix.length. - Deploy process-level resilience patterns (graceful restarts, circuit breakers, rate limiting) to reduce the impact of unexpected crashes while code-level fixes are applied.
How teams detect issues like this
Detection can combine code-level inspection with runtime monitoring:
- Perform static analysis or manual code review to identify routing logic that indexes plain JavaScript objects (e.g.,
trees[req.method]) with unvalidated or unsanitized request fields. - Add linting or custom ESLint rules to flag uses of untrusted input as object keys on non-null-prototype objects that drive control flow.
- Instrument HTTP/2 servers with structured logging around method parsing and router lookup failures, capturing unexpected method names and associated stack traces.
- Monitor for patterns of repeated, similar HTTP/2 requests that correlate with process crashes, elevated 5xx response rates, or abnormal restart counts in orchestration systems.
- Use application-level error handling and centralized exception tracking to surface unhandled exceptions originating from router lookup paths.
Detection can combine code-level inspection with runtime monitoring:
- Perform static analysis or manual code review to identify routing logic that indexes plain JavaScript objects (e.g.,
trees[req.method]) with unvalidated or unsanitized request fields. - Add linting or custom ESLint rules to flag uses of untrusted input as object keys on non-null-prototype objects that drive control flow.
- Instrument HTTP/2 servers with structured logging around method parsing and router lookup failures, capturing unexpected method names and associated stack traces.
- Monitor for patterns of repeated, similar HTTP/2 requests that correlate with process crashes, elevated 5xx response rates, or abnormal restart counts in orchestration systems.
- Use application-level error handling and centralized exception tracking to surface unhandled exceptions originating from router lookup paths.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
