CVE-2026-44492

What it actually does

Axios versions prior to 0.32.0 and 1.16.0 do not normalize IPv4-mapped IPv6 addresses before evaluating proxy bypass rules. If an application relies on NO_PROXY entries such as 127.0.0.1, localhost-equivalent IPv4 addresses, or cloud metadata IPs like 169.254.169.254 to prevent proxying of sensitive internal destinations, an attacker-controlled URL using an IPv4-mapped IPv6 representation can bypass that logic. Node.js then resolves the mapped address to the underlying IPv4 destination, causing the request to reach an internal service through the configured proxy. The primary technical impact is server-side request forgery that can expose internal-only HTTP services or cloud instance metadata to an unauthenticated remote attacker when the vulnerable application fetches attacker-supplied URLs with Axios and a proxy configuration.

Why it matters to the business

Applications using vulnerable Axios versions may unintentionally allow external attackers to access internal services, local administrative endpoints, or cloud metadata endpoints that were expected to be protected by proxy bypass rules. In cloud environments, successful exploitation could expose temporary credentials, instance identity documents, or service tokens, potentially leading to broader compromise. The CVSS score is high, but EPSS is currently low and there is no known CISA KEV listing or reported ransomware use, so urgency should be driven by whether Axios is used for user-controlled outbound requests in proxied server-side applications.

How an attack unfolds

An attacker first identifies an application feature that causes the server to make outbound HTTP requests using Axios, such as URL preview, webhook delivery, file import, callback validation, feed fetching, or integration testing. The attacker then supplies a target URL encoded as an IPv4-mapped IPv6 address rather than the normal IPv4 address. For example, instead of requesting 169.254.169.254, the attacker supplies a URL containing ::ffff:a9fe:a9fe. The application passes this URL to a vulnerable Axios version. Axios evaluates the destination against NO_PROXY but fails to normalize the IPv4-mapped IPv6 address to its IPv4 equivalent, so entries such as 169.254.169.254 or 127.0.0.1 do not match as intended. The request is sent through the configured proxy and Node.js resolves the IPv4-mapped IPv6 address to the underlying IPv4 host. If the proxy can reach the destination, the attacker may receive responses from internal services, local-only endpoints, or cloud metadata APIs through the vulnerable application.

How to fix it

Upgrade Axios to a fixed version: use Axios 0.32.0 or later on the 0.x line, or Axios 1.16.0 or later on the 1.x line. Because Axios is commonly pulled in transitively, update lockfiles and verify that all deployed applications resolve to a fixed Axios version, not only direct package declarations. If immediate upgrade is not possible, add defense-in-depth controls around outbound requests: reject all loopback, link-local, private, multicast, and reserved address ranges after canonical DNS and IP normalization; explicitly normalize IPv4-mapped IPv6 addresses before policy checks; block requests to cloud metadata endpoints; enforce allowlists for user-supplied destinations; and restrict egress from application servers and proxies to only required external destinations. Do not rely on NO_PROXY alone as an SSRF control.

How to confirm the fix worked

Confirm the deployed dependency tree no longer contains vulnerable Axios versions by running package-manager checks such as npm ls axios, yarn why axios, pnpm why axios, or equivalent software composition analysis. Validate that the effective runtime version is Axios 0.32.0 or later for 0.x deployments, or 1.16.0 or later for 1.x deployments. Test application SSRF defenses using safe, controlled requests containing IPv4-mapped IPv6 forms such as http://[::ffff:7f00:1]/ and http://[::ffff:a9fe:a9fe]/ and verify that the application blocks or safely handles them. Review proxy logs to ensure these addresses are not forwarded to loopback, link-local, metadata, or other internal destinations. Also verify that egress firewalls or proxy ACLs prevent access to 127.0.0.0/8, 169.254.0.0/16, RFC1918 networks, and other internal ranges from application request paths that handle untrusted URLs.

Typical attack path

