Like issuing a recall for a car that left the junkyard a decade ago
CVE-2015-6609 is a heap-based buffer overflow in Android's libutils library, specifically in UTF-16 to UTF-8 string conversion routines used during audio file processing. The mediaserver process — which runs with elevated privileges including access to audio/video streams and hardware — can be reached remotely via a crafted audio file delivered through MMS, browser playback, or any app that triggers media decoding. Affected versions are Android 5.1.1 before build LMY48X and Android 6.0 before the November 2015 security patch level. This is a cousin of the infamous Stagefright family of media-processing bugs that dominated Android security headlines in 2015.
Google rated this Critical and that was fair — *in November 2015*. The attack surface was real: MMS delivery meant zero-click exploitation was theoretically possible, and mediaserver's privilege level made it a juicy target. But it is now August 2026. Android 6.0 (Marshmallow) hit end-of-life years ago. Google's own distribution dashboard stopped even tracking versions below 5.0 in 2021. The global active share of Android ≤6.0 is estimated at well under 1%, and in managed enterprise fleets it's effectively zero. Any device still running these versions has *hundreds* of other unpatched critical CVEs and should be treated as a hardware decommission problem, not a patching problem.
3 steps from start to impact.
Craft malicious audio file
libutils's utf16_to_utf8 conversion path. This requires knowledge of the specific heap layout of the target Android version's mediaserver process.- Knowledge of Android mediaserver internals for the specific target build
- Ability to craft a valid-enough audio container that reaches the vulnerable parsing code
- No public weaponized PoC exists for this CVE in 2026
- ASLR was present even on Android 5.x, making reliable code execution non-trivial without an info-leak chain
Deliver payload to target device
- Target device must be running Android ≤6.0 (November 2015 patch level)
- Target must receive MMS or visit a URL / install an app that triggers media processing
- Google disabled auto-processing of MMS media in Hangouts and Messenger after the original Stagefright disclosures in mid-2015
- Finding an enterprise-managed Android device on version ≤6.0 in 2026 is essentially impossible; MDM policies universally enforce minimum OS versions well above 6.0
- Carrier MMS infrastructure has been largely supplanted by RCS and OTT messaging
Trigger mediaserver processing
libutils UTF-16→UTF-8 conversion overflows a heap buffer in the mediaserver process. Successful exploitation yields code execution as the media user, which holds privileges to access camera, microphone, audio/video streams, and DRM-protected content.- The audio file must reach the vulnerable code path without being rejected by the media framework's container parser
- Heap layout must be predictable enough to control execution flow
- SELinux (enforcing since Android 5.0) sandboxes mediaserver, limiting post-exploitation lateral movement even if code execution succeeds
- Modern exploit mitigations (stack canaries, ASLR) on even these old Android versions add non-trivial difficulty
The supporting signals.
| In-the-wild exploitation | No known active exploitation. Not listed in CISA KEV. No campaigns attributed to this CVE in any public threat reporting. |
|---|---|
| Proof-of-concept | No public weaponized PoC. The Stagefright family had research PoCs (e.g., Zimperium's work on CVE-2015-1538), but CVE-2015-6609 specifically lacks a published exploit. |
| EPSS score | 0.0217 (approximately 80th percentile) — low predicted exploitation probability. |
| KEV status | Not listed. Never added to CISA's Known Exploited Vulnerabilities catalog. |
| CVSS vector | AV:N/AC:L/Au:N/C:C/I:C/A:C (CVSS v2 = 10.0). No CVSS v3.x vector was assigned by NVD. The v2 score reflects worst-case network-reachable RCE without authentication. |
| Affected versions | Android ≤5.1.1 (before build LMY48X) and Android 6.0 (before 2015-11-01 security patch level). All earlier versions implicitly affected. |
| Fixed versions | Android 5.1.1 LMY48X and later; Android 6.0 with November 2015 security patch level (2015-11-01). AOSP patches in bootable/recovery and system/core. No backports to Android 4.x. |
| Exposure data | Android ≤6.0 active device share is <1% globally as of 2025 (per StatCounter/Google). In enterprise MDM-managed fleets, effectively 0% — MDM policies enforce minimum OS versions of Android 10+. |
| Disclosure date | 2015-11-03 (NVD published). Reported to Google on 2015-08-03 per the Android security bulletin. |
| Researcher / org | Not publicly attributed in the November 2015 bulletin for this specific CVE. Part of the broader Stagefright-era media framework audit wave. |
noisgate verdict.
The single most decisive factor is that the entire affected population — Android ≤6.0 — is extinct in managed enterprise environments, making the reachable attack surface effectively zero. No device running a supported Android version is vulnerable, and any device still on Android 6.0 in 2026 has far larger systemic risk than this individual CVE.
Why this verdict
- Extinct attack surface: Android ≤6.0 represents <1% of global active devices and effectively 0% of enterprise MDM-managed fleets. There is no population to patch.
- Role multiplier: Android mobile endpoints in these versions occupy no high-value infrastructure role (not a DC, hypervisor, CI/CD, or identity provider). Even in the worst case — a compromised personal phone — the blast radius is limited to one user's on-device data, not fleet-scale or domain-scale impact. The floor does not apply.
- No exploitation evidence in 11 years: Despite being publicly known since November 2015 with a CVSS v2 of 10.0, this CVE has never appeared in CISA KEV, has no attributed campaigns, and has no public weaponized exploit code. The theoretical severity never materialized.
- Defense-in-depth already present: Even on vulnerable Android versions, SELinux enforcement, ASLR, and post-Stagefright MMS auto-processing mitigations reduced practical exploitability significantly at the time of disclosure.
Why not higher?
To warrant LOW or above, there would need to be a meaningful population of affected devices in the defender's fleet or evidence of active exploitation interest. Neither exists. Android ≤6.0 devices fail basic MDM compliance checks and should not be on any enterprise network. The CVE is a historical artifact, not an actionable finding.
Why not lower?
IGNORE is already the lowest severity bucket. The only reason it scores 1.0 rather than 0.0 is the theoretical possibility that an unmanaged BYOD device running Android 6.0 could exist in a fringe scenario — but even this does not rise to the level of warranting any patching action.
What to do — in priority order.
- Enforce MDM minimum OS version policy of Android 10+ — Any device running Android ≤6.0 is vulnerable to hundreds of critical CVEs, not just this one. MDM enrollment policies should block or quarantine devices below Android 10. This eliminates the entire attack surface for CVE-2015-6609 and its class.
- Block MMS auto-download on any legacy devices — If for some reason legacy Android devices exist in your environment, ensure MMS auto-download is disabled. This was the primary zero-click vector for Stagefright-class bugs.
- Patching the CVE itself — Google stopped providing security updates for Android 6.0 years ago. There is no vendor patch pipeline. The device must be replaced, not patched.
- Network segmentation for legacy Android devices — while it limits blast radius, it doesn't address the fundamental problem that the device is running a completely unsupported OS with hundreds of other unpatched vulns.
Crowdsourced verification payload.
Run this on your MDM server or any workstation with adb access to check a connected Android device. Invoke with: bash check_cve_2015_6609.sh. Requires adb in PATH and a USB-connected or network-connected Android device with USB debugging enabled.
#!/usr/bin/env bash
# check_cve_2015_6609.sh
# Checks if a connected Android device is vulnerable to CVE-2015-6609
# Requires: adb in PATH, connected Android device with USB debugging
set -euo pipefail
if ! command -v adb &>/dev/null; then
echo "ERROR: adb not found in PATH"
exit 2
fi
# Get Android API level and security patch level
API_LEVEL=$(adb shell getprop ro.build.version.sdk 2>/dev/null | tr -d '\r')
SEC_PATCH=$(adb shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
ANDROID_VER=$(adb shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')
if [ -z "$API_LEVEL" ]; then
echo "UNKNOWN - Could not connect to device or read properties"
exit 2
fi
echo "Android version: $ANDROID_VER (API $API_LEVEL)"
echo "Security patch level: ${SEC_PATCH:-not set}"
# API level 23 = Android 6.0, API 22 = Android 5.1
# Vulnerable: Android <= 6.0 before 2015-11-01 patch level
if [ "$API_LEVEL" -gt 23 ]; then
echo "PATCHED - Android version $ANDROID_VER (API $API_LEVEL) is above affected range"
exit 0
fi
if [ "$API_LEVEL" -eq 23 ] && [ -n "$SEC_PATCH" ]; then
# Compare security patch date - need 2015-11-01 or later
if [[ "$SEC_PATCH" > "2015-10-31" ]] || [[ "$SEC_PATCH" == "2015-11-01" ]]; then
echo "PATCHED - Security patch level $SEC_PATCH includes fix for CVE-2015-6609"
exit 0
fi
fi
echo "VULNERABLE - Android $ANDROID_VER (API $API_LEVEL) with security patch $SEC_PATCH is in the affected range for CVE-2015-6609"
echo "RECOMMENDATION: This device is running an end-of-life Android version. Replace the hardware."
exit 1If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.