CVE-2026-57862 is an SSRF bypass in Kanboard that exploits a gap most developers don't know exists: FILTER_VALIDATE_IP rejects hex notation like 0x7F000001 (which resolves to 127.0.0.1) because it doesn't match dotted-decimal format—not because it's safe. The isPrivateURL() function treats this rejection as permission to connect, but cURL resolves the hex to its actual address before connecting. The connection happens. The developer thought they were checking what the network layer would check. They weren't.
The underlying flaw is not specific to hex notation. IPv6 loopback, IPv4-mapped IPv6 addresses, or any hostname that resolves to internal infrastructure would trigger the same gap. The function was never checking whether the connection would reach internal infrastructure—it was only checking whether the input looked like a dotted-decimal IPv4 address. That distinction is the real vulnerability.
For defenders: audit any code that uses FILTER_VALIDATE_IP, FILTER_VALIDATE_URL, or similar filters as SSRF mitigations. The pattern if (!filter_var($input, FILTER_VALIDATE_IP)) { // allow } is a known anti-pattern. The correct approach is to resolve the input first—perform DNS resolution or use gethostbyname()—then validate the resolved address. If the input is a hostname, resolve it before checking whether it lands in private address space.
The broader pattern here recurs across ecosystems. Python's urllib, path traversal filters, and other security boundaries have all suffered from the same root cause: validating the input string rather than the value the downstream component will actually use. The fix is always the same: validate what happens after resolution, not what arrives in the request.