Which versions of jadx are affected by EUVD-2026-44534?

jadx versions prior to 1.5.6 enable remote code execution on security analyst workstations through malicious Android applications, posing direct risk to organizations' threat intelligence teams.. A patch is available.

How to fix or mitigate EUVD-2026-44534?

Within 24 hours, create an inventory of all jadx installations across security and development teams, then notify users of the vulnerability and establish a temporary policy requiring APK analysis only in isolated environments. Within 7 days, distribute and install jadx 1.5.6 on all affected systems, validate the upgrade by testing decompilation of reference APKs, and audit configuration management to prevent reversion to older versions. Within 30 days, confirm 100% deployment completion, review and re-analyze any APKs processed with vulnerable versions to identify potential compromise of internal systems, and implement automated version enforcement mechanisms to maintain patched status going forward.

jadx EUVD-2026-44534

Q: What is the CVSS score of EUVD-2026-44534?

EUVD-2026-44534 has a CVSS 4.0 base score of 8.4 (High). CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-42049 HIGH

Code Injection (CWE-94)

2026-07-14 security-advisories@github.com

RCE Java Google Code Injection

8.4

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.4 HIGH

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.8 HIGH

Attacker supplies a local malicious APK (AV:L) and the analyst must open/build the exported project (UI:R); no privileges needed (PR:N), and injected Groovy yields full C/I/A compromise of the analyst host.

3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 22, 2026 - 12:03 vuln.today

Analysis Generated

Jul 22, 2026 - 12:03 vuln.today

Patch available

Jul 14, 2026 - 23:20 EUVD

CVE Published

Jul 14, 2026 - 22:16 cve.org

HIGH 8.4

DescriptionCVE.org

jadx is a Dex to Java decompiler. Prior to 1.5.6, jadx inserts the android:versionName value from an AndroidManifest into the generated app/build.gradle Groovy template without proper sanitization when exporting a decompiled APK as an Android Gradle project. A malicious APK can break out of the string context so that opening or building the exported Gradle project executes attacker-controlled Groovy code on the victim machine. This issue is fixed in version 1.5.6.

Articles & Coverage 1

News 5 New Java Vulnerabilities - 1 Critical, 4 High, 1 With POC Jul 15, 2026

AnalysisAI

Arbitrary Groovy code execution in the jadx Dex-to-Java decompiler (prior to 1.5.6) allows a malicious APK to run attacker-controlled code on the analyst's machine. When jadx exports a decompiled APK as an Android Gradle project, it copies the android:versionName value from AndroidManifest.xml into the generated build.gradle Groovy template without sanitization, letting a crafted value break out of the string literal and inject code that executes when the victim opens or builds the exported project. No public exploit identified at time of analysis; EPSS risk is low (0.15%, 5th percentile) and CISA SSVC records exploitation as none, but the technical impact is total.

Technical ContextAI

The affected technology is jadx, an open-source Android reverse-engineering tool that decompiles Dalvik bytecode (DEX) to Java and can export a project scaffold for the Android Gradle build system. The root cause is CWE-94 (Improper Control of Generation of Code / Code Injection): jadx's TemplateFile/AndroidGradleGenerator machinery substituted the attacker-controlled android:versionName manifest attribute directly into a Groovy build.gradle template. Because Gradle build scripts are executable Groovy, any value that terminates the surrounding string literal is interpreted as live code rather than data. The upstream fix (commit 5a6e660) introduces a SANITIZE_STRINGS security flag, a SanitizeType enum (GRADLE_GROOVY / GRADLE_KOTLIN), and a sanitizeGradle routine that strips dangerous characters (;'"${}/:>?*|[]\) from template variables unless a caller explicitly opts out with a '!!' raw-value marker.

RemediationAI

Vendor-released patch: jadx 1.5.6 - upgrade to 1.5.6 or later, which adds Groovy/Kotlin string sanitization for Gradle template values (commit 5a6e660b4663d998d52c7dc4511299f3368ef611; release https://github.com/skylot/jadx/releases/tag/v1.5.6; advisory https://github.com/skylot/jadx/security/advisories/GHSA-w6f5-h4x4-rfpj). Note that the same commit adds a JADX_DISABLE_ALL_SECURITY_FLAGS environment variable that turns off these protections, so ensure it is NOT set to 'true' in analyst environments. Until you can upgrade, the concrete compensating controls are: avoid using the "export as Android Gradle project" feature on untrusted APKs (trade-off: loses the Gradle scaffold convenience); if you must export, inspect the generated build.gradle for suspicious versionName content before opening it in an IDE or running any Gradle task (trade-off: manual and error-prone); and never open/import an exported project into an IDE that auto-runs Gradle sync on untrusted samples. Detonate untrusted APK analysis inside an isolated, disposable VM/sandbox so any code execution is contained (trade-off: added workflow overhead).