CVE-2026-39973: Arbitrary File Write via Path Traversal in Apktool

Apktool is an industry-standard utility used by security researchers and developers to reverse engineer Android applications. The tool decodes binary APK files into human-readable project directories for analysis. CVE-2026-39973 is a path traversal vulnerability identified as CWE-22 that affects Apktool versions 3.0.0 and 3.0.1. The flaw triggers specifically during the apktool d decoding phase when the application processes the resources.arsc file.

The vulnerability originates from a security regression introduced during a major codebase refactor in December 2025. Developers inadvertently removed critical path sanitization functions that previously protected the file extraction logic. This removal exposed the application to directory traversal attacks via maliciously crafted resource type names.

By leveraging this vulnerability, an attacker can escape the intended output directory during the decoding process. The vulnerability enables arbitrary file writes on the host system executing the tool. This condition escalates to unauthenticated remote code execution, granting the attacker the privileges of the user running Apktool.

During the APK extraction process, Apktool parses the resources.arsc binary file to reconstruct the original resource directory structure. This structure relies heavily on the Type String Pool, an internal mapping that defines names for standard Android resource categories. Legitimate categories include types such as drawable, layout, or string.

In affected versions, the application reads the typeName from the string pool and concatenates it directly to the base project output directory string. Prior to the vulnerability introduction, Apktool mitigated path traversal by routing this concatenated string through BrutIO.sanitizePath() and BrutIO.detectPossibleDirectoryTraversal(). These functions validated the resulting path against the sandbox boundaries.

Commit e10a0450c7afcd9462c0b76bcbff0e7428b92bdd unintentionally removed these security checks from the ResFileDecoder.java component. The application consequently trusts the attacker-controlled typeName entirely. The unvalidated path is passed directly to file-writing sinks without any normalization checks.

The resulting extraction path follows the format [typeName][qualifiers]/[name].[ext]. If an attacker supplies a sequence such as ../../../../.ssh/ as the typeName, the system evaluates the relative path from the working directory. The File object resolves this relative sequence to a location completely outside the intended project sandbox.

The vulnerability resides within the path construction logic of the resource file decoder. Without sanitization wrappers, the variables extracted from the parsed ARSC file flow directly into the File object initialization. The code snippet below demonstrates the vulnerable state prior to the patch.

// Vulnerable path construction in ResFileDecoder.java
String outResPath = entry.getTypeName() + entry.getConfig().getQualifiers() + "/" + entry.getName();
outResPath += "." + ext;
// File object created without BrutIO.sanitizePath()
File outFile = new File(outDir, outResPath);

The remediation in version 3.0.2 applies a strict defense-in-depth approach. Commit 65dd8480dfcb63068562ffaa527f71bb0a9f772c implements resource type whitelisting within ResTypeSpec.java. The application now verifies that the extracted typeName matches a hardcoded list of legitimate Android resource categories.

// Whitelisting fix in ResTypeSpec.java
public static final Set<String> ALLOWED_TYPES = new HashSet<>(Arrays.asList(
    "anim", "animator", "color", "drawable", "layout", "menu", "raw", "string", "xml"
));
 
public ResTypeSpec(...) {
    if (!ALLOWED_TYPES.contains(name)) {
        this.name = String.format("invalid%02X", id);
    } else {
        this.name = name;
    }
}

In addition to the whitelist, the developers reinstated the BrutIO.sanitizePath() wrapper in the file-writing sinks. This ensures that even if an attacker bypasses the ResTypeSpec validation, the resulting path undergoes strict boundary normalization before the system opens a file handle.

Exploitation requires the attacker to manipulate the binary structure of an Android APK. The attacker targets the resources.arsc file, specifically focusing on the entries stored within the Type String Pool. This file dictates how the Android OS, and subsequently Apktool, structures the application resources.

Using a hex editor or a custom resource compiler, the attacker overwrites a legitimate resource type name with a directory traversal payload. A payload such as ../../../../.ssh/ replaces a standard type entry like drawable. The attacker then distributes this modified APK to the target researcher or automated analysis sandbox.

The attack sequence initiates when the victim executes apktool d malicious.apk in their terminal environment. The application parses the manipulated resources.arsc file and extracts the traversal sequence. It formulates the output path using the injected directory traversal characters.

As the decoding process writes the extracted resource contents to disk, it places the file at the attacker-specified location. The attacker controls both the destination path via the string pool and the file contents via the corresponding resource data block. This grants a precise, arbitrary file write primitive on the host filesystem.

Successful exploitation results in arbitrary file writes on the host system running Apktool. This capability directly translates to unauthenticated remote code execution. The code executes under the privileges of the user running the Apktool process, which is typically a developer or security analyst.

An attacker can overwrite sensitive configuration files to gain persistence or execute commands upon the next shell initialization. Common targets include ~/.ssh/config for connection hijacking and ~/.ssh/authorized_keys for direct SSH access. Attackers frequently target shell profiles such as ~/.bashrc and ~/.zshrc to achieve silent code execution.

The vulnerability carries a CVSS v3.1 base score of 7.1, categorizing it as high severity. This score reflects the severe integrity and confidentiality impact combined with the requirement for user interaction. The attack vector is classified as local because the user must explicitly execute the tool against the malicious file.

The Exploit Prediction Scoring System (EPSS) score remains exceptionally low at 0.00014, placing it in the 2.78th percentile. This low score reflects the highly targeted nature of the attack. It is designed to compromise reverse engineers rather than serve as a vector for broad, automated internet scanning.

Organizations and individual users must upgrade Apktool to version 3.0.2 or later to remediate the vulnerability entirely. Administrators can verify the currently installed version by executing apktool -version in their terminal environment. Package managers should be updated to pull the latest signed binary from the official repository.

If immediate patching is not feasible, users must isolate the execution environment. Security engineers should execute Apktool strictly within a dedicated virtual machine or an ephemeral container. This architectural containment restricts the blast radius of a successful arbitrary file write, preventing compromise of the primary host machine.

Detection teams can monitor endpoint file systems for unexpected writes to sensitive directories during Apktool execution. File Integrity Monitoring (FIM) solutions should flag unauthorized modifications to /etc/ or user home configuration directories. Processes spawned by the Java runtime executing Apktool should not possess write access outside of designated temporary directories.