← Back to Feed CACHED · 2026-10-25 04:25:12 · CACHE_KEY CVE-2026-58704
CVE-2026-58704 · CWE-285 · Disclosed 2026-09-15

Google Pixel Cellular Modem baseband permission bypass via logic error

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A pickpocket who only needs to stand near you on the subway to empty your wallet

CVE-2026-58704 is a permission-bypass vulnerability in the cellular modem firmware (baseband) of Google Pixel devices, from the Pixel 6 series through the Pixel 11 family, including Pixel Tablet and Pixel Fold. A logic error in the modem's authorization code allows an attacker within radio proximity (adjacent network — think rogue cell tower or IMSI catcher) to escalate privileges at the baseband layer without any user interaction and without needing any prior execution privileges on the device. The baseband operates below Android's application-layer security model, meaning a successful exploit grants access to a deeply privileged execution environment that can intercept calls, SMS, and location data before the OS even sees them. The bug is tracked internally as A-484011314; the tracker remains private. Google patched it in the September 15, 2026 Pixel Update Bulletin at security patch level 2026-09-05.

Google rates this HIGH at CVSS 8.8, and that score is technically correct for the vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The adjacent-network attack vector is the key friction point — this is not remotely exploitable over the internet, which caps mass-exploitation potential. However, the zero-click nature, the KEV listing within 24 hours of disclosure, and Google's use of the phrase *limited, targeted exploitation* — language historically reserved for commercial spyware operations (NSO Group, Intellexa, Candiru) — mean the friction is irrelevant for the threat actors who actually wield this class of exploit. For enterprise defenders managing a Pixel fleet, the vendor severity is fair; noisgate trims slightly to 7.8 to reflect the per-device blast radius and adjacent-only vector, but the active exploitation keeps this firmly HIGH.

"Actively exploited Pixel baseband zero-click flaw demands immediate MDM-pushed patching."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker establishes radio proximity

The adversary deploys a rogue base station (IMSI catcher / Stingray / fake eNodeB) or positions themselves on the same Wi-Fi segment as the target Pixel device. Commercial surveillance vendors routinely operate portable IMSI catchers from vehicles or backpacks within a few hundred meters of the target. This step requires physical proximity, not internet access.
Conditions required:
  • Physical or radio proximity to target device
  • Rogue base station or adjacent Wi-Fi access
Where this breaks in practice:
  • Requires physical operational deployment near the target
  • IMSI catcher equipment is export-controlled in many jurisdictions
  • Limits exploitation to one target at a time in most scenarios
Detection/coverage: Rogue base station detection apps (e.g., SnoopSnitch, EFF Rayhunter) can flag IMSI catchers, but coverage is spotty and enterprise MDM solutions generally do not monitor for fake cell towers.
STEP 02

Modem authorization bypass triggered

The attacker sends crafted cellular signaling messages that exploit the logic error in the Pixel modem's permission-checking code. Because the modem processes radio-layer traffic before the Android OS permission model applies, the faulty authorization check is reached without any authentication or privilege on the device. This is a zero-click vector — the device owner sees nothing, taps nothing, and approves nothing.
Conditions required:
  • Target device running Pixel firmware below security patch level 2026-09-05
  • Active cellular radio on the device
Where this breaks in practice:
  • Exploit must be tailored to the specific Pixel modem firmware version
  • No public PoC exists, limiting this to well-resourced actors
Detection/coverage: No known scanner or EDR agent detects this at the baseband layer. Android's built-in exploit detection (MTE, GWP-ASan) does not cover modem firmware.
STEP 03

Privilege escalation at baseband layer

Successful exploitation grants the attacker elevated privileges within the modem's execution environment. The baseband processor handles all cellular communication — voice, SMS, data, and location signaling — independent of the Android application processor. Compromise at this layer means the attacker can intercept or manipulate cellular traffic before it reaches the OS.
Conditions required:
  • Successful exploitation of the authorization bypass in step 2
