CVE-2026-54550: 
Java Analyse et atténuation des vulnérabilités

CVE-2026-54550 is a path traversal vulnerability in IzPack, a widely used Java-based cross-platform installer packaging tool. The flaw exists in UnpackerBase.unpack() within izpack-installer, where attacker-controlled PackFile target paths containing ../ sequences are not normalized or validated for directory containment, allowing files to be written outside the intended installation directory. All versions up to and including 5.2.6 of the Maven package org.codehaus.izpack:izpack-installer are affected, with no patched release currently available. The vulnerability was originally identified and reported by Michał Majchrowicz, Marcin Wyczechowski, and Paweł Zdunek of the AFINE Team, first published to the GitHub Advisory Database on July 17, 2026, and updated on August 26, 2026. It carries a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory, Feedly).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — Path Traversal). In UnpackerBase.unpack(), the targetPath is retrieved from an attacker-controlled PackFile object and passed through IoHelper.translatePath(), which performs only file-separator character conversion (/ ↔ File.separatorChar) with no security validation, canonical path resolution, or startsWith(installDir) containment check. The resulting File object is constructed directly from this unsanitized path, allowing ../ sequences to resolve to arbitrary locations on disk. Because IzPack installer JARs are standard ZIP archives with no digital signature or integrity protection, an attacker can repack any legitimate installer with malicious PackFile entries embedding traversal sequences. A public proof-of-concept reproducer is included in the advisory, demonstrating file writes outside the installation directory using a standalone Java class that replicates the vulnerable code path (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker to write arbitrary files to any location accessible under the victim's privileges at the time the installer is executed. On Windows, where installers are commonly run as a local administrator, this includes sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup, %SystemRoot%\System32, or other PATH directories — enabling persistence or privilege escalation. On Linux and macOS, user-writable locations such as shell startup scripts or ~/.local/bin can be targeted. The vulnerability has no confidentiality or availability impact but poses a high integrity risk with a changed scope, as the affected component (the installer) can impact resources beyond its own security boundary (GitHub Advisory).

A proof-of-concept is publicly available as part of the security advisory, demonstrating the vulnerability with a standalone Java reproducer (GitHub Advisory). The NVD SSVC assessment classifies exploitation status as "poc" and notes the attack is not automatable, requiring user interaction (a victim must run the trojanized installer). The EPSS score is 0.0, indicating low current probability of widespread exploitation. No in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly).

1. Obtain a legitimate IzPack-generated installer: Identify a target application distributed as an IzPack installer JAR (e.g., from a software vendor's download page).
2. Unpack the installer JAR: Since IzPack installers are standard ZIP archives, extract the contents using any ZIP tool: unzip target-installer.jar -d installer_contents/.
3. Craft a malicious PackFile entry: Modify or inject a serialized PackFile resource within the extracted archive so that its targetPath field contains a path traversal sequence, e.g., <installDir>/../../../AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/malware.exe on Windows or ../../.bashrc on Linux.
4. Repack the installer: Reassemble the modified contents back into a JAR/ZIP: zip -r malicious-installer.jar installer_contents/. No code signing is required as IzPack does not enforce installer integrity.
5. Distribute the trojanized installer: Deliver the malicious installer to the victim via social engineering (e.g., phishing email, fake software download site, or supply chain substitution).
6. Victim executes the installer: When the victim runs the installer, UnpackerBase.unpack() processes the malicious PackFile entry, calls IoHelper.translatePath() (separator swap only), constructs a File object without normalization, and writes the attacker-controlled payload to the traversal target path under the victim's privileges.
7. Achieve persistence or code execution: The written file (e.g., a startup script or executable) executes on next login or system event, granting the attacker persistent access (GitHub Advisory).

• File System: Unexpected files appearing in startup folders (e.g., %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ on Windows, ~/.config/autostart/ on Linux) shortly after running an IzPack installer; files written to %SystemRoot%\System32 or PATH directories by a Java process; files with names inconsistent with the installed application in system directories.
• Process: Java process (java.exe or java) spawning child processes or writing files outside the declared installation directory during installer execution; mkdirs() calls creating unexpected directory structures outside the install path.
• Logs: Installer log files (if generated) showing file write operations to paths containing .. segments or resolving outside the installation directory; OS audit logs (e.g., Windows Security Event Log, Linux auditd) recording file creation events by the Java installer process in sensitive system locations.
• Network: Outbound connections from the installer process to unexpected remote hosts (if the dropped payload includes a network component), particularly during or immediately after installer execution (GitHub Advisory).

As of the advisory publication date (August 26, 2026), no patched release of org.codehaus.izpack:izpack-installer is available for versions ≤ 5.2.6. A fix has been merged into the 5.2 branch via pull request #1193 (commits 4233ba3 and 8b7c679), which adds validateTargetPath() checks at both compile time and installation time to reject paths containing .. segments (Fix PR, Fix Commit). Until a patched release is published, organizations should: (1) avoid running IzPack installers obtained from untrusted or unverified sources; (2) run installers in sandboxed or low-privilege environments where possible; (3) monitor file system activity during installer execution using endpoint detection tools; and (4) track the IzPack GitHub repository for a patched release (GitHub Advisory).

The vulnerability was discovered and responsibly disclosed by Michał Majchrowicz, Marcin Wyczechowski, and Paweł Zdunek of the AFINE Team. The IzPack maintainer (reinhapa) promptly merged a fix into the 5.2 branch on July 17, 2026, the same day the advisory was first published, with the fix reviewed and approved by contributor akuhtz (Fix PR). No significant broader media coverage or notable social media commentary has been identified beyond the GitHub advisory and standard vulnerability database entries.