Safeurl
Monthly
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Server-side request forgery protection bypass in Slab safeurl (Elixir) 0.1.0 and later lets an attacker who controls authoritative DNS for a submitted hostname reach internal network destinations that validation had rejected. The library validates one DNS lookup but returns only a verdict rather than the approved address, so the bundled HTTPoison client resolves the original hostname a second time at request time and can be steered to a blocked internal IP. Exploitation is conditional - the attacker must control DNS for the name, win the resolution race, and the host application must route user-influenced URLs through safeurl (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N, high confidentiality impact); no public exploit code or confirmed active exploitation was identified at time of analysis, and the same race can occur non-maliciously with short-TTL or rotating DNS records.
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Server-side request forgery protection bypass in Slab safeurl (Elixir) 0.1.0 and later lets an attacker who controls authoritative DNS for a submitted hostname reach internal network destinations that validation had rejected. The library validates one DNS lookup but returns only a verdict rather than the approved address, so the bundled HTTPoison client resolves the original hostname a second time at request time and can be steered to a blocked internal IP. Exploitation is conditional - the attacker must control DNS for the name, win the resolution race, and the host application must route user-influenced URLs through safeurl (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N, high confidentiality impact); no public exploit code or confirmed active exploitation was identified at time of analysis, and the same race can occur non-maliciously with short-TTL or rotating DNS records.