Where this breaks in practice:
  • Baseband environments vary across Pixel generations, requiring per-model exploit adaptation
  • Pixel's Tensor security architecture includes some modem isolation, though the extent of isolation for this specific flaw is undisclosed
Detection/coverage: Google Play Protect and standard MDM agents cannot inspect baseband state. Post-compromise forensic indicators may appear in modem crash logs if the exploit is noisy.
STEP 04

Data exfiltration or surveillance implant

With baseband-level access, the attacker can silently intercept calls, SMS (including 2FA codes), and precise location data. In commercial spyware operations, this access is typically chained with an application-processor exploit to install a full surveillance implant (microphone, camera, file access). Even without chaining, baseband access alone yields high-value intelligence for targeted surveillance.
Conditions required:
  • Sustained radio proximity or persistent implant capability
  • Optional: additional exploit for application processor to achieve full device compromise
Where this breaks in practice:
  • Maintaining persistent access requires either continuous proximity or a secondary persistence mechanism
  • Full device compromise requires an additional exploit chain beyond this CVE
Detection/coverage: Amnesty International's Mobile Verification Toolkit (MVT) can detect some spyware implants post-facto. iVerify and Lookout offer limited baseband anomaly detection on managed devices.
03 · Compensating Control

1
HIGH 7.8→IGNORE 0.0
SEVERITY REDUCED
Push OTA patch to 2026-09-05 via MDM immediately — The definitive fix is Google's September 2026 security update (patch level 2026-09-05). Use your MDM (Intune, JAMF, VMware Workspace ONE, Google endpoint management) to force the OTA update and set a compliance policy that blocks corporate resource access for devices below this patch level. Given KEV listing and active exploitation, deploy within hours — override the noisgate HIGH mitigation SLA of 30 days with the KEV-driven immediate timeline.
2
HIGH 7.8→LOW 2.5
SEVERITY REDUCED
Disable cellular radio on high-value devices in sensitive locations — If patching cannot be completed immediately, enabling airplane mode (or disabling the cellular radio while keeping Wi-Fi) eliminates the adjacent-network cellular attack vector entirely. This is a temporary measure for executives or sensitive personnel in high-threat environments. Deploy within the noisgate HIGH mitigation SLA of 30 days, though given KEV status, implement within hours for high-value targets.
3
HIGH 7.8→MEDIUM 5.5
SEVERITY REDUCED
Enforce MDM compliance gating on patch level — Configure MDM conditional access policies to quarantine or block corporate resource access (email, VPN, internal apps) for any Pixel device reporting a security patch level below 2026-09-05. This does not fix the vulnerability but ensures unpatched devices cannot access sensitive corporate data, limiting the value of a compromised device to the attacker. Deploy within 30 days per noisgate HIGH mitigation SLA.
4
HIGH 7.8→HIGH 7.0
Deploy rogue base station detection where available — Tools like EFF's Rayhunter project or commercial solutions (FirstPoint Mobile Guard, Privoro) can detect IMSI catchers and rogue eNodeBs in the vicinity of high-value facilities. This provides detection-layer coverage for the primary attack vector. However, coverage is immature and not a substitute for patching.
What doesn't work
  • Standard EDR/MTD agents — Mobile threat defense (Lookout, Zimperium, CrowdStrike Falcon for Mobile) operates at the Android OS layer and cannot inspect or protect the baseband firmware. The exploit fires below the OS security boundary.
  • Network-level firewalls or WAFs — This is a cellular radio-layer attack, not an IP-based network attack. Enterprise perimeter controls are irrelevant to the attack vector.
  • App-level sandboxing or Google Play Protect — Play Protect scans applications, not modem firmware. The vulnerability exists in a completely separate execution environment from the Android application processor.
  • VPN on the device — A VPN encrypts IP-layer traffic but does not affect cellular signaling-layer messages that reach the modem before the IP stack is involved.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild StatusActively exploited. Google confirmed *limited, targeted exploitation* in the September 2026 Pixel Update Bulletin. CISA added to KEV on 2026-09-16 with a 3-day remediation deadline under BOD 26-04. Language is consistent with commercial spyware vendor tradecraft.
