This is less an open front door than a landmine hidden in the carrier side of the road
CVE-2026-0113 is an out-of-bounds write in ns_GetUserData inside ns_SmscbUtilities.c, a cellular-modem parsing path tied to SMS Cell Broadcast handling. The CNA text says it can cause remote elevation of privilege with no user interaction; Google's public records only pin the fix to Pixel-family devices at security patch level 2026-03-05 or later, and the Android OSV entry marks the affected range as Pixel-family specific before 2026-03-05.
Google publicly labels the issue High in the March 2026 Pixel bulletin, but for enterprise patch triage that overstates the day-to-day risk. The decisive friction is attacker position: this is not an internet-exposed web service or email client bug, it is a modem-side parser issue that likely requires carrier-path access or a rogue base-station style delivery setup to feed malicious cell-broadcast traffic into the target. That keeps it dangerous but not fleet-fire-drill dangerous.
4 steps from start to impact.
Obtain cellular delivery-path control
srsRAN; academic baseband work shows modem parsers are reachable from rogue base stations.- RF proximity to the victim or access to carrier/core broadcast infrastructure
- Specialized radio equipment and protocol knowledge, or telecom insider/partner access
- Target device must have the affected Google cellular modem stack
- This is not reachable from the public internet like a VPN or web-admin bug
- Rogue base-station operations are technically noisy, regulated, and operationally risky
- Only the relevant Pixel device population is publicly confirmed
Deliver malformed SMSCB payload into ns_GetUserData
ns_GetUserData within ns_SmscbUtilities.c. Because the bug sits in a parser, exploitation likely depends on precise message structure and modem/firmware behavior rather than generic packet spray.- Ability to send protocol-valid but malicious cell-broadcast content
- Target modem firmware version predates the
2026-03-05fix - The vulnerable code path must be enabled in that modem build
- Public technical details are sparse and the bug ID is not publicly opened
- Baseband exploitation is fragile across modem variants and firmware revisions
- Malformed traffic may be normalized or dropped before reaching the exact parser state
Convert memory corruption into modem-side code execution or privilege gain
- Reliable control over the overwritten memory region
- A modem build where exploit mitigations can be bypassed
- A stable target-specific exploit chain
- Memory corruption in baseband firmware is harder to weaponize than the CNA text alone implies
- Lack of public PoC suggests the chain is non-trivial or at least not yet commoditized
- Operational reliability matters more here than in a crash-only bug
Reach meaningful device impact
- Successful post-corruption control in the modem environment
- A usable follow-on objective such as interception, surveillance, or pivot into higher-privilege device services
- A victim population worth the specialized delivery effort
- Blast radius is mostly per-device, not one-shot tenant-wide compromise
- Enterprise mobile fleets are usually a smaller subset than server/workstation estates
- No public exploitation evidence or KEV inclusion raises the bar for emergency treatment
2026-03-05 and block them from sensitive access until updated. For a MEDIUM verdict there is no mitigation SLA; use this as an interim control while you work inside the 365-day remediation window.manufacturer=Google and security_patch < 2026-03-05 so this does not disappear into the general Android noise floor. The real control here is inventory discipline, because standard vulnerability scanners will not see this parser directly.- A WAF does nothing here because the attack surface is not HTTP.
- Email filtering does nothing because the delivery path is cellular broadcast/modem-side, not mail-borne content.
- Mobile app allowlisting is not a fix because the vulnerable code path is in modem firmware/system components below the app layer.
- Internet-facing ASM scanning will not tell you who is vulnerable; this is an RF/device exposure problem, not a public-IP exposure problem.
The supporting signals.
| In-the-wild status | No CISA KEV listing and no authoritative public reporting of active exploitation was found in the sources reviewed here. |
|---|---|
| Proof-of-concept availability | No public CVE-specific exploit or GitHub PoC was found. Realistic delivery would likely involve carrier/CBC access or rogue-RAN tooling such as srsRAN. |
| EPSS | Prompt-supplied EPSS = 0.00238 (~0.238% 30-day exploitation probability), which is low and consistent with a specialized attack path. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Technical class | Memory corruption via out-of-bounds write in a cellular modem parser; third-party databases map it to CWE-787. No official CVSS vector or score was published. |
| Affected versions | Publicly, Google exposes this as a Pixel bulletin issue in the Cellular Modem subcomponent. OSV marks the affected range as Pixel-family specific before security patch level 2026-03-05. |
| Fixed versions | Google states security patch level 2026-03-05 or later addresses the issue for supported Pixel devices. |
| Scanning / exposure data | *Inference from component location:* this is a device-side modem/RF parser, so there is no meaningful Shodan/Censys/FOFA-style internet exposure count to prioritize against. Your exposure data comes from mobile inventory + patch level, not ASM. |
| Disclosure timeline | CVE record published 2026-03-10 by Google_Devices; Pixel bulletin published 2026-03-03 and updated 2026-03-09. |
| Researcher / reporting org | Public credit was not exposed in the sources reviewed. The issuing CNA is Google_Devices. |
Sources.
- Google Pixel Update Bulletin — March 2026
- Android Security Bulletin — March 2026
- Android OSV entry PUB-A-441209133
- OpenCVE record for CVE-2026-0113
- CISA Known Exploited Vulnerabilities Catalog
- srsRAN Project documentation
- BaseSAFE: Baseband Sanitized Fuzzing through Emulation
- Google Pixel Help — Check & update your Android version
Why this verdict
- Downward pressure: attacker must control the cellular delivery path rather than just reach an exposed IP service. That implies RF proximity, carrier-side access, or telecom-grade equipment and expertise.
- Downward pressure: reachable population is narrower than the CVE text suggests. Publicly confirmed exposure is tied to supported Pixel-family devices before
2026-03-05, not a broad cross-vendor Android server estate. - Upward pressure: the bug is still pre-auth remote memory corruption with no UI in a privileged modem parsing path, so it cannot be dismissed as harmless or purely theoretical.
Why not higher?
There is no public exploitation evidence, no KEV inclusion, and no public PoC. More importantly, the path is not internet-scalable: most attackers cannot casually inject malicious cell-broadcast traffic at enterprise targets the way they can spray HTTP, VPN, or email attack surfaces.
Why not lower?
The CNA impact statement is still serious: remote, no user interaction, and memory corruption in a modem-facing parser. If you run a managed Pixel fleet for executives, journalists, field teams, or travelers, the threat model is materially stronger than a routine nuisance bug.
Crowdsourced verification payload.
Run this on an auditor workstation with the Android SDK adb tool installed, pointed at a USB-connected or network-connected device with debugging enabled. Invoke it as ./check_cve_2026_0113.sh <device-serial> or omit the serial for a single attached device; no root is required.
#!/usr/bin/env bash
# check_cve_2026_0113.sh
# Verify whether a connected Google Pixel device is patched for CVE-2026-0113
# Logic: Google publicly fixes this issue at security patch level 2026-03-05 or later.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/adb error
set -euo pipefail
TARGET_PATCH="2026-03-05"
SERIAL="${1:-}"
ADB=(adb)
if ! command -v adb >/dev/null 2>&1; then
echo "UNKNOWN: adb not found in PATH"
exit 3
fi
if [[ -n "$SERIAL" ]]; then
ADB+=( -s "$SERIAL" )
fi
# Verify connectivity
if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
echo "UNKNOWN: no reachable adb device"
exit 2
fi
getprop_safe() {
local key="$1"
"${ADB[@]}" shell getprop "$key" 2>/dev/null | tr -d '\r'
}
MANUFACTURER="$(getprop_safe ro.product.manufacturer)"
BRAND="$(getprop_safe ro.product.brand)"
MODEL="$(getprop_safe ro.product.model)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
BUILD="$(getprop_safe ro.build.fingerprint)"
if [[ -z "$PATCH" ]]; then
echo "UNKNOWN: could not read ro.build.version.security_patch"
exit 2
fi
# Normalize vendor check for Google Pixel-family devices.
shopt -s nocasematch
IS_GOOGLE=0
if [[ "$MANUFACTURER" == *google* ]] || [[ "$BRAND" == *google* ]] || [[ "$MODEL" == Pixel* ]]; then
IS_GOOGLE=1
fi
shopt -u nocasematch
if [[ "$IS_GOOGLE" -ne 1 ]]; then
echo "UNKNOWN: device is not clearly a Google Pixel device"
echo "manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL patch=$PATCH"
exit 2
fi
# YYYY-MM-DD sorts lexicographically.
if [[ "$PATCH" < "$TARGET_PATCH" ]]; then
echo "VULNERABLE: Google device patch level is below $TARGET_PATCH"
echo "manufacturer=$MANUFACTURER model=$MODEL patch=$PATCH"
echo "build=$BUILD"
exit 1
else
echo "PATCHED: Google device patch level is $PATCH (>= $TARGET_PATCH)"
echo "manufacturer=$MANUFACTURER model=$MODEL"
echo "build=$BUILD"
exit 0
fi