How Octal IP Address Parsing Leads to SSRF in Node.js and How to Fix It

How Octal IP Address Parsing Leads to SSRF in Node.js and How to Fix It

The Vulnerability Discovered

In the backend service dependencies, a critical parsing inconsistency was discovered in the ip-address library (version 9.0.5) that could allow attackers to bypass IP-based access controls and perform Server-Side Request Forgery (SSRF) attacks. The vulnerability, tracked as CVE-2026-69192, stems from how the library's Address4 class interprets IP octets with leading zeros—treating them as decimal while standard DNS resolvers interpret them as octal.

This means an IP address like 192.168.001.1 would be decoded as 192.168.1.1 by the vulnerable library, but as 192.168.1.1 (octal 001 = decimal 1) by resolvers, creating a dangerous parsing divergence. For addresses like 192.168.010.1, the library would see 192.168.10.1 (decimal), while resolvers would see 192.168.8.1 (octal 010 = decimal 8)—a completely different target.

Understanding the Attack Surface

The vulnerability affects any Node.js application using ip-address 9.0.5 or earlier that:

1. Validates incoming URLs or IP addresses against a whitelist
2. Makes outbound HTTP requests based on user-supplied input
3. Implements IP-based access controls or rate limiting
4. Processes proxy configurations with IP restrictions

The attack scenario is straightforward: An attacker provides a URL like http://192.168.010.1/internal-api to the application. The vulnerable ip-address library validates this as 192.168.10.1 (decimal interpretation), which might pass the whitelist. However, when the application actually makes the HTTP request, the DNS resolver interprets 192.168.010.1 as 192.168.8.1 (octal interpretation), potentially reaching an unintended internal service.

The Root Cause: Parsing Divergence

The issue lies in how the Address4 class in ip-address 9.0.5 handled octet parsing. When encountering an octet like 010, the library would:

1. Strip the leading zero
2. Parse 10 as a decimal number
3. Return the value as 10

However, standard IP address parsing—used by DNS resolvers, browsers, and operating systems—follows RFC 3986 and legacy Unix conventions where leading zeros indicate octal notation. Therefore:

• 010 in octal = 8 in decimal
• 001 in octal = 1 in decimal
• 077 in octal = 63 in decimal

This divergence means the ip-address library and the actual network stack interpret the same input differently, creating a trust-boundary bypass opportunity.

The Vulnerable Code Pattern

In backend/package.json, the vulnerable dependency was specified as:

"ip-address": "^9.0.5",

The Address4 parsing logic in version 9.0.5 would process octets without properly accounting for leading-zero octal semantics. When the application used this library to validate IP addresses before making HTTP requests or checking access controls, it would make decisions based on the wrong IP address.

Example vulnerable code flow:

// Vulnerable pattern (using ip-address 9.0.5)
const Address4 = require('ip-address').Address4;

// User provides this URL
const userUrl = "http://192.168.010.1/admin";

// Extract and validate IP
const ipStr = "192.168.010.1";
const addr = new Address4(ipStr);

// Library validates as 192.168.10.1 (decimal)
if (whitelist.includes(addr.toString())) {
  // This passes! But...
  const response = await fetch(userUrl);
  // ...the actual DNS resolution interprets 192.168.010.1 as 192.168.8.1 (octal)
  // Attacker reaches an unintended internal service!
}

The toString() method would return 192.168.10.1, but the actual network request resolves 192.168.010.1 as 192.168.8.1, bypassing the whitelist entirely.

The Fix: Upgrading to ip-address 10.3.1

The fix involved upgrading the ip-address library from 9.0.5 to 10.3.1, which corrects the octal parsing behavior. This change appears in two files:

In backend/package.json:

- "ip-address": "^9.0.5",
+ "ip-address": "^10.3.1",

In backend/pnpm-lock.yaml:

  ip-address:
-   specifier: ^9.0.5
-   version: 9.0.5
+   specifier: ^10.3.1
+   version: 10.3.1

Version 10.3.1 of the ip-address library now correctly interprets leading-zero octets as octal notation, aligning with RFC 3986 and standard resolver behavior. The Address4 class now properly handles:

• 192.168.010.1 → correctly parsed as 192.168.8.1 (octal 010 = decimal 8)
• 192.168.001.1 → correctly parsed as 192.168.1.1 (octal 001 = decimal 1)
• 10.0.0.1 → correctly parsed as 10.0.0.1 (no leading zeros, decimal interpretation)

After the fix:

// Secure pattern (using ip-address 10.3.1)
const Address4 = require('ip-address').Address4;

const ipStr = "192.168.010.1";
const addr = new Address4(ipStr);

// Library now correctly interprets as 192.168.8.1 (octal)
console.log(addr.toString()); // "192.168.8.1"

// If 192.168.8.1 is NOT in the whitelist, the request is blocked
if (whitelist.includes(addr.toString())) {
  // This now correctly fails if 192.168.8.1 isn't explicitly whitelisted
  const response = await fetch(userUrl);
}

The fix ensures that the library's IP parsing matches what actually happens when the application makes network requests, eliminating the parsing divergence that enabled the attack.

Why This Matters

This vulnerability is particularly dangerous because:

1. Silent bypass: The application appears to validate correctly, but the actual network behavior differs
2. Trust-boundary violation: Attackers can reach resources they shouldn't access
3. SSRF enablement: Combined with other application logic, this enables full SSRF attacks
4. Widespread impact: Any IP-based access control using the vulnerable library is affected

The parsing divergence is subtle enough that developers might not realize their whitelist validation doesn't match actual network behavior. An attacker could systematically probe internal IP ranges using octal notation to discover and access internal services.

Prevention & Best Practices

To prevent similar vulnerabilities in your Node.js applications:

1. Keep IP parsing libraries updated: Regularly update ip-address and similar libraries. Use tools like npm audit and Dependabot to track vulnerable dependencies.

2. Validate IP addresses consistently: Use the same parsing logic for validation and actual network operations. Don't mix libraries.

3. Test with edge cases: Include test cases for IP addresses with leading zeros:
   javascript const testCases = [ "192.168.010.1", // Octal notation "10.0.0.1", // Standard notation "127.000.000.001" // All octal ];

4. Implement defense-in-depth: Don't rely solely on IP-based access controls. Combine with:
   - Authentication and authorization checks
   - Rate limiting
   - Request logging and monitoring
   - Network segmentation

5. Use RFC 3986 compliant parsers: Ensure your IP parsing library follows RFC 3986 standards for octal notation.

6. Enable security scanning: Use tools like Trivy, Snyk, or npm audit to automatically detect vulnerable dependency versions.

Key Takeaways

• Octal notation in IP addresses (leading zeros) is interpreted differently by the vulnerable ip-address 9.0.5 library versus standard DNS resolvers, creating a parsing divergence that allows SSRF attacks.
• IP address 192.168.010.1 is parsed as 192.168.10.1 by the vulnerable library but resolves to 192.168.8.1 by DNS, enabling attackers to bypass IP whitelists.
• The fix (upgrading to ip-address 10.3.1) aligns the library's parsing with RFC 3986 standards, ensuring leading zeros are correctly interpreted as octal.
• IP-based access controls must be consistent across validation and actual network operations—a mismatch creates a security boundary vulnerability.
• Defense-in-depth strategies are essential: IP validation alone is insufficient; combine with authentication, authorization, and monitoring.

How Orbis AppSec Detected This

Source: Dependency specification in backend/package.json where ip-address version 9.0.5 is declared as a direct dependency for IP address parsing operations.

Sink: The Address4 class from the ip-address library, used to parse and validate IP addresses before making outbound HTTP requests or checking IP-based access controls.

Missing control: The vulnerable version (9.0.5) lacks proper RFC 3986 compliance for octal notation in IP octets. It treats leading-zero octets as decimal instead of octal, creating a parsing divergence with standard DNS resolvers.

CWE: CWE-1025 (Comparison Using Wrong Factors) and CWE-918 (Server-Side Request Forgery (SSRF)).

Fix: Upgrade ip-address from 9.0.5 to 10.3.1, which corrects the Address4 parsing logic to properly interpret leading-zero octets as octal notation, aligning with RFC 3986 and standard resolver behavior.

Orbis AppSec automatically detected this vulnerability through dependency scanning and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-69192 demonstrates a subtle but critical class of vulnerabilities: parsing inconsistencies that create trust-boundary bypasses. When different components of your application interpret the same input differently, security controls fail silently. The fix—upgrading ip-address to 10.3.1—ensures that IP address parsing is consistent across your application and the underlying network stack.

This vulnerability is a reminder that security isn't just about detecting malicious input; it's about ensuring that security controls actually match the behavior they're meant to protect. Always validate that your parsing logic aligns with how data is actually used downstream, and keep dependencies updated to benefit from security fixes that address these subtle inconsistencies.