1. Find an application endpoint that accepts a URL, webhook target, callback address, feed URL, import location, or other externally supplied destination.
2. Confirm the server performs outbound HTTP requests using Axios and that responses, errors, timing, or side effects are observable.
3. Choose an internal IPv4 target that is commonly protected by NO_PROXY, such as 127.0.0.1 or 169.254.169.254.
4. Convert the IPv4 target into an IPv4-mapped IPv6 representation, such as ::ffff:7f00:1 for 127.0.0.1 or ::ffff:a9fe:a9fe for 169.254.169.254.
5. Submit a URL using the mapped IPv6 address to the vulnerable application.
6. Axios fails to normalize the address before proxy-bypass evaluation, so the request is routed through the configured proxy instead of being blocked or bypassed as expected.
7. Node.js resolves the mapped IPv6 address to the underlying IPv4 destination.
8. The attacker observes internal service responses, metadata output, credentials, tokens, or other sensitive data exposed by the server-side request.

How to detect it

Investigate whether exposed application features accepted externally supplied URLs and made outbound Axios requests through a proxy. Review application logs, API request logs, reverse proxy logs, outbound proxy logs, and egress firewall logs for URLs containing IPv4-mapped IPv6 syntax, especially requests targeting loopback or cloud metadata equivalents. Focus on bracketed IPv6 literals in HTTP URLs such as http://[::ffff:7f00:1]/ and http://[::ffff:a9fe:a9fe]/, and on outbound proxy connections that resolved to 127.0.0.1, 169.254.169.254, RFC1918 ranges, or internal service ports. In cloud environments, correlate application request timestamps with metadata service access logs or instance credential use, including unusual calls to metadata paths such as /latest/meta-data/, /latest/api/token, or IAM/security-credentials endpoints. Review WAF and API gateway logs for attacker-supplied parameters containing ::ffff:, percent-encoded bracket characters, or unusual IPv6 URL literals. Where request bodies are logged, search webhook, callback_url, url, target, feed, import, image, avatar, redirect, and endpoint parameters for mapped IPv6 values. Treat successful responses, metadata path access, or immediate follow-on use of newly issued cloud credentials as strong evidence of exploitation.

• ::ffff:7f00:1
• ::ffff:a9fe:a9fe
• http://[::ffff:7f00:1]
• https://[::ffff:7f00:1]
• http://[::ffff:a9fe:a9fe]
• https://[::ffff:a9fe:a9fe]
• [::ffff:127.0.0.1]
• [::ffff:169.254.169.254]
• 0:0:0:0:0:ffff:7f00:1
• 0:0:0:0:0:ffff:a9fe:a9fe
• /latest/meta-data/
• /latest/api/token
• /latest/meta-data/iam/security-credentials/
• 169.254.169.254
• 127.0.0.1
• ::ffff:

What your security team should do

• Inventory applications and services that use Axios, especially Node.js services that accept user-controlled URLs or make webhook, callback, preview, import, or integration requests.
• Prioritize remediation for server-side applications running behind HTTP, HTTPS, or SOCKS proxies with NO_PROXY configured for internal addresses or cloud metadata endpoints.
• Upgrade Axios to 0.32.0 or later on the 0.x branch, or 1.16.0 or later on the 1.x branch, and rebuild/redeploy containers, serverless packages, and bundled artifacts.
• Search dependency lockfiles and SBOMs for vulnerable Axios versions, including transitive dependencies that may not appear in top-level package manifests.
• Implement normalized destination validation that blocks loopback, link-local, private, reserved, and IPv4-mapped IPv6 representations before making outbound requests.
• Restrict proxy and network egress so application workloads cannot reach cloud metadata services, loopback-only administration interfaces, or internal networks unless explicitly required.
• Review proxy, application, and cloud metadata access logs for IPv4-mapped IPv6 request patterns and suspicious requests to 169.254.169.254 or localhost-equivalent destinations.
• Add regression tests for IPv4, IPv6, IPv4-mapped IPv6, hexadecimal, octal, decimal, and DNS-rebinding style address representations in all SSRF protection code.