{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/ssrfcheck--1.3.0/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["ssrfcheck (\u003c= 1.3.0)"],"_cs_severities":["high"],"_cs_tags":["ssrf","vulnerability","node.js"],"_cs_type":"advisory","_cs_vendors":["npm"],"content_html":"\u003cp\u003eThe \u003ccode\u003essrfcheck\u003c/code\u003e library, version 1.3.0 and earlier, contains a critical vulnerability that allows attackers to bypass its SSRF protection mechanisms. The vulnerability stems from the library\u0026rsquo;s failure to properly handle IPv4 addresses encoded as IPv4-mapped IPv6 addresses (e.g., \u003ccode\u003ehttp://[::ffff:127.0.0.1]/\u003c/code\u003e). The WHATWG URL parser, which is integrated into Node.js, normalizes the IPv4 notation inside the brackets to a compressed hex form before \u003ccode\u003essrfcheck\u003c/code\u003e\u0026rsquo;s private IP regex is executed. This normalization bypasses the regex, which is designed to match dot-notation only. As a result, applications using the \u003ccode\u003eisSSRFSafeURL()\u003c/code\u003e function are exposed to SSRF attacks, potentially allowing attackers to access cloud metadata, internal network resources, and localhost services. This vulnerability affects all Node.js versions greater than or equal to 10.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an application using \u003ccode\u003essrfcheck\u003c/code\u003e for URL validation.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL containing a private IP address encoded as an IPv4-mapped IPv6 address, such as \u003ccode\u003ehttp://[::ffff:127.0.0.1]/\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application receives the URL from an untrusted source (e.g., user input, API parameter, webhook payload).\u003c/li\u003e\n\u003cli\u003eThe application calls \u003ccode\u003eisSSRFSafeURL()\u003c/code\u003e to validate the URL.\u003c/li\u003e\n\u003cli\u003eThe WHATWG URL parser normalizes the IPv4 notation inside the brackets (e.g., \u003ccode\u003e127.0.0.1\u003c/code\u003e becomes \u003ccode\u003e7f00:1\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eisPrivateIP\u003c/code\u003e function attempts to match the normalized IP address against its regex, but the regex fails because it expects dot notation.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eisSSRFSafeURL()\u003c/code\u003e returns true, indicating that the URL is safe.\u003c/li\u003e\n\u003cli\u003eThe application makes an HTTP request to the attacker-controlled URL, leading to SSRF. The attacker can now access internal resources, cloud metadata, or localhost services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability can lead to significant security breaches. An attacker can potentially steal cloud metadata from AWS, GCP, or Azure instances by sending a request to \u003ccode\u003ehttp://[::ffff:169.254.169.254]/latest/metadata\u003c/code\u003e. This metadata often contains sensitive information such as API keys and credentials. The attacker can also pivot to internal network resources that are not exposed to the internet, accessing services on \u003ccode\u003e10.x.x.x\u003c/code\u003e, \u003ccode\u003e172.16.x.x\u003c/code\u003e, or \u003ccode\u003e192.168.x.x\u003c/code\u003e. Furthermore, the attacker can access services bound to loopback on the server, such as administrative interfaces at \u003ccode\u003ehttp://[::ffff:127.0.0.1]/admin\u003c/code\u003e. The bypass requires no authentication, special privileges, or non-default configurations. This vulnerability affects every version of \u003ccode\u003essrfcheck\u003c/code\u003e on every Node.js version \u0026gt;= 10, creating a widespread risk for applications relying on this library for SSRF protection.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of \u003ccode\u003essrfcheck\u003c/code\u003e that addresses this vulnerability.\u003c/li\u003e\n\u003cli\u003eAs a workaround, implement a custom URL validation function that explicitly checks for IPv4-mapped IPv6 addresses and blocks them before calling \u003ccode\u003eisSSRFSafeURL()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor application logs for suspicious outbound HTTP requests to private IP addresses or cloud metadata endpoints.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect SSRF Attempt via IPv4-mapped IPv6 Address\u003c/code\u003e to detect potential SSRF attempts in web server logs.\u003c/li\u003e\n\u003cli\u003eBlock the IOCs listed in this brief at the network or application level to prevent attackers from exploiting this vulnerability.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-06T12:00:00Z","date_published":"2026-05-06T12:00:00Z","id":"/briefs/2026-05-ssrfcheck-ssrf/","summary":"ssrfcheck version 1.3.0 and earlier is vulnerable to server-side request forgery (SSRF) attacks because it fails to block private IP addresses encoded as IPv4-mapped IPv6 addresses due to WHATWG URL parsing.","title":"ssrfcheck vulnerable to SSRF via IPv4-mapped IPv6 bypass","url":"https://feed.craftedsignal.io/briefs/2026-05-ssrfcheck-ssrf/"}],"language":"en","title":"CraftedSignal Threat Feed — Ssrfcheck (\u003c= 1.3.0)","version":"https://jsonfeed.org/version/1.1"}