PT-2026-67498 · Pypi · Ipaddress
CVE-2026-69192
·
Published
2026-08-03
·
Updated
2026-08-03
CVSS v4.0
7.7
High
| Vector | AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X |
Name of the Vulnerable Software and Affected Versions
ip-address versions prior to 10.3.1
Description
Address4 accepts IPv4 octets with leading zeros and decodes them as decimal, whereas the WHATWG URL host parser, inet aton, and getaddrinfo decode them as octal. This discrepancy allows a string to be interpreted differently by the library and the network stack. For example, new Address4('012.0.0.1') is identified as a public address, but a request to http://012.0.0.1/ connects to the internal address 10.0.0.1.Applications using these checks to build network trust-boundary decisions, such as filters to block Server-Side Request Forgery (SSRF), may incorrectly classify internal targets as external and allow the request. SSRF is an attack where a user-supplied address coaxes the server into making a request to an internal destination, such as a loopback service or cloud metadata endpoint, that the user cannot otherwise reach.
The issue resides in the
Address4.parse function, which uses a regular expression that allows leading zeros. Consequently, all dependent classifiers are affected, including isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm().Recommendations
Update to version 10.3.1.
As a temporary workaround, reject any host whose octets contain a leading zero before parsing it.
Fix
SSRF
RCE
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Ipaddress