Google patches Pixel cellular modem permission bypass used in targeted attacks

What happened

Google disclosed a permission bypass in the Pixel cellular modem, tracked as CVE-2026-58704, and said at disclosure that it “may be under limited, targeted exploitation” [4]. The National Vulnerability Database describes it as a logic error in the modem code that allows a permission bypass and leads to escalation of privilege without additional execution privileges [3].

On 16 September 2026, CISA added the CVE to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation, with a remediation due date of 19 September 2026 — three days [1][2]. CISA lists ransomware use as unknown [1]. The required action is to apply vendor mitigations in line with BOD 26-04 and CISA’s forensics triage requirements, or discontinue use of the product if mitigations are unavailable [1].

Both Google and CISA indicate the flaw can be exploited with no user interaction, which matches the NVD entry stating user interaction is not needed [3][4]. The Register characterises this as a zero-click attack path, and reports that it asked Google for more detail on the scope of exploitation and what attackers can achieve; as of that report, the publicly available detail remained very limited [4].

Who is affected

Google Pixel devices with the vulnerable cellular modem firmware [1][3]. The sources available do not list which specific Pixel models or which security patch level contains the fix, so confirm the target build from Google’s own bulletin before you set a compliance baseline. The fix is delivered through a device update — the sources say the hole is closed provided the device is updated [4].

Federal Civilian Executive Branch agencies are bound by the 19 September deadline under BOD 26-04 [1][2]. Everyone else is not, but the same logic applies: this is a flaw in a cellular baseband on a widely deployed consumer handset, and mobile fleets are rarely inventoried as carefully as servers.

How it works, as far as the sources go

The public detail is thin. What is stated: the defect is a logic error in the modem’s code that lets an attacker bypass a permission check and escalate privilege [3]. The CVSS vector supplied in our enrichment data is CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — adjacent network access, low complexity, no privileges and no user interaction required, with high impact to confidentiality, integrity and availability. “Adjacent” here means the attacker needs to be reachable over the radio path rather than arbitrary internet access, which is consistent with a modem-side bug rather than something an ordinary web page can reach.

There is a discrepancy on the score. The Hacker News reports CVSS 8.0 [3]; the enrichment data we work from records 8.8 for the same CVE. We have not resolved which figure Google and NVD ultimately published. Our computed severity for this item is high either way, and the practical response does not change.

No source names an attacker, a campaign or a victim set. The Register observes that zero-click chains of this kind are commonly associated with commercial spyware operations, but presents that as context rather than attribution for this case [4]. Treat it as context, not a finding.

Why the short deadline matters

BOD 26-04 requires agencies to prioritise rapid remediation of KEV-listed vulnerabilities on exposed assets that give total control after exploitation, and it sets expectations for checking whether a system was already compromised before the patch landed [2]. A three-day window plus a forensics triage requirement is the strongest signal available in the public record about how CISA reads this bug. There is no equivalent public evidence about how broadly it has been used.

Baseband flaws are awkward operationally. In our experience the modem layer sits outside what most MDM tooling reports on, and exploitation over the radio path is unlikely to generate the app-layer events defenders normally rely on — that is our own assessment, not something the sources address. None of the four sources here discuss mitigations other than applying the vendor update, so plan on the update being the remedy unless Google’s bulletin says otherwise.

What to do

• Push the Pixel update now. Confirm the exact fixed security patch level from Google’s bulletin, then treat any Pixel below that level as vulnerable.
• If you are an FCEB agency, the KEV due date was 19 September 2026 and the action includes CISA’s forensics triage requirements, not just patching [1].
• Inventory Pixel devices actually in use, including BYOD handsets with mail, VPN or SSO access. You cannot patch what you have not enumerated.
• Report on patch level, not on “update pushed”. Verify per-device compliance through MDM attestation rather than assuming the update installed.
• For high-risk users — executives, journalists, staff handling sensitive matters — prioritise them first and consider whether hardened modes and reduced attack surface are appropriate given the zero-click nature of the flaw [4].
• Retire Pixel models that no longer receive firmware updates. CISA’s guidance explicitly contemplates discontinuing use where mitigations are unavailable [1].
• Do not wait for indicators of compromise. None have been published in the sources we have.