CVE-2026-54684 in jadx
Summary
by MITRE • 07/15/2026
jadx is a Dex to Java decompiler. From 1.5.2 to 1.5.5, a malicious .xapk file can cause jadx to write attacker-controlled archive entry contents outside the intended XAPK plugin temporary unpack directory because XApkLoader resolves each entry name directly with tmpDir.resolve(fileName) after a CWD-based ZIP security check. When jadx is launched from a directory that is an ancestor of the config directory, the arbitrary write can plant a JAR in plugins/dropins, and the next jadx run loads the JAR with URLClassLoader and ServiceLoader, executing attacker-controlled plugin code. This issue is fixed in version 1.5.6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/15/2026
The vulnerability exists within jadx version 1.5.2 through 1.5.5 where a specially crafted .xapk file can lead to arbitrary file writing outside the intended temporary directory during extraction. This flaw stems from how XApkLoader processes archive entries by directly resolving each file name against the temporary directory using tmpDir.resolve(fileName) without proper validation of the resolved path. The security check performed earlier in the process only validates against the current working directory but does not prevent path traversal attacks that could occur when the application is launched from a directory that is an ancestor of the intended configuration directory.
The technical implementation of this vulnerability allows attackers to exploit the lack of proper path validation during XAPK plugin extraction. When jadx processes an attacker-controlled .xapk file, the resolver function tmpDir.resolve(fileName) creates absolute paths that may escape the designated temporary directory boundaries. This occurs because the CWD-based security check only validates against the current working directory but fails to account for potential path traversal scenarios where the application's launch directory might contain symbolic links or parent directory references that could lead to unintended file placement.
The operational impact of this vulnerability is significant as it enables privilege escalation through arbitrary code execution. When jadx is launched from a directory that serves as an ancestor to the config directory, the malicious extraction process can place a JAR file directly into the plugins/dropins directory. This strategic placement allows subsequent jadx executions to load the attacker-controlled JAR using URLClassLoader and ServiceLoader mechanisms, effectively executing arbitrary code with the privileges of the user running jadx. The vulnerability essentially transforms a simple decompilation tool into a potential attack vector for persistent code execution within the target environment.
This vulnerability aligns with CWE-22 Path Traversal and CWE-434 Unrestricted Upload of File with Dangerous Type, representing a combination of directory traversal and insecure file handling practices. From an ATT&CK perspective, this issue maps to T1059 Command and Scripting Interpreter and T1505 Server Software Component, as it enables attackers to execute malicious code through compromised software components. The attack chain demonstrates how a seemingly benign file processing operation can be weaponized to achieve persistent execution within the target system. The fix implemented in version 1.5.6 addresses this by introducing proper path validation that ensures all resolved paths remain within the intended temporary directory boundaries, preventing any potential path traversal attacks during XAPK plugin extraction processes.
The security implications extend beyond immediate code execution as this vulnerability could enable attackers to establish persistence mechanisms within environments where jadx is frequently used for application analysis. The fact that the attack requires only a single malicious .xapk file and leverages legitimate application functionality makes it particularly dangerous for automated exploitation scenarios. Organizations using jadx in development or reverse engineering workflows should consider this vulnerability as a potential entry point for more sophisticated attacks, especially when dealing with untrusted input files from external sources or unknown developers.