This is a sharp shard in one phone’s video engine, not a skeleton key for the whole internet
CVE-2026-0116 is an out-of-bounds write in __mfc_handle_released_buf inside the Exynos/Tensor MFC media driver path. The public fix shows the bug is a missing guard around dec->refcnt before writing into dec->ref_buf[...], which means malformed buffer-release state can push writes past the intended array bounds. Google published it on 2026-03-10; the Pixel bulletin places it in the MFC subcomponent and says security patch level 2026-03-05 or later addresses it on supported Pixel devices.
The vendor-style 9.8/AV:N/UI:N story overstates enterprise reality. This is not an internet-facing daemon you can mass-scan and pop from anywhere; it is a device-side media-driver bug in a specific hardware codec path, on a narrower population than 'all Android'. That said, because it sits below the app sandbox and could plausibly be driven by crafted media on affected phones, it still deserves a HIGH bucket rather than a casual backlog entry.
4 steps from start to impact.
Land crafted media on the device
- Target is an affected Pixel/Android build with the vulnerable MFC driver
- Attacker can deliver media to an app or service path that invokes hardware codec handling
- The receiving app does not fully neutralize the payload before the kernel driver sees it
- Population is limited to devices carrying this MFC implementation, not generic servers or desktops
- Modern apps may transcode, sanitize, or reject malformed media before it hits the vulnerable path
- No public PoC means exploit development cost is non-trivial
Reach the MFC buffer-release logic
321712082 adds repeated checks that dec->refcnt < MFC_MAX_BUFFERS - 1 before incrementing and storing into dec->ref_buf[...]. That is the tell: exploitation requires steering the MFC state machine into repeated released-buffer handling until the reference-buffer bookkeeping walks out of bounds. Weaponized tooling here would be a custom Exynos/Tensor MFC harness built from the public diff and codec-driver behavior, not an off-the-shelf framework.- The app/browser/messaging flow must invoke the affected MFC routines
- The crafted input must survive userspace processing and reach kernel driver state transitions
- The device must use the vulnerable binary driver before the March 2026 patch level
- Driver-state exploitation is much harder than triggering a userland parser crash
- The MFC path is hardware- and vendor-specific
- Sandboxed app contexts still need a reliable path into the vulnerable kernel code
Convert overwrite into code execution
- Attacker has a stable overwrite primitive on the target firmware
- Target defenses do not break the chain before kernel control is gained
- The exploit is tuned to the victim's exact driver/kernel image
- Reliability across mixed Pixel generations and monthly builds is hard
- Modern kernel hardening raises exploit-dev cost
- Enterprise fleets often have heterogeneous app stacks and patch cadence
Operate on the compromised handset
- Initial exploit succeeds on an affected mobile device
- Device contains useful enterprise identities or data
- Post-exploitation controls do not immediately contain the handset
- This is one device at a time, not a mass internet worm surface
- MDM, app attestation, and conditional access can reduce business impact after compromise
- Lateral movement from mobile endpoints is usually harder than from a domain-joined laptop
2026-03-05 or later on supported Pixel devices. For a HIGH verdict, deploy this compensating control within 30 days where direct patch completion is lagging.- A perimeter firewall does not help much; there is no fixed server port to block because the vulnerable surface is a local device media-driver path.
- Network vulnerability scanners will not meaningfully identify exposure; they cannot infer handset kernel-driver state from the public internet.
- Email filtering alone is insufficient; the same content path could be reached through browsers, messaging apps, or downloaded media outside mail.
The supporting signals.
| In-the-wild status | No confirmed in-the-wild exploitation in the checked sources. CISA ADP's Vulnrichment/SSVC entry shows Exploitation: none, and the CVE is not present in the CISA KEV catalog results I checked. |
|---|---|
| Proof-of-concept availability | No public PoC surfaced in the searches I checked. The main public exploit-development artifact is the AOSP/Gitiles patch diff for bug 321712082, which exposes the missing refcnt bounds guard. |
| EPSS | 0.00238 (0.238%) from the user-supplied intel, which is low for a supposedly internet-scale 9.8 bug. Downstream trackers place it roughly in the low-to-mid percentile band, not the top-tier weaponization zone. |
| KEV status | Not KEV-listed. No CISA due date, no KEV campaign metadata, and no public exploitation note in the vendor bulletin. |
| CVSS vector reality check | The published vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, but that assumes a clean remote path to the vulnerable driver. In enterprise terms this is content-driven device exploitation, not a broadly reachable network listener. |
| Affected scope | CVE/NVD says Android kernel, but the Pixel bulletin narrows the issue to MFC and the public code path lives under Exynos/Tensor media driver trees. That is materially narrower than 'every Android device'. |
| Fixed version | For Google devices, security patch level 2026-03-05 or later addresses the issue per the Pixel Update Bulletin. The fix appears in vendor driver code rather than an easy app-level package version. |
| Scanning / exposure data | Shodan/Censys/FOFA-style exposure is basically the wrong lens. This is an endpoint kernel/media path, not a routable service banner. Attack surface management platforms will not meaningfully enumerate it from the public internet. |
| Disclosure timeline | CVE published 2026-03-10. Pixel bulletin version 1.0 published 2026-03-04, updated 2026-03-09, and states it was last updated 2026-03-10 UTC. |
| Reporter / fix provenance | The visible fix commit is Samsung-authored and Google-committed in AOSP/Gitiles, with commit message media: mfc: add refcnt condition check to avoid OOB for bug 321712082. |
Sources.
Why this verdict
- Reachability is overstated:
AV:N/UI:Nreads like an internet-worm service bug, but the real prerequisite is getting crafted media into a vulnerable MFC hardware path on an affected handset. - Population is narrower than 'Android': the Pixel bulletin isolates this to MFC, and the public code lives in Exynos/Tensor media-driver trees, which sharply limits exposed fleet percentage versus generic Android CVSS math.
- Threat intel is cold: no KEV, no confirmed exploitation, no public PoC, and very low EPSS all push this below CRITICAL despite the ugly technical impact.
Why not higher?
I am not calling this CRITICAL because every practical prerequisite narrows the field: affected hardware, affected firmware, media-path reachability, and exploit reliability on specific driver builds. If this were a public-internet service with active exploitation or a mature public exploit, the score would jump fast.
Why not lower?
I am not dropping it to MEDIUM because the impact is still a kernel/media-driver memory corruption issue on a widely carried enterprise endpoint class. If weaponized, it can defeat app isolation and compromise high-value mobile identities and data, which is too consequential for a backlog-only label.
Crowdsourced verification payload.
Run this on an auditor workstation with adb and a USB- or network-connected Android device. Invoke it as ./check-cve-2026-0116.sh <serial> or just ./check-cve-2026-0116.sh for the only attached device; it needs no root on the phone, only adb shell access to read system properties.
#!/usr/bin/env bash
# check-cve-2026-0116.sh
# Purpose: Determine likely exposure to CVE-2026-0116 on Google Pixel devices.
# Logic: Pixel devices missing security patch level 2026-03-05 are treated as VULNERABLE.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
TARGET_PATCH="2026-03-05"
SERIAL="${1:-}"
fail_unknown() {
echo "UNKNOWN: $1"
exit 2
}
adb_cmd() {
if [[ -n "$SERIAL" ]]; then
adb -s "$SERIAL" "$@"
else
adb "$@"
fi
}
command -v adb >/dev/null 2>&1 || fail_unknown "adb not found in PATH"
STATE="$(adb_cmd get-state 2>/dev/null || true)"
[[ "$STATE" == "device" ]] || fail_unknown "no reachable adb device"
getprop_safe() {
adb_cmd shell getprop "$1" 2>/dev/null | tr -d '\r'
}
MODEL="$(getprop_safe ro.product.model)"
BRAND="$(getprop_safe ro.product.brand)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
RELEASE="$(getprop_safe ro.build.version.release)"
DEVICE="$(getprop_safe ro.product.device)"
HARDWARE="$(getprop_safe ro.hardware)"
SOC_MANUF="$(getprop_safe ro.soc.manufacturer)"
BOARD="$(getprop_safe ro.board.platform)"
[[ -n "$MODEL" ]] || fail_unknown "unable to read device model"
[[ -n "$PATCH" ]] || fail_unknown "unable to read security patch level"
# Normalize likely Google Pixel scope.
IS_PIXEL=0
if [[ "$BRAND" =~ [Gg]oogle ]] || [[ "$MODEL" =~ Pixel ]]; then
IS_PIXEL=1
fi
if [[ $IS_PIXEL -ne 1 ]]; then
echo "UNKNOWN: non-Pixel or unrecognized device model ('$BRAND $MODEL'); manual review required"
exit 2
fi
# Heuristic family match for supported Pixel generations likely carrying the gs/Tensor stack.
AFFECTED_FAMILY=0
if [[ "$MODEL" =~ Pixel\ (6|6a|6\ Pro|7|7a|7\ Pro|8|8a|8\ Pro|9|9a|9\ Pro|9\ Pro\ XL|9\ Pro\ Fold|10|10a|10\ Pro|10\ Pro\ XL|10\ Pro\ Fold|Fold) ]]; then
AFFECTED_FAMILY=1
fi
# Basic date comparison works because Android patch levels are YYYY-MM-DD.
if [[ "$PATCH" < "$TARGET_PATCH" ]]; then
if [[ $AFFECTED_FAMILY -eq 1 ]]; then
echo "VULNERABLE: $BRAND $MODEL | Android $RELEASE | Patch $PATCH | device=$DEVICE | hw=$HARDWARE | soc=$SOC_MANUF | board=$BOARD"
exit 1
else
echo "UNKNOWN: Pixel device with patch level $PATCH older than $TARGET_PATCH, but model family is not in the expected affected set: $MODEL"
exit 2
fi
fi
echo "PATCHED: $BRAND $MODEL | Android $RELEASE | Patch $PATCH | device=$DEVICE | hw=$HARDWARE | soc=$SOC_MANUF | board=$BOARD"
exit 0