If you've analyzed an Android app in the last few months using one of the security community's most trusted tools, a malicious APK file could have already quietly taken over your machine — and you'd have no idea.
Who's at Risk — and Why It Matters Beyond Security Labs
Apktool is the Swiss Army knife of Android security research. It's used by independent malware analysts, corporate security teams, app store reviewers, academic researchers, bug bounty hunters, and mobile app developers who need to inspect what's actually hiding inside an Android application package (APK). Conservative estimates put active installations in the tens of thousands, concentrated among exactly the people tasked with protecting the rest of us from malicious apps.
That's what makes CVE-2026-39973 particularly dangerous. The people most likely to open an untrusted, potentially malicious APK — because that's literally their job — are the ones most exposed. A single poisoned sample forwarded through a threat-sharing channel, submitted to a research inbox, or uploaded to a public malware repository could compromise the analyst's entire workstation, not just the sandbox they thought they were working in.
What Actually Happens When You Open a Booby-Trapped APK
Think of an APK file like a ZIP archive — a container holding dozens of individual files that describe an Android app: its icons, layouts, code, and a master index called the resource table. When a security researcher runs Apktool to "decode" an APK, they're asking the tool to crack open that container and neatly place all those files into an output folder on their computer. Under normal circumstances, every file stays safely inside that designated folder. The researcher controls where things land.
The vulnerability breaks that containment entirely. An attacker can craft a malicious APK where the resource table — the index that tells Apktool where each file belongs — contains hidden navigation instructions disguised as file path characters. Specifically, sequences like ../../ that mean "go up a level" in any file system directory. When Apktool obediently follows those instructions during decoding, it walks right out of the intended output folder and deposits files wherever the attacker directs: your desktop, your shell startup scripts, your SSH configuration folder, your application plugins directory. The tool writes the files silently, no warning, no prompt, no error message.
The downstream consequences escalate quickly. An attacker who knows their target uses a specific code editor with an auto-loading plugin folder, or runs a particular CI/CD pipeline that picks up files from a known path, can chain this arbitrary file write into full remote code execution. Your next terminal session opens, a startup script runs, and suddenly your credentials, your source code, your corporate VPN access — all of it belongs to someone else. The attack is especially insidious because the researcher's instinct is to trust their own tools, not suspect them.
The Technical Root Cause: One Deleted Safety Check
Security professionals will want to know exactly where this broke. The vulnerability lives in brut/androlib/res/decoder/ResFileDecoder.java and is classified as a path traversal leading to arbitrary file write (CWE-22), carrying a CVSS score of 7.1 (HIGH). The root cause is a security regression — meaning this was a known danger that was previously handled correctly, then accidentally unprotected by a routine code change.
Specifically, commit e10a045 (merged via PR #4041 on December 12, 2025) removed a single function call: BrutIO.sanitizePath(). That function was the gatekeeper responsible for stripping out ../ traversal sequences from resource file output paths before anything was written to disk. Without it, Apktool versions 3.0.0 and 3.0.1 pass attacker-controlled path strings from the resources.arsc Type String Pool directly to the file system. The fix is conceptually simple — restore the sanitization call — but every installation running either affected version remains exposed until patched.
Has This Been Exploited in the Wild?
As of publication, no confirmed active exploitation has been documented. There are no known victim campaigns, no threat actor attribution, and no evidence of weaponized APK samples circulating in malware repositories. That's the good news.
The bad news is the attack surface is highly targetable and the technique is well understood. Path traversal through ZIP-like archive formats has a long, well-documented exploitation history — attackers know how to build these payloads. The security research community's own infrastructure (shared malware samples, public sandboxes, collaborative analysis platforms) creates natural distribution channels for exactly this kind of weaponized file. The window between "vulnerability disclosed" and "someone builds a proof-of-concept" is historically very short for issues this straightforward. Security teams should treat urgency as if exploitation were confirmed.
What You Need to Do Right Now
Three steps, in order of priority:
-
Update Apktool immediately. The patched version is Apktool 3.0.2 or later. If you installed via the official binary, download the latest JAR from the official Apktool GitHub releases page. If you installed through a package manager (Homebrew, apt, etc.), run your standard update command and confirm the resulting version number. Run
apktool --versionto verify. If it says3.0.0or3.0.1, you are not patched. -
Audit any APKs decoded between December 12, 2025 and today. If you ran
apktool don any untrusted APK during the vulnerability window, check your output directories and the directories above them for unexpected files. Pay particular attention to startup script locations (~/.bashrc,~/.zshrc,~/.profile), SSH config folders (~/.ssh/), and any application plugin or extension directories your development environment loads automatically. Unexplained new files in any of these locations should be treated as a potential indicator of compromise. - Isolate your APK analysis environment. Whether or not you were affected this time, this incident is a reminder: untrusted APK analysis should happen in a dedicated virtual machine or container with no shared filesystem mounts to your host. Tools like Docker with explicit volume boundaries, or a dedicated analysis VM snapshot, mean that even a successful path traversal attack lands in a disposable environment rather than on your primary workstation. If your current workflow doesn't include this separation, now is the time to build it.
CVE: CVE-2026-39973 | CVSS: 7.1 HIGH | Affected versions: Apktool 3.0.0, 3.0.1 | Fixed in: Apktool 3.0.2+ | Exploitation status: No confirmed active exploitation