REDHAT-BUG-2510801: SSRF
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.3.1, Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inetaton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4('012.0.0.1') reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch('http://012.0.0.1/') connects to 10.0.0.1. An application that builds a network trust-boundary decision on these checks, for example a filter intended to block Server-Side Request Forgery, or SSRF, will classify an internal target as external and allow the request. The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets. This issue is fixed in version 10.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ip-addressto a version that resolves this vulnerability.Fixed in 10.3.1
Event History
Frequently Asked Questions
Which applications are realistically exposed to this issue?
Applications using npm/ip-address before 10.3.1 are exposed when they use Address4-derived checks to make network trust decisions and then pass the original host string to a network client. SSRF filters and controls that distinguish internal from external addresses are a primary affected use case.
What does an attacker need to exploit the mismatch?
An attacker needs to supply an IPv4 address with a leading-zero octet, such as 012.0.0.1, to a workflow that validates the address with ip-address but connects using a URL parser or network stack that interprets leading-zero octets as octal. This can cause a target treated as external by the validation logic to resolve to an internal address for the actual connection.
Which ip-address checks should be considered unreliable for leading-zero IPv4 input?
All consumers of Address4 inherit the parsing issue: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm(). They are computed from decimal-decoded octets even when the downstream URL or network stack interprets those octets differently.
What is the available remediation?
Update npm/ip-address to version 10.3.1, which fixes the issue. Until updating, do not rely on Address4 validation alone for security decisions when an address may later be interpreted by a URL parser, inet_aton, or getaddrinfo.