Skip to content

IzPack has Path Traversal in UnpackerBase that allows writing files outside the installation directory via malicious pack entries

High severity GitHub Reviewed Published Jul 17, 2026 in izpack/izpack • Updated Aug 26, 2026

Package

maven org.codehaus.izpack:izpack-installer (Maven)

Affected versions

<= 5.2.6

Patched versions

None

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.

References

@reinhapa reinhapa published to izpack/izpack Jul 17, 2026
Published to the GitHub Advisory Database Aug 26, 2026
Reviewed Aug 26, 2026
Last updated Aug 26, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Changed
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(31st percentile)

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

CVE ID

CVE-2026-54550

GHSA ID

GHSA-f63g-88cj-hjf9

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.