CVE-2024-29415: Node.js IP Package SSRF Vulnerability

CVE-2024-29415 Overview

CVE-2024-29415 is a Server-Side Request Forgery (SSRF) vulnerability affecting the ip package through version 2.0.1 for Node.js. The vulnerability exists because certain IP addresses are improperly categorized as globally routable via the isPublic function when they should be recognized as private or loopback addresses. This allows attackers to bypass SSRF protections that rely on the ip package for IP address validation.

The vulnerability stems from an incomplete fix for a previous vulnerability, CVE-2023-42282, which addressed similar IP address validation issues. Various IP address representations including octal notation (e.g., 01200034567, 012.1.2.3), shorthand formats (e.g., 127.1), IPv6 mixed notation (e.g., ::fFFf:127.0.0.1), and compressed IPv6 formats (e.g., 000:0:0000::01) can bypass the isPublic check and be incorrectly classified as publicly routable addresses.

Critical Impact

Applications using the ip package to validate user-supplied IP addresses before making network requests may be vulnerable to SSRF attacks, potentially allowing attackers to access internal services, cloud metadata endpoints, and other protected resources.

Affected Products

• Node.js ip package through version 2.0.1
• Applications using the ip package for IP address validation in SSRF protection mechanisms
• Systems relying on isPublic() function for distinguishing internal from external IP addresses

Discovery Timeline

• 2024-05-27 - CVE-2024-29415 published to NVD
• 2025-01-17 - Last updated in NVD database

Technical Details for CVE-2024-29415

Vulnerability Analysis

The ip package provides utility functions for working with IP addresses in Node.js applications, including the isPublic() function that determines whether an IP address is publicly routable. A common security pattern involves using this function to prevent SSRF by rejecting requests to private or loopback addresses.

The vulnerability occurs because the isPublic() function fails to properly handle various non-standard IP address representations that resolve to private or loopback addresses. When an application uses this function to validate user-supplied URLs or IP addresses before making HTTP requests, an attacker can craft specially formatted IP addresses that pass the isPublic() check but actually resolve to internal addresses.

For example, 127.1 resolves to 127.0.0.1 (localhost), and octal-encoded addresses like 012.1.2.3 can represent different addresses than their decimal equivalents. The IPv6 mixed format ::fFFf:127.0.0.1 is an IPv4-mapped IPv6 address pointing to localhost.

Root Cause

The root cause is inadequate input normalization and validation in the IP address parsing logic. The isPublic() function does not properly canonicalize IP addresses before checking them against private and reserved IP ranges. This allows various alternative representations of the same IP address to produce different validation results.

This issue represents an incomplete remediation of CVE-2023-42282, indicating that the original fix did not comprehensively address all possible IP address encoding variations that could be used to bypass the validation logic.

Attack Vector

The attack requires network access and involves an attacker supplying maliciously crafted IP addresses to an application that uses the vulnerable ip package for SSRF protection. The attack flow typically follows this pattern:

1. Attacker identifies an application endpoint that accepts user-controlled URLs or IP addresses
2. The application uses ip.isPublic() to validate that the target is not an internal address
3. Attacker supplies a URL containing a specially formatted IP address (e.g., http://127.1/, http://012.1.2.3/)
4. The isPublic() function incorrectly returns true, classifying the address as publicly routable
5. The application proceeds to make a request to what is actually an internal address
6. Attacker gains access to internal services, cloud metadata endpoints, or other protected resources

The vulnerability can be exploited to access cloud provider metadata services (typically at 169.254.169.254), internal APIs, administrative interfaces, or any other services reachable from the vulnerable server but not intended to be publicly accessible.

Detection Methods for CVE-2024-29415

Indicators of Compromise

• Unusual outbound network requests from application servers to loopback or private IP ranges
• Access logs showing requests with non-standard IP address formats (octal notation, shorthand formats, IPv6 mixed notation)
• Requests to cloud metadata endpoints (169.254.169.254) from application servers
• Error logs indicating failed connections to internal services that should not be accessible from the application

Detection Strategies

• Audit application dependencies for vulnerable versions of the ip package using npm audit or similar dependency scanning tools
• Monitor network traffic for connections to private IP ranges originating from web application servers
• Implement Web Application Firewall (WAF) rules to detect and block non-standard IP address formats in user input
• Review application logs for URL parameters containing octal-encoded or shorthand IP addresses

Monitoring Recommendations

• Enable detailed logging for all outbound HTTP requests made by the application
• Configure alerts for network connections from application servers to RFC 1918 private address ranges or localhost
• Monitor for access patterns consistent with SSRF exploitation, such as sequential probing of internal IP addresses
• Implement anomaly detection for unusual destination IPs in outbound traffic from application servers

How to Mitigate CVE-2024-29415

Immediate Actions Required

• Update the ip package to a patched version if available, or implement additional validation layers
• Review all code paths that use ip.isPublic() or similar functions for SSRF protection
• Implement defense-in-depth measures by combining IP validation with network-level controls
• Consider using allowlists of permitted external hosts rather than blocklists of internal addresses

Patch Information

The vulnerability was initially reported through GitHub Issue #150. Proposed fixes are available in GitHub Pull Request #143 and GitHub Pull Request #144. NetApp has also issued a security advisory addressing this vulnerability in their affected products via NetApp Security Advisory ntap-20250117-0010.

Organizations should monitor the node-ip repository for an official patched release and apply updates as soon as they become available.

Workarounds

• Implement additional IP address normalization before calling validation functions to convert all representations to a canonical format
• Use network-level controls such as egress firewall rules to prevent application servers from connecting to internal address ranges
• Consider alternative IP validation libraries that properly handle non-standard address formats
• Implement a URL allowlist approach that only permits requests to explicitly approved external domains rather than attempting to block internal addresses

# Configuration example: Egress firewall rules to block internal access (iptables)
# Block outbound connections to loopback from application user
iptables -A OUTPUT -o lo -m owner --uid-owner www-data -j DROP

# Block RFC 1918 private ranges
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner www-data -j DROP

# Block link-local and metadata service
iptables -A OUTPUT -d 169.254.0.0/16 -m owner --uid-owner www-data -j DROP