REDHAT-BUG-2507593: SSRF
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Versions 10.1.1 through 10.2.0 are vulnerable to SSRF through misclassification of IPv4-mapped/NAT64 IPv6 addresses. Address6.getType() classifies an address by matching it against a table of known IPv6 special-use prefixes, returning Global unicast when nothing matches. That table had no entry for the IPv4-mapped range (::ffff:0:0/96), so every mapped address fell through to Global unicast; NAT64 addresses matched their own NAT64 … labels. The boolean checks isLoopback, isUnspecified, and isMulticast compared getType() against a fixed label and so returned false, while isLinkLocal and isULA checked only the native IPv6 ranges. The library already exposed isMapped4() and to4(), but did not apply them inside these checks, so a mapped or NAT64 address was never normalized to its embedded IPv4 address before classification. For IPv4-mapped addresses the host OS routes to the IPv4 stack, so the misclassification is reachable on any dual-stack host. For NAT64, the classification bypass is unconditional but end-to-end reachability additionally requires a NAT64/DNS64 gateway in the deployment network.This issue has been fixed in version 10.2.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.2.1
Event History
Frequently Asked Questions
Which deployments are exposed to the IPv4-mapped address bypass?
Any dual-stack host can reach the issue for IPv4-mapped addresses, because the host operating system routes those addresses to the IPv4 stack. NAT64-related bypasses additionally require a NAT64/DNS64 gateway for end-to-end reachability.
What address forms can evade the library's IPv6 safety checks?
IPv4-mapped IPv6 addresses can be classified as Global unicast instead of according to their embedded IPv4 address. NAT64 addresses can also bypass classification because they receive NAT64 labels rather than being normalized to the embedded IPv4 address.
Which checks are affected by this classification behavior?
isLoopback, isUnspecified, and isMulticast can return false because they compare the misclassified type to fixed labels. isLinkLocal and isULA only check native IPv6 ranges and do not account for mapped or NAT64 embedded IPv4 addresses.
How can I determine whether a dependency is affected?
The affected npm/ip-address versions are 10.1.1 through 10.2.0. Review both direct and transitive dependency versions in that range, especially where the library is used to validate addresses for network access controls.