Proof-of-ConceptNo public PoC. No repositories on GitHub named after CVE-2026-58704 contain working exploit code. pocindex.io, ExploitDB, and Nuclei templates show no entries. The exploit is presumed held by a commercial surveillance vendor. Bug tracker A-484011314 remains private.
EPSS0.00591 (top ~6%). Low probability of mass exploitation, consistent with a targeted-exploitation profile rather than commodity attack tooling.
KEV StatusListed 2026-09-16. CISA required federal civilian agencies to remediate by 2026-09-19 (3-day window). This aggressive timeline reflects the zero-click, actively-exploited nature.
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 8.8. Adjacent vector caps remote reachability. No privileges, no interaction, full CIA impact. Scope is Unchanged, meaning the modem context is the security boundary.
Affected VersionsAll supported Google Pixel devices: Pixel 6, 6 Pro, 6a, 7, 7 Pro, 7a, 8, 8 Pro, 8a, 9, 9 Pro, 9 Pro Fold, 10, 10 Pro, 11, 11 Pro, Pixel Tablet, Pixel Fold — any firmware below security patch level 2026-09-05. Pixel-specific; does not affect Samsung, OnePlus, or other Android OEMs.
Fixed VersionSecurity patch level 2026-09-05 or later, delivered via the September 15, 2026 Pixel Update Bulletin. OTA available for all supported devices.
Scanning / ExposureNot applicable for Shodan/Censys/GreyNoise. This is a cellular baseband vulnerability, not an internet-facing service. Exposure is measured in Pixel device installed base (~100M+ active devices globally per Google). Enterprise exposure depends on MDM-reported patch levels.
Disclosure Date2026-09-15 (Pixel Update Bulletin). CISA KEV added 2026-09-16.
Researcher / AttributionUndisclosed. Google has not credited a researcher or organization. The bug tracker is private. The exploitation pattern is consistent with commercial surveillance vendors (NSO Group, Intellexa, Candiru) based on Google's *limited, targeted* language.

Sources.

  1. Google Pixel Update Bulletin — September 2026
  2. CSA Research Note — Pixel Modem Zero-Day
  3. Malwarebytes — Google Pixel Modem Flaw
  4. SecurityOnline — Pixel Vulnerability Exploited
  5. CyberInsider — Pixel Modem Zero-Day
  6. Android Authority — Pixel Zero-Click Vulnerability
  7. 9to5Google — Pixel Targeted Zero-Day
  8. OpenCVE — CVE-2026-58704
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.8/10)

Why this verdict

  • Adjacent-only vector limits mass exploitation. AV:A means the attacker must be in radio proximity or on the same network segment — not remotely exploitable over the internet. This eliminates drive-by and internet-scale attack scenarios, representing a significant narrowing of the reachable population compared to AV:N.
  • Zero-click + no privileges = minimal per-target friction. Once in proximity, the attacker needs nothing from the victim — no phishing, no app install, no interaction. This offsets the adjacency constraint for motivated, resourced adversaries.
  • Active exploitation confirmed (KEV-listed). This is not theoretical. Commercial spyware operators have operational capability to deploy IMSI catchers and have demonstrably used this exploit against real targets. KEV listing within 24 hours of disclosure signals high confidence in exploitation evidence.
  • Role multiplier: Enterprise mobile fleet. Pixel devices in enterprise serve roles ranging from (a) low-value: personal-use employee BYOD, to (b) typical: corporate-managed MDM devices for line-of-business workers, to (c) high-value: executive devices, security team phones, devices carrying privileged credentials (MFA authenticators, VPN tokens, email with sensitive data). On a high-value executive Pixel, baseband compromise yields call interception, SMS 2FA theft, and location tracking — a complete surveillance capability. However, the blast radius is per-device, not fleet-scale or domain-scale. An attacker compromises one phone at a time with physical proximity. This is not a hypervisor, DC, or network edge appliance where one exploit pivots to thousands of hosts.
  • No public PoC constrains threat to well-resourced actors. Without public exploit code, commodity attackers and script kiddies cannot reproduce this. The threat is limited to commercial surveillance vendors and state-aligned operators with baseband exploitation capability — a small but highly capable adversary pool.
  • Pixel-specific scope. This affects only Google Pixel devices, not the broader Android ecosystem. In a 10,000-host enterprise, the Pixel subset may be 5-20% of the mobile fleet depending on device policy, further narrowing the exposed population.

