A high-severity path traversal vulnerability (CVE-2026-39973) has been disclosed in Apktool versions 3.0.0 and 3.0.1, allowing attackers to write arbitrary files to any location on the host filesystem during a standard APK decode operation, potentially escalating to remote code execution (RCE). Users are urged to update to version 3.0.2 immediately.
A critical security regression in Apktool 3.0.1. The vulnerability, tracked as CVE-2026-39973, is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and carries a CVSS v3.1 score of High severity with a vector string of CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N.
Apktool 3.0.1 Path Traversal Flaw
The flaw resides in brut/androlib/res/decoder/ResFileDecoder.java, the core component responsible for decoding resource files from APK packages during the apktool d (decode) command.
Apktool is one of the most widely used open-source tools for reverse engineering Android APK (Android Package Kit) files, relied upon by security researchers, mobile app developers, and penetration testers worldwide.
It enables users to decode APK resources into near-original form and rebuild them after modification. Because it is heavily integrated into automated pipelines, including Mobile Security Frameworks (MobSF) and CI/CD reverse-engineering workflows, any vulnerability in Apktool carries a disproportionately large attack surface.
The Security Regression
This vulnerability is explicitly a security regression, not a newly introduced design flaw. On December 12, 2025, commit e10a045 (merged via PR #4041) Inadvertently removed the critical BrutIO.sanitizePath() call from ResFileDecoder.java.
This function had previously served as a sanitization guard, ensuring that output file paths derived from resource names were confined strictly within the designated output directory.
When the call was removed, Apktool lost its ability to neutralize ../ (dot-dot-slash) sequences embedded within the resources.arsc Type String Pool of a crafted APK file.
The affected versions are Apktool 3.0.0 and 3.0.1. The patched version is 3.0.2, which reintroduces BrutIO.sanitizePath() before all file write operations in ResFileDecoder.java.
The attack chain is straightforward and requires minimal attacker skill:
- Step 1 — Craft a Malicious APK: An attacker embeds
../traversal sequences inside the resources.arsc Type String Pool specifically in the resource name entries that Apktool uses to determine output file paths. - Step 2 — Distribute the APK: The attacker distributes the malicious APK to a target, who is a developer, security researcher, or automated system operator who routinely processes APKs with Apktool.
- Step 3 — Trigger the Decode: When the victim runs
apktool d malicious.apk, the tool processes the resource names without path sanitization and constructs file write paths using the attacker-controlled strings. - Step 4 — Arbitrary File Write: Files are written to attacker-specified locations outside the intended output directory, including
~/.ssh/config,~/.bashrc,~/.profile, or Windows Startup folders. - Step 5 — Escalate to RCE: By overwriting shell initialization files or injecting into SSH authorized keys, an attacker achieves persistent Remote Code Execution on the victim’s machine.
This is structurally identical to the earlier CVE-2024-21633 (affecting Apktool ≤ 2.9.1), which also exploited unsanitized resource names to perform arbitrary file writes.
The recurrence of this vulnerability class underlines the systemic risk of removing sanitization controls during code refactoring.
| Metric | Value |
|---|---|
| Attack Vector | Local |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | Required |
| Confidentiality Impact | High |
| Integrity Impact | High |
| Availability Impact | None |
| Severity | High |
The “User Interaction: Required” metric indicates that a victim must run apktool d on the malicious APK, which is a routine, everyday action for Apktool’s core user base, making real-world exploitation highly plausible.
Affected Versions and Patch Details
According to the GitHub Advisory, the following versions are affected:
- Apktool 3.0.0 — Vulnerable
- Apktool 3.0.1 — Vulnerable (regression introduced here)
- Apktool 3.0.2 — Patched
The fix, developed by remediation contributor IgorEisberg, reintroduces the BrutIO.sanitizePath() validation call ResFileDecoder.java before any filesystem write operation. The original reporter of the vulnerability was caveeroo.
Any individual or organization running apktool d on untrusted or third-party APK files on Apktool versions 3.0.0 or 3.0.1 is at risk. This includes:
- Mobile application security researchers analyzing malware or third-party apps
- Bug bounty hunters processing APKs from unknown sources
- Automated security testing pipelines using MobSF or similar frameworks with Apktool as a backend engine
- Android developers decompiling competitor or legacy apps for analysis
Organizations running Apktool in CI/CD pipelines without strict sandboxing are at particularly elevated risk, as automated processing removes the human vigilance that might otherwise catch suspicious outputs.
Mitigation
- Upgrade to Apktool 3.0.2 immediately via Maven (
org.apktool:apktool-lib:3.0.2) or the official GitHub Releases page. - If an immediate upgrade is not possible, run Apktool inside an isolated container or sandbox (e.g., Docker with read-only mounts to sensitive directories).
- Restrict write access to critical directories such as
~/.ssh/,~/.bashrc, and system startup folders before processing any untrusted APKs. - Audit any APK processed with Apktool 3.0.0 or 3.0.1 for unexpected file modifications in user home directories or outside the designated output folder.
FAQ
Q1: What is CVE-2026-39973?
CVE-2026-39973 is a high-severity path traversal vulnerability in Apktool 3.0.0 and 3.0.1 that allows a malicious APK to write arbitrary files anywhere on the host filesystem during decoding, potentially enabling RCE.
Q2: Which versions of Apktool are affected, and what is the fix?
Apktool versions 3.0.0 and 3.0.1 are affected; upgrading to version 3.0.2, which reintroduces the BrutIO.sanitizePath() guard in ResFileDecoder.java, fully remediates the vulnerability.
Q3: How does this path traversal attack escalate to Remote Code Execution (RCE)?
By embedding ../ sequences in the resources.arsc Type String Pool, an attacker can overwrite files like ~/.bashrc, ~/.ssh/config, or Windows Startup folders, causing malicious code to execute the next time the victim logs in or boots their system.
Q4: Is this the first path traversal vulnerability in Apktool?
No, a similar flaw, CVE-2024-21633, affected Apktool versions ≤ 2.9.1 with an identical arbitrary file write mechanism via unsanitized resource names, making CVE-2026-39973 a security regression of a previously patched vulnerability class.
Site: http://thecybrdef.com