CVE-2026-54550 in IzPack
Summary
by MITRE • 08/26/2026
IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers. In 5.2.6 and earlier, UnpackerBase.unpack() in izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java obtains an attacker-controlled PackFile targetPath, passes it through IoHelper.translatePath(), which only converts separators, and constructs a File without normalizing parent-directory segments or enforcing destination containment. A malicious installer pack entry containing ../ sequences can therefore write outside the intended installation directory to startup folders, executable search paths, or other locations accessible with the victim's privileges when the victim runs the installer.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
IzPack is a widely utilized framework for creating cross-platform installers on the Java platform, enabling developers to package applications into self-extracting archives that handle installation logic and file deployment. The vulnerability identified in versions 5.2.6 and earlier resides within the core installer component, specifically affecting the UnpackerBase.unpack() method located in the izpack-installer module. This function is responsible for extracting files from a PackFile archive to their designated target locations on the victim's system during the installation process. The security flaw stems from insufficient input validation regarding file paths contained within maliciously crafted installer packages, allowing an attacker to manipulate where these files are written by exploiting path traversal techniques.
The technical root cause of this vulnerability lies in how the UnpackerBase.unpack() method processes the targetPath attribute provided by a PackFile entry. When extracting a file, the code invokes IoHelper.translatePath(), which performs only basic separator normalization, such as converting forward slashes to backslashes on Windows systems. Crucially, this helper function does not resolve or remove parent-directory traversal sequences like ../ nor does it enforce strict containment within the intended installation directory root. Consequently, if an installer package contains a file entry with a target path that includes these relative navigation segments, the resulting File object constructed by the application will point to a location outside the expected sandboxed environment of the installer's working directory. This lack of canonicalization allows the extraction logic to bypass standard containment checks effectively rendering any boundary enforcement meaningless against crafted inputs.
The operational impact of this flaw is severe due to its potential for arbitrary file write attacks with the privileges of the user executing the installer. By carefully constructing a malicious IzPack archive, an attacker can direct files to be written into critical system directories such as startup folders, executable search paths like PATH variables, or other locations where the operating system automatically executes code upon login or process initiation. This capability transforms a standard software installation routine into a vector for persistent malware deployment or privilege escalation. For instance, writing a malicious script or binary to an auto-start location ensures that it runs every time the user logs in, potentially granting the attacker remote access, data exfiltration capabilities, or control over system processes without requiring elevated administrative rights beyond those of the standard user account running the installer.
This vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-78 OS Command Injection if the written files are executed as part of post-install scripts. From an offensive security perspective, this behavior is consistent with ATT&CK technique T1546 Event Triggered Execution, specifically through mechanisms like Startup Items or Environment Modification, where attackers establish persistence by placing executables in directories that trigger automatic execution. The attack vector typically involves distributing a compromised installer via phishing emails, malicious websites, or software update channels, relying on the user's trust to run the application with their current privileges.
Mitigation strategies for this vulnerability primarily involve upgrading IzPack to version 5.2.7 or later where these path handling issues have been addressed by implementing robust canonicalization and containment checks before file operations occur. For organizations unable to immediately upgrade, defensive measures include enforcing strict code signing policies to ensure that only trusted installers are executed and utilizing application control solutions like Windows Defender Application Control or AppLocker to restrict write access to critical system directories such as startup folders and program files from untrusted processes. Additionally, security awareness training should emphasize the risks of running software installations from unknown sources, particularly those involving Java-based packaging tools which may not be subject to standard executable signature verification by default endpoint protection systems.