Why not higher?

CRITICAL would require either fleet-scale blast radius or a canonical high-value-role component. While this is a deeply privileged baseband flaw with active exploitation, the blast radius is per-device (one phone at a time), requires physical proximity, and Pixel phones are consumer/mobile endpoints — not identity infrastructure, hypervisors, or network edge appliances. The adjacent-only vector fundamentally caps the scalability of exploitation. Even with KEV listing, the combination of per-device scope and proximity requirement keeps this below the CRITICAL floor.

Why not lower?

MEDIUM would be inappropriate given confirmed active exploitation (KEV-listed), zero-click attack surface, and the depth of compromise (baseband-level access below the OS security model). The lack of a public PoC and adjacent vector do add friction, but the proven operational use by surveillance vendors and the sensitivity of data accessible via baseband compromise (calls, SMS, location) keep this firmly at HIGH. Downgrading past HIGH when CISA mandated a 3-day federal remediation window would be indefensible.

06 · Verification

Crowdsourced verification payload.

Run this script from an auditor workstation with ADB access to the target Pixel device(s). The device must have USB debugging enabled and be connected via USB or authorized for ADB over Wi-Fi. Requires adb in PATH. Invoke: bash check_cve_2026_58704.sh — no root required on the device.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_58704.sh
# Checks Google Pixel devices for CVE-2026-58704 patch status
# Requires: adb in PATH, target device connected with USB debugging enabled
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

REQUIRED_PATCH="2026-09-05"

# Check adb is available
if ! command -v adb &>/dev/null; then
  echo "UNKNOWN — adb not found in PATH"
  exit 2
fi

# Check device is connected
DEVICE_COUNT=$(adb devices | grep -cw 'device' || true)
if [ "$DEVICE_COUNT" -lt 1 ]; then
  echo "UNKNOWN — no ADB device connected"
  exit 2
fi

# Get device manufacturer
MANUFACTURER=$(adb shell getprop ro.product.manufacturer 2>/dev/null | tr -d '\r')
if [[ "${MANUFACTURER,,}" != "google" ]]; then
  echo "UNKNOWN — device is ${MANUFACTURER}, not Google Pixel (CVE-2026-58704 is Pixel-specific)"
  exit 2
fi

# Get current security patch level
PATCH_LEVEL=$(adb shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN — could not read security patch level"
  exit 2
fi

MODEL=$(adb shell getprop ro.product.model 2>/dev/null | tr -d '\r')
echo "Device: ${MODEL} (${MANUFACTURER})"
echo "Security patch level: ${PATCH_LEVEL}"
echo "Required patch level: ${REQUIRED_PATCH}"

# Compare dates (YYYY-MM-DD format sorts lexicographically)
if [[ "$PATCH_LEVEL" < "$REQUIRED_PATCH" ]]; then
  echo "VULNERABLE — CVE-2026-58704: patch level ${PATCH_LEVEL} is below ${REQUIRED_PATCH}"
  exit 1
else
  echo "PATCHED — CVE-2026-58704: patch level ${PATCH_LEVEL} meets or exceeds ${REQUIRED_PATCH}"
  exit 0
fi