01 · The Real Story
A decoder that chokes on a malformed frame and hands the attacker the remote control
Android's FrameDecoder, part of the image/animation decode pipeline, copies decoded frame data into a heap buffer without validating its size. A specially crafted animated image or media container can trigger an out-of-bounds write in onOutputReceived of FrameDecoder.cpp, leading to remote code execution with no additional privileges and no user interaction. The flaw affects Android 14, 15, 16, 16 QPR2, and 17, and was fixed in the November 2026 Android Security Bulletin.
No vendor CVSS score was published for this CVE, so this assessment starts from the official description alone. The stated impact—RCE, no privileges, no user interaction—would normally map to a 9.8 Network vector. However, no public exploit exists, EPSS is only 0.211%, and the attack chain requires auto-processing of a malicious media file. Android 14+ sandboxing and media-process hardening constrain the initial blast radius, so the true severity settles at HIGH, not CRITICAL.
"Silent Android media-decoder RCE with zero-click delivery, but no public exploit yet—patch within 30 days."
02 · The Attack Path
5 steps from start to impact.
STEP 01
Craft malformed media file
Attacker constructs a custom animated image or media container (AVIF, HEIF, GIF, WebP, or a video frame) with a crafted frame that causes
FrameDecoder::onOutputReceived to write past the heap buffer during decoding.Conditions required:
- Attacker has reverse-engineered Android 14–17 FrameDecoder parsing path
- No public exploit is required—custom development is feasible for an advanced actor
Where this breaks in practice:
- No public PoC or exploit chain has been indexed as of 2026-11-02
- Heap layout variabilities across SoC vendors and Android builds complicate reliable triggering
Detection/coverage: No existing scanner or signature detects this zero-day media file; content disarm/reconstruction in email gateways may strip some container metadata.
STEP 02
Deliver file to a channel that auto-processes media
Attacker sends the malicious file via MMS, RCS, a messaging app, email attachment, or hosts it on a webpage that Android auto-loads into an image decoding path. The target never needs to click; preview generation or auto-download triggers decoding.
Conditions required:
- Target phone number, email address, or URL reachable
- Channel permits media delivery and the receiving app auto-downloads or displays previews without user action
Where this breaks in practice:
- Carriers or messaging apps may transcode/compress attachments, disrupting the exploit
- Many Android apps disable auto-download for MMS or media by default; battery/data saver can block background fetch
- Enterprise MDM may restrict MMS / RCS or disable personal messaging profiles
Detection/coverage: Email gateway and NGFW content filters may block known-bad extensions, but not unknown heap overflow payloads.
STEP 03
Trigger FrameDecoder on untrusted content
The vulnerable Android framework path invokes FrameDecoder, either inside an app process (e.g., browser or messaging app) or within the media server, to decode the first frame. The malformed frame causes an out-of-bounds write in
onOutputReceived.Conditions required:
- Device runs affected Android version (14, 15, 16, 16 QPR2, or 17)
- The vulnerable decode path is reachable from the delivered content
Where this breaks in practice:
- Not all image/animation formats route through the same FrameDecoder path; media type and app behavior vary
- Modern Android may sandbox media decoding in a separate process with limited privileges
Detection/coverage: No OS-level logging flags the overflow before code execution; crash reports may show mediaserver or app process crashes.
STEP 04
Gain code execution in the decoding process
The heap overwrite corrupts adjacent heap metadata or a function pointer, redirecting execution to attacker-controlled code. This yields remote code execution with no additional privileges beyond the decoding process.
Conditions required:
- Exploit must bypass ASLR, PIE, heap grooming, and stack/heap protections in Android
- Attacker must achieve a controllable heap layout for the target device/SoC
Where this breaks in practice:
- Android hardening (ASLR, PIE, zero-initialization, CFI, heap isolation) has made reliable exploitation significantly harder
- No public exploit has demonstrated successful code execution against current Android versions
Detection/coverage: Mobile threat detection / EDR may catch post-exploitation anomalies, but not the initial memory corruption.
STEP 05
Abuse process-level access and move laterally on device
With code execution in the media/decoding process, the attacker can access microphone, camera, network sockets, or (if the process is an app) app data. They may then attempt to steal OAuth tokens, MFA approvals, or corporate email contents, or chain another vulnerability to escape the sandbox.
Conditions required:
- Vulnerable process has permissions to sensitive data or hardware
- Further privilege escalation is needed for full device compromise or tenant pivot
Where this breaks in practice:
- Android SELinux and app sandboxing limit the compromised process to its UID; root/kernel access is not implied by this CVE
- No privilege escalation is bundled; the CVE only provides code execution in the decoding process
- If the process is media server (UID media), it cannot read app sandbox files directly
Detection/coverage: MDM/UEM can detect known suspicious indicators (e.g., unexpected process spawning, debug flags), but only after compromise.
03 · Compensating Control
1
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCEDApply the November 2026 Android security patch within 30 days — This is the remediation fix; noisgate remediation SLA for HIGH is ≤180 days, but because this is a silent RCE, treat patch deployment as mitigation and complete within 30 days via MDM. Verify every device reports patch level 2026-11-05 or later.
2
HIGH 8.5→MEDIUM 5.5
SEVERITY REDUCEDDisable auto-download/auto-play of media via MDM policies within 30 days — Breaks delivery and trigger steps for MMS/RCS and many messaging apps. Configure MDM to block automatic media download, disable MMS auto-retrieval, and require user action for image loading in enterprise apps. This mitigates until patches land.
3
HIGH 8.5→HIGH 7.5
Deploy mobile threat defense / EDR on all Android devices — Detect post-exploitation anomalies (unexpected process behavior, network connections) after the initial heap overflow. Does not prevent exploitation but reduces dwell time and enables incident response.
4
HIGH 8.5→MEDIUM 4.5
SEVERITY REDUCEDRestrict enterprise data access from unpatched Android devices — Use Conditional Access / zero-trust to block or limit access to O365, Google Workspace, and VPN from devices below patch level 2026-11-05. This limits data egress if exploited.
What doesn't work
- Google Play Protect scanning: does not detect zero-day media-parsing heap overflows before exploit.
- Traditional network firewalls / WAFs: cannot inspect MMS/RCS traffic that bypasses enterprise perimeter.
- Email attachment sandboxing: only protects email vector; MMS/RCS, messaging, and web content still reach the device.
- Antivirus signature updates: without a public PoC, no signatures exist for the malicious file.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No known exploitation; no reports from OffSeq Mirage or GreyNoise; not in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC; no ExploitDB, Metasploit, or nuclei templates indexed as of 2026-11-02. |
| EPSS score | 0.00211 (0.211% probability of exploitation in next 30 days). |
| KEV status | Not listed. |
| CVSS vector | No vendor vector published; description maps to AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H if interpreted as full network RCE. |
| Affected versions | Android 14, 15, 16, 16 QPR2, and 17. |
| Fixed versions | November 2026 Android Security Bulletin; patch level 2026-11-05. |
| Scanning/exposure data | Not internet-exposed as a network service; exposure is every unpatched Android device receiving untrusted media. No Shodan/Censys relevance. |
| Disclosure date | 2026-11-02. |
| Reporting researcher/org | No credited researcher in available sources; coordinated by Google Android Security. |
Sources.
05 · The Call
Final Verdict
= UNCHANGED to HIGH (8.5/10)
Why this verdict
- No vendor baseline: CVE has no CVSS score; this is an initial assessment based on the official description and attack surface.
- Network-adjacent RCE, no UI: The flaw yields code execution in a media/image decoding process on Android 14–17, and remote delivery via MMS, RCS, or auto-loading web content is plausible.
- Role multiplier: On consumer devices the impact is local; on enterprise-managed Android with MFA, O365/Workspace, and corporate email, the same RCE can exfiltrate tokens and app data, and a mass-MMS campaign could hit a fleet. That puts the floor at HIGH.
- Friction holds it below CRITICAL: No public PoC, no in-the-wild exploitation, EPSS 0.211%, and Android's media-process sandbox limits the initial blast radius to one process, not kernel/root.
Why not higher?
Not CRITICAL because no public exploit, in-the-wild activity, or KEV listing exists yet; the initial code execution is confined to the media/decoding process, and Android 14+ hardening makes a reliable mass exploit uncertain. A single device compromise does not guarantee fleet-wide or domain-level impact without additional escalation.
Why not lower?
Not MEDIUM or lower because the official CVE states remote code execution with no additional privileges and no user interaction; Android 14–17 is extremely widely deployed in enterprise fleets, and compromised devices act as MFA and cloud-session endpoints, so a silent RCE cannot be accepted as routine patching.
06 · Verification
Crowdsourced verification payload.
Run this script on a Linux/macOS auditor workstation with Android SDK platform-tools installed. Invoke as bash check_cve-2026-58868.sh; requires adb access to target devices via USB debugging. It checks each connected device's security patch level against the required November 2026 patch.
#!/usr/bin/env bash
# Check Android security patch level for CVE-2026-58868
set -u
REQUIRED="2026-11-05"
devices=$(adb devices | awk 'NR>1 && $2=="device" {print $1}')
if [ -z "$devices" ]; then
echo "UNKNOWN: No devices connected"
exit 2
fi
for dev in $devices; do
patch=$(adb -s "$dev" shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
if [ -z "$patch" ]; then
echo "$dev UNKNOWN"
continue
fi
if [[ "$patch" < "$REQUIRED" ]]; then
echo "$dev VULNERABLE (patch $patch)"
else
echo "$dev PATCHED (patch $patch)"
fi
done