Skip to content

← Public intelligence

npm package

ip-address

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.3npmAmendedPublished

    ip-address: Address6 matches a zone identifier in quadratic time ahead of its length limit, allowing a single long string to stall the process

    CVE-2026-111997 · GHSA-rxp7-6hxx-x8q5

    Affected
    • npm ip-address <= 10.7.3
    Fixed in
    10.7.4· Vendor fix available
    Issue
    new Address6() and Address6.isValid() strip a zone identifier with the pattern /%.$/ before they apply the 45-character length limit. When the string holds many % characters followed by a line terminator, the pattern is retried from every % and each attempt scans to the line terminator before failing, so rejecting the string takes time proportional to the square of its length. 10,000 % characters and a newline take 41 ms, 40,000 take 632 ms and 100,000 take 3.9 s of synchronous work. The same strings without the newline are rejected in under a millisecond. An application that validates an attacker-supplied string with these methods can be stalled by a single long request. The input is rejected with the correct AddressError; the cost of reaching that rejection is the defect. Details The constructor in src/ipv6.ts removes the CIDR suffix, then the zone, then checks the length of what is left: REZONESTRING is /%.$/. It has no anchor at its start, . does not match a line…

    Recommended action: Upgrade to 10.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Medium, CVSS 6.3npmAmendedPublished

    ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range

    CVE-2026-101912 · GHSA-j6r3-76f7-8jcv

    Affected
    • npm ip-address <= 10.7.0
    Fixed in
    10.7.1· Vendor fix available
    Issue
    isInSubnet() and isHostInSubnet() accept an address of either family and compare masked binary strings without checking that both operands are the same family. Address4 pads to 32 bits and Address6 to 128, so whenever the leading bits agree the strings are equal: new Address6('a00::1').isInSubnet(new Address4('10.0.0.0/8')) is true, and new Address4('32.0.0.1').isInSubnet(new Address6('2000::/3')) is true. No IPv4 address is inside an IPv6 network, so both answers are untrue. An application that parses untrusted input as whichever family accepts it and then tests the result against a fixed-family allowlist can admit an address outside the list. Details Both methods are in src/common.ts: mask(n) returns the first n bits of the address as a string of 0 and 1, taken from a representation padded to the family's width. new Address6('a00::1').mask(8) is '00001010', and so is new Address4('10.0.0.0/8').mask(), so string equality reports containment. The signature admits either…

    Recommended action: Upgrade to 10.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  3. Medium, CVSS 6.3npmAmendedPublished

    ip-address: Address6 builds a parse diagnostic proportional to the input with no length bound, allowing a single long string to stall or crash the process

    CVE-2026-101911 · GHSA-h3mg-xc3c-68pw

    Affected
    • npm ip-address <= 10.7.0
    Fixed in
    10.7.1· Vendor fix available
    Issue
    new Address6() and Address6.isValid() place no bound on the length of the string they parse. When the string contains a character that cannot appear in an IPv6 address, the parser builds a diagnostic that wraps every such character in a 34-byte <span class="parse-error", so the work and the memory scale with the input rather than with an address. A 1 MiB string of ! costs about 110 MB and 70 ms of synchronous work, 8 MiB costs about 800 MB and half a second, 16 MiB throws a RangeError in place of the documented AddressError, and 32 MiB aborts the Node process. isValid() builds the diagnostic and discards it, so a caller that only asks whether a string is valid pays the full price. An application that validates an attacker-supplied string with these methods can be stalled or crashed by a single oversized request. This is a crash on input that should have been rejected cleanly, which SECURITY.md lists as in scope. Details parse() in src/ipv6.ts checks for characters outside…

    Recommended action: Upgrade to 10.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  4. Medium, CVSS 6.3npmAmendedPublished

    ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts

    CVE-2026-101913 · GHSA-rpw4-54j3-4h4q

    Affected
    • npm ip-address <= 10.5.0
    Fixed in
    10.5.1· Vendor fix available
    Issue
    Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10. Link-local unicast is the whole /10 under RFC 4291 §2.4 and the IANA IPv6 Special-Purpose Address Registry, so the method returns false for every link-local address outside the one /64 that stateless address autoconfiguration happens to use. new Address6('fe81::1').isLinkLocal() is false. The library contradicts itself on the same object: for fe81::1, getType() returns 'Link-local unicast', getScope() returns 'Link local', and isHostInSubnet(new Address6('fe80::/10')) returns true, while isLinkLocal() returns false. 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 a link-local target as unremarkable and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach. Details…

    Recommended action: Upgrade to 10.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  5. Medium, CVSS 6.9npmAmendedPublished

    ip-address: no classifier recognizes the NAT64 local-use range 64:ff9b:1::/48, allowing SSRF and trust-boundary bypass

    CVE-2026-101910 · GHSA-2vr4-cq9g-pvrc

    Affected
    • npm ip-address >= 10.2.0, <= 10.5.0
    Fixed in
    10.5.1· Vendor fix available
    Issue
    No classifier on Address6 recognizes the NAT64 local-use range 64:ff9b:1::/48 (RFC 8215). isPrivate(), isLoopback(), isLinkLocal() and their siblings all return false for every address in it, so an internal IPv4 destination written through a local-use NAT64 prefix (64:ff9b:1:7f00:0:100:: for 127.0.0.1, 64:ff9b:1:a9fe:a9:fe00:: for 169.254.169.254) reads as an ordinary global address. getType() names the range 'NAT64 (local-use)', so the library knows what the address is and classifies it as nothing. 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. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint. Details The fix for GHSA-22jq-vg5j-6vgg (10.2.1)…

    Recommended action: Upgrade to 10.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  6. High, CVSS 7.7npmPublished

    ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass

    CVE-2026-69192 · GHSA-mwp4-54f8-5fhr

    Affected
    • npm ip-address <= 10.3.0
    Fixed in
    10.3.1· Vendor fix available
    Issue
    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. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint. Details Address4.parse gates untrusted input on READDRESS (src/v4/constants.ts:5), whose per-octet alternative is: The [01]?[0-9][0-9]? branch matches a…

    Recommended action: Upgrade to 10.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  7. Medium, CVSS 6.9npmPublished

    ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks

    CVE-2026-69198 · GHSA-4xrf-jv44-h6hh

    Affected
    • npm ip-address >= 10.1.1, <= 10.2.1
    Fixed in
    10.2.2· Vendor fix available
    Issue
    Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata…

    Recommended action: Upgrade to 10.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  8. Medium, CVSS 6.9npmAmendedPublished

    ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks

    CVE-2026-54272 · GHSA-22jq-vg5j-6vgg

    Affected
    • npm ip-address >= 10.1.1, <= 10.2.0
    Fixed in
    10.2.1· Vendor fix available
    Issue
    Address6's special-property checks misclassify IPv4-mapped (::ffff:0:0/96) and NAT64 well-known (64:ff9b::/96) IPv6 addresses. These checks classify an address by its IPv6 wrapper rather than by the IPv4 address it embeds, so isLoopback(), isLinkLocal(), isMulticast(), and isUnspecified() all return false for literals such as ::ffff:127.0.0.1 or ::ffff:169.254.169.254 that actually route to loopback, RFC 1918, or link-local (cloud-metadata) destinations. Address6 also had no isPrivate() method, so a mapped RFC 1918 address could not be detected at all. 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) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata…

    Recommended action: Upgrade to 10.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  9. Medium, CVSS 5.3npmAmendedPublished

    ip-address has XSS in Address6 HTML-emitting methods

    CVE-2026-42338 · GHSA-v2v4-37r5-5v8g

    Affected
    • npm ip-address <= 10.1.0
    Fixed in
    10.1.1· Vendor fix available
    Issue
    Address6.group() and Address6.link() do not HTML-escape attacker-controlled content before embedding it in the HTML strings they return, and AddressError.parseMessage (emitted by the Address6 constructor for invalid input) can contain unescaped attacker-controlled content in one branch. An application that (1) passes untrusted input to Address6 and (2) renders the output of these methods, or the thrown error's parseMessage, as HTML (e.g. via innerHTML) is vulnerable to cross-site scripting. A related issue in v6.helpers.spanAll() produced malformed markup but was not exploitable; it is hardened in the same release for consistency. Details Four related issues were identified and fixed together: 1. Address6.group(): zone ID injection. The Address6 constructor stores the raw input (including any IPv6 zone ID) in this.address before zone stripping. group() then passed this.address to helpers.simpleGroup(), which wrapped each :-separated segment in a <span element without…

    Recommended action: Upgrade to 10.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →