CVE-2026-69192 in ip-address
Summary
by MITRE • 08/03/2026
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, inet_aton, 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/03/2026
The ip-address library vulnerability represents a critical parsing inconsistency that undermines network security decisions based on IP address validation. This flaw exists in versions prior to 10.3.1 where the Address4 class handles octet parsing with leading zeros differently than standard network infrastructure components. The fundamental issue arises from how the library interprets numeric literals with leading zeros, treating them as decimal values while network stack components like WHATWG URL host parser, inet_aton, and getaddrinfo interpret these same values as octal. This discrepancy creates a dangerous scenario where applications using the library make security decisions based on incorrect IP address representations.
The technical implementation of this vulnerability demonstrates a classic parsing inconsistency that affects multiple network classification methods within the library. When processing an address like '012.0.0.1', the Address4 library correctly reports the form as 12.0.0.1 and classifies it as non-private, but this interpretation conflicts with actual network behavior where leading zero parsing results in octal interpretation equal to decimal 10. This means that while the library claims the address represents 12.0.0.1, network operations actually connect to 10.0.0.1, creating a fundamental mismatch between application logic and system behavior. The vulnerability affects all IP classification methods within the Address4 class because they all rely on the same flawed parsing mechanism rather than being isolated issues.
The operational impact of this vulnerability extends far beyond simple address representation errors and poses serious security risks particularly in server-side request forgery protection mechanisms. Applications that implement trust boundary decisions based on IP address classifications can be completely subverted by this inconsistency, as demonstrated by the SSRF filtering scenario where internal targets are incorrectly classified as external, allowing unauthorized requests to internal systems. The vulnerability's pervasive nature means that every method in the Address4 class is affected since they all derive from the same erroneous parsing logic, creating a systemic security flaw that impacts isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() methods. This comprehensive impact makes the vulnerability particularly dangerous as it affects core network security functionality.
Security implications of this vulnerability align with established frameworks such as CWE-192, which addresses integer overflow or underflow issues, and ATT&CK technique T1190 for exploitation of remote services through server-side request forgery. The flaw represents a parsing inconsistency that can be exploited to bypass security controls by manipulating how IP addresses are interpreted, particularly in contexts where network trust boundaries are established. Organizations relying on this library for network validation and access control mechanisms face significant risks as their security policies may be rendered ineffective due to this fundamental parsing disagreement between application logic and system behavior.
The fix implemented in version 10.3.1 addresses the root cause by standardizing the octet parsing behavior to align with established network stack conventions, ensuring that leading zero handling matches the expected octal interpretation used throughout Unix and Internet infrastructure components. This remediation restores consistency between application-level IP address processing and system-level network operations, eliminating the dangerous mismatch that enabled bypass of security controls. The vulnerability serves as a reminder of the critical importance of maintaining consistent parsing behavior across different layers of network infrastructure and demonstrates how seemingly minor implementation differences can create significant security vulnerabilities in systems relying on IP address validation for trust decisions.