CVE-2026-54550: Path Traversal Vulnerability in IzPack Installer Unpacker

IzPack is a widely utilized Java-based cross-platform installer framework. The installer core relies on an unpacker subsystem to extract archive assets to target locations on the local filesystem. Prior to version 5.2.7, the unpacking mechanism did not validate target extraction paths against directory traversal payloads, exposing a critical filesystem attack surface.\n\nAn attacker can construct a malicious installer package containing directory traversal sequences. When executed by an target user, the installation process extracts files outside the designated installation directory. This can result in arbitrary file writes under the security context of the user executing the installer.

The flaw resides within the unpack method of UnpackerBase.java located in the izpack-installer module. During execution, the application reads target paths directly from the pack metadata. These paths are processed through IoHelper.translatePath(), which normalizes path separators for the target operating system but does not perform logical canonicalization.\n\nBecause the resolution logic lacks directory containment checks, the application instantiates a File object using the untrusted, un-normalized string. It then writes the package contents directly to this filesystem location. This behavior maps to CWE-22, enabling filesystem boundary escape when the underlying operating system executes the file creation routines.

Before the implementation of the patch, the target validation was completely absent inside the extraction loop. The vulnerable implementation resolved paths as follows:\n\njava\n// Vulnerable Path Resolution\nString targetPath = packFile.getTargetPath();\nString path = IoHelper.translatePath(targetPath, variables);\nFile target = new File(path);\n\n\nThe remediated code implements validation at both compile-time and runtime. The patch adds lexical traversal detection inside PackFile.java and platform-specific sanitization checks within UnpackerBase.java:\n\njava\n// Patched Validation in PackFile.java\npublic static void validateTargetPath(String target) throws IOException {\n Objects.requireNonNull(target, \"target\");\n if (containsParentTraversal(target)) {\n throw new IOException(\"Installer target path must not contain path traversal: \" + target);\n }\n}\n\n\nAdditionally, the updated unpacker handles Windows-specific quirks, checking for reserved device names (CON, PRN, AUX, NUL) and trailing spaces or dots that can bypass standard security filters.

While the patch effectively mitigates direct parent-directory traversal via relative path segments, architectural limitations remain in the design. The containment verification implemented in UnpackerBase.validateTargetPath() generates a warning instead of a hard block when files are written outside the primary installation directory.\n\nThis behavior is preserved intentionally to support installers that must place configuration files into global system directories like /etc/ or C:/ProgramData. Consequently, an installer package compiled with malicious intent can still target arbitrary write locations using absolute paths, provided no relative path traversal is detected.\n\nFurthermore, because PackFile implements java.io.Serializable, an attacker could theoretically bypass the compile-time checks by manually crafting a serialized metadata payload. If the installer deserializes untrusted pack metadata before validating the target paths dynamically during execution, the defense-in-depth model relies entirely on the runtime validations inside UnpackerBase.

To execute this attack, a threat actor must distribute a trojanized installer package to a target user. The attack requires user interaction to run the installer, which executes with the active privileges of the victim's operating system process.\n\nmermaid\ngraph LR\n A[\"Attacker Crafts Package with ../ Paths\"] --> B[\"Victim Executes Trojanized Installer\"]\n B --> C[\"Unpacker Translates Raw Paths\"]\n C --> D[\"File Created Outside Target Directory\"]\n D --> E[\"Payload Written to Windows Startup Folder\"]\n\n\n\nDuring extraction, the path resolver converts traversal payloads like ../../../../AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/payload.exe relative to the installation root. The system writes the executable into the startup folder, ensuring persistence and arbitrary code execution upon subsequent system logon.

Remediation requires upgrading the IzPack packaging toolkit to a version greater than 5.2.6. Developers must rebuild existing installers using the updated compiler to ensure that the generated metadata packages include compile-time validation controls.\n\nOrganizations deploying legacy installers should perform static analysis on the distributed JAR files. Extracting and analyzing the packs.info file or embedded XML descriptors can identify the presence of ../ sequences or absolute paths pointing to sensitive system locations.