CVE-2024-29415

What it actually does

The Node.js `ip` package through version 2.0.1 can incorrectly classify non-standard textual representations of loopback or otherwise non-public addresses as publicly routable when using `isPublic`. Applications that rely on this function to block access to internal, loopback, link-local, metadata, or private network destinations may allow crafted IP literals to bypass SSRF protections. The flaw is an incomplete fix for a prior address-parsing issue and can affect any server-side feature that fetches, proxies, validates, scans, imports, previews, or otherwise connects to user-supplied URLs or IP addresses.

Why it matters to the business

If an exposed application uses the vulnerable package for URL or IP allow/deny decisions, attackers may be able to reach internal services that were assumed to be protected, including cloud metadata endpoints, administrative interfaces, internal APIs, databases, or service discovery endpoints. This can lead to credential theft, data exposure, service manipulation, or pivoting deeper into the network. Although exploitation requires the vulnerable package to be used in a security-sensitive SSRF control path and EPSS is currently moderate, the issue is important because the package is widely used across the Node.js ecosystem and the flaw has been public for a long time.

How an attack unfolds

An attacker first identifies an application feature that accepts a URL, hostname, or IP address and causes the backend server to initiate a network request, such as a webhook tester, image fetcher, URL previewer, import connector, proxy endpoint, PDF generator, scanner, or integration callback validator. The application attempts to prevent SSRF by using the `ip` package's `isPublic` function to reject private or loopback destinations. The attacker supplies a specially formatted IP address that represents a non-public target but is misclassified as public, such as shortened loopback notation, octal-like notation, IPv6 loopback variants, or IPv4-mapped IPv6 forms. If the application accepts the value and follows redirects or resolves the target as intended by the attacker, the backend connects to an internal destination. The attacker then uses the response, timing behavior, error messages, or side effects to enumerate internal services, retrieve sensitive metadata, access credentials, or interact with internal administrative endpoints.

How to fix it

Inventory Node.js applications and dependencies for use of the `ip` package through version 2.0.1, especially where `isPublic`, `isPrivate`, address parsing, URL validation, webhook validation, proxying, or outbound request filtering is used as a security control. Because no fixed version was provided in the input, do not rely on `ip.isPublic` from affected versions for SSRF prevention. Replace it with a maintained IP parsing and classification library that canonicalizes addresses before classification, or implement strict validation using platform-standard URL parsing plus robust IP normalization for IPv4, IPv6, IPv4-mapped IPv6, decimal, octal-like, hexadecimal, shortened, and encoded forms. Enforce outbound network egress controls at the network layer so applications cannot reach loopback, RFC1918, link-local, multicast, unique-local IPv6, cloud metadata, Kubernetes API, container bridge, or administrative address ranges unless explicitly required. Validate the final connection target after DNS resolution and after redirects, and block redirect chains that resolve to non-public addresses. Prefer explicit allowlists of approved domains or destinations over public/private blocklists for high-risk features.

How to confirm the fix worked

Confirm exposure by checking dependency manifests and lockfiles such as `package.json`, `package-lock.json`, `yarn.lock`, and `pnpm-lock.yaml` for `ip` versions up to and including 2.0.1. Review application code and transitive dependencies for calls to `isPublic` or related IP classification logic used before outbound requests. Build regression tests that submit ambiguous or alternate-form addresses such as `127.1`, `01200034567`, `012.1.2.3`, `000:0:0000::01`, and `::fFFf:127.0.0.1` to every URL-fetching feature and verify they are blocked. Confirm that redirects to loopback, private, link-local, and metadata addresses are blocked after each redirect and after DNS resolution. Validate network-layer mitigations by attempting controlled outbound requests from the application runtime to loopback, private ranges, and cloud metadata addresses and confirming they fail unless explicitly approved.

Typical attack path

1. Find an externally reachable application function that fetches or connects to user-supplied URLs or IP addresses.
2. Confirm the backend performs server-side network requests and returns response content, errors, timing differences, or other observable behavior.
3. Submit crafted representations of loopback or private destinations that may bypass `ip.isPublic`, such as `127.1`, `01200034567`, `012.1.2.3`, `000:0:0000::01`, or `::fFFf:127.0.0.1`.
4. Use the bypass to make the backend connect to internal services, localhost-only endpoints, cloud metadata services, or private network addresses.
5. Enumerate reachable internal hosts and ports using response differences, redirects, DNS behavior, or connection timing.
6. Extract sensitive data or credentials where accessible, or trigger state-changing actions against internal services.

How to detect it

Look for evidence that user-controlled URL or IP input contained unusual encodings of loopback, private, link-local, or metadata-service destinations. Useful sources include application request logs, reverse proxy and WAF logs, outbound proxy logs, DNS resolver logs, egress firewall flow logs, cloud metadata service access logs where available, container or Kubernetes network logs, and application error logs from URL-fetching features. Focus on requests containing shortened loopback addresses, octal-like IPv4 strings, IPv6 loopback variants, IPv4-mapped IPv6 addresses, redirect parameters, webhook URLs, callback URLs, import URLs, image URLs, and preview URLs. Correlate suspicious inbound parameters with outbound connections from the application to `127.0.0.0/8`, `::1`, RFC1918 ranges, link-local ranges such as `169.254.0.0/16`, cloud metadata endpoints such as `169.254.169.254`, Kubernetes service addresses, or localhost-only administrative ports. Also review whether the same source attempted port scanning patterns through repeated URL submissions, varied ports, or timing-based probes. If exploitation is suspected, examine responses returned to the attacker, application exceptions, credentials retrieved from metadata services, and any subsequent use of newly exposed cloud or service credentials.

• 127.1
• 01200034567
• 012.1.2.3
• 000:0:0000::01
• ::fFFf:127.0.0.1
• ::ffff:127.0.0.1
• [::ffff:127.0.0.1]
• http://127.1
• https://127.1
• http://01200034567
• http://012.1.2.3
• http://000:0:0000::01
• http://[000:0:0000::01]
• http://[::fFFf:127.0.0.1]
• 169.254.169.254
• http://169.254.169.254
• metadata.google.internal
• 169.254.170.2
• 100.100.100.200
• isPublic(

What your security team should do

• Prioritize internet-facing Node.js applications with URL fetch, webhook, proxy, import, crawler, preview, file conversion, or integration features.
• Search software composition analysis results and lockfiles for the `ip` package at versions up to and including 2.0.1, including transitive dependencies.
• Treat uses of `ip.isPublic` in request validation as unsafe until replaced or independently guarded by canonicalization and egress filtering.
• Add or strengthen outbound egress deny rules for loopback, private, link-local, multicast, IPv6 unique-local, container, orchestration, and cloud metadata address ranges.
• Add regression tests for non-standard IP formats and redirect-to-private-address scenarios in all SSRF-sensitive code paths.
• Review access logs, application logs, proxy logs, and egress telemetry for historical requests containing unusual loopback or IPv6-mapped address strings.
• If suspicious SSRF activity is found, rotate any credentials potentially exposed via metadata services or internal endpoints and investigate subsequent internal access.