CVE-2026-54684: jadx Dex to Java Decompiler RCE Flaw

CVE-2026-54684 Overview

CVE-2026-54684 is a path traversal vulnerability [CWE-22] in jadx, a Dex-to-Java decompiler. Versions 1.5.2 through 1.5.5 fail to validate archive entry names inside malicious .xapk files. The XApkLoader component resolves each entry with tmpDir.resolve(fileName) after a current-working-directory ZIP security check that can be bypassed. An attacker who convinces a user to open a crafted XAPK can write arbitrary files, including a JAR planted into plugins/dropins. The next jadx execution loads that JAR via URLClassLoader and ServiceLoader, executing attacker-controlled plugin code. The issue is fixed in version 1.5.6.

Critical Impact
A single malicious .xapk file can achieve persistent code execution in the user's jadx context on subsequent launches.

Affected Products

jadx 1.5.2
jadx 1.5.3, 1.5.4, 1.5.5
jadx XAPK plugin (XApkLoader) prior to 1.5.6

Discovery Timeline

2026-07-14 - CVE CVE-2026-54684 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-54684

Vulnerability Analysis

The flaw lives in the XAPK plugin loader. When jadx unpacks a .xapk archive, XApkLoader iterates over ZIP entries and writes each to a temporary directory using tmpDir.resolve(fileName). Before the write, JadxZipSecurity performs a traversal check by resolving the entry against the current working directory (CWD). An attacker-supplied absolute path or a name already prefixed with the CWD passes this check, because CWD.resolve(absolute) returns the absolute path unchanged and startsWith(CWD) evaluates true.

The result is a classic Zip Slip variant: entries escape tmpDir and land at attacker-chosen filesystem locations. When jadx is started from a directory that is an ancestor of the jadx config directory, the write can target plugins/dropins. On the next jadx launch, URLClassLoader loads the dropped JAR and ServiceLoader instantiates its plugin services, executing arbitrary Java code with the user's privileges.

Root Cause

The root cause is trusting a ZIP entry name to be relative before resolving it against the destination directory. The pre-patch check used CWD.resolve(entryName) without first rejecting absolute paths or names that already contain the CWD, so the traversal filter could be bypassed with a crafted fileName.

Attack Vector

Exploitation requires local user interaction: the victim must open a malicious .xapk in jadx from a working directory that is an ancestor of the jadx config directory. No authentication is required. Once the JAR is planted, the next jadx invocation triggers code execution automatically through the plugin service loader.

java

// Path traversal check as presented on
// https://www.heise.de/en/background/Secure-Coding-Best-practices-for-using-Java-NIO-against-path-traversal-9996787.html
try {
-    Path entryPath = CWD.resolve(entryName).normalize();
+    Path entryPathPart = Paths.get(entryName).normalize();
+    if (entryPathPart.startsWith(CWD) || entryPathPart.isAbsolute()) {
+        // reject entry name if it is already a full path to CWD, otherwise next check will always pass
+        // reject absolute path as well
+        LOG.error("Path traversal attack detected (absolute path) in entry: {}", entryName);
+        return false;
+    }
+    Path entryPath = CWD.resolve(entryPathPart).normalize();
    if (entryPath.startsWith(CWD)) {
        return true;
    }

Source: jadx commit a74bb07. The patch rejects absolute entry names and any name already rooted at the CWD before performing the containment check.

Detection Methods for CVE-2026-54684

Indicators of Compromise

Unexpected .jar files appearing in the jadx plugins/dropins directory shortly after opening an .xapk file.
ZIP entries within .xapk archives that contain absolute paths or .. sequences when inspected with unzip -l.
New Java classes loaded by jadx that were not part of the shipped distribution.

Detection Strategies

Statically scan untrusted .xapk samples for entry names beginning with /, a drive letter, or containing .. before allowing analysts to open them.
Monitor file writes by the jadx process outside its designated temp unpack directory using endpoint file integrity monitoring.
Alert on java / jadx processes writing to user-profile plugin directories such as ~/.jadx/plugins/dropins or %APPDATA%\jadx\plugins\dropins.

Monitoring Recommendations

Log jadx version strings from analyst workstations and flag hosts still running 1.5.2 through 1.5.5.
Capture process-creation telemetry for jadx and jadx-gui and correlate child process spawns against baseline behavior.
Track load events of unsigned JARs via URLClassLoader in Java runtime audit logs where available.

How to Mitigate CVE-2026-54684

Immediate Actions Required

Upgrade jadx to version 1.5.6 or later on every analyst workstation and CI reverse-engineering pipeline.
Do not open .xapk samples from untrusted sources in vulnerable jadx builds.
Audit the jadx config directory, especially plugins/dropins, and remove any JAR files not intentionally installed.

Patch Information

The fix is available in jadx release v1.5.6. See the GitHub Security Advisory GHSA-gpvc-ccw7-744v for full details and the code change in commit a74bb07, which rejects absolute paths and CWD-rooted entry names in JadxZipSecurity.

Workarounds

Launch jadx from a working directory that is not an ancestor of the jadx config directory, which prevents planted files from reaching plugins/dropins.
Run jadx inside a container or disposable sandbox when analyzing untrusted .xapk archives.
Remove or make read-only the plugins/dropins directory to block automatic loading of dropped JARs.

bash

# Verify installed jadx version and upgrade
jadx --version

# Linux/macOS: remove untrusted dropins and lock the directory
rm -f ~/.jadx/plugins/dropins/*.jar
chmod 555 ~/.jadx/plugins/dropins

# Run jadx from a neutral directory when handling untrusted samples
cd /tmp/jadx-sandbox && jadx suspicious.xapk