Exploited Pixel modem flaw is rated High, not Critical, and Google has not said who was targeted

The score moved in a day; the evidence did not

CISA's scorers changed the CVSS rating for CVE-2026-58704 from 8.0 to 8.8 in just under 22 hours, and nothing new had come from Google in between. NVD's change history shows the CISA-ADP vector arriving at 19:17 UTC on 15 September as AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, which computes to 8.0. At 17:17 UTC on 16 September it was replaced by the same vector with one metric changed, PR:N, which computes to 8.8. Google, the numbering authority that issued the CVE, supplied no CVSS score at all. So the 8.0 in some of the early coverage, and the talk of attackers needing basic privileges on the device, were not mistakes when they were written. They were CISA's first draft.

What that does not establish is that anyone learned more about the attack. Neither number is Google's, and neither describes how the flaw was used, against whom, or whether it was one step in a longer chain. The only first-hand statement about exploitation is a single sentence in Google's Pixel Update Bulletin for September 2026, published on 15 September: there are indications that CVE-2026-58704 "may be under limited, targeted exploitation". The rest of what readers have been told, including "zero-click", "hacked" and the likely hand of spyware vendors, comes from Google's standard CVE wording or from context the reporters added.

CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 16 September with a due date of 19 September, a Saturday, three days later. That deadline binds US federal civilian agencies. For UK organisations the clock is different, and so is the useful question: which of your phones are Pixels, and what security patch level are they actually running?

What Google said, and what it did not

The primary record is short. Google's Pixel bulletin lists 110 CVEs. This one is a single row: CVE-2026-58704, Android bug ID A-484011314, type EoP (elevation of privilege), severity High, subcomponent Modem. The CVE record filed by Google's device team adds one description: a possible permission bypass due to a logic error in the cellular modem, which "could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed", with no user interaction required. Set against the questions a security lead would ask, the gaps are wider than the answers.

CVE-2026-58704 on the primary record. Sources: Google Pixel Update Bulletin September 2026, the CVE.org record, NVD, CISA KEV. All read 17 September 2026.

Question	Stated on the record	Not stated
Was it exploited?	Google: indications it may be under limited, targeted exploitation. CISA SSVC: exploitation active.	How many devices, when it started, or how Google found out.
Who was targeted?	Nothing.	Any sector, country, role or number of victims.
Who did it?	Nothing.	Any actor, spyware vendor or government.
What kind of bug?	Elevation of privilege, High, Modem. A permission bypass from a logic error.	Which privilege is gained, from which context, into which.
How is it reached?	Remote (proximal/adjacent). CISA-ADP vector AV:A.	What the adjacent network is: cellular radio, Wi-Fi or something else.
User interaction?	Not needed.	Whether the attacker first needs a foothold, such as code already running in the modem.
Part of a chain?	Nothing.	Any companion CVE, in this bulletin or elsewhere.
Which devices?	All supported Google devices get the 2026-09-05 patch level. KEV product: Pixel.	A list of affected models, or anything on Pixel Tablet or Pixel Watch.
Signs of compromise?	None published.	Any way to tell whether a device was hit before it was patched.
Fixed in?	Security patch level 2026-09-05 or later.	Per-model build numbers (the bulletin gives none).

Some coverage went further than this table. One report described the bug as letting an attacker break out of the modem's sandbox into the rest of the phone's data. That may turn out to be right, but it is not in the bulletin, the CVE record or the KEV entry. It is a reasonable reading of "escalation of privilege" in a modem, and it should be labelled as one. Several outlets also noted that bugs like this are often used by commercial spyware makers. That is fair context. It is not attribution, and no primary source offers any.

"Zero-click" is a true label that hides the condition

The phrase comes from the last sentence of the CVE description: user interaction is not needed. That is accurate, and it is where the headlines stopped. The words just before it matter more. In Google's own Android severity guidance, proximal attack vectors "are considered remote" but are defined as bugs that can be exploited "only by an attacker who is physically near the target device". In Google's vocabulary, then, "remote (proximal/adjacent)" means near, not anywhere on the internet. CISA-ADP's AV:A (adjacent network) says the same thing in CVSS terms.

The severity tells you something too. Google's severity matrix rates remote arbitrary code execution within the cellular baseband with no user interaction as Critical. CVE-2026-58704 is not typed as code execution, and it is rated High. The same bulletin fixes four other Modem issues, none of them flagged as exploited: CVE-2026-56967 (remote code execution, Critical), CVE-2026-0159 (remote code execution, High), CVE-2026-55306 (denial of service, Critical) and CVE-2026-56975 (denial of service, High). Google's High row includes a pivot from compromised baseband firmware into the main application processor kernel, or a bypass of the mechanisms that keep the two apart. Google does not say which row it applied here.

Who scored what, and when

Much of the confusion clears once each field is credited to whoever actually set it. The CVE record has two containers: one from Google as the numbering authority, one from CISA's Authorised Data Publisher programme (CISA-ADP), which adds scores and weakness types to records that arrive without them. NVD then layers its own analysis on top.

Who assigned each field on CVE-2026-58704. Sources: CVE.org record, NVD CVE API and change history, CISA KEV feed, read 17 September 2026. Times UTC.

Field	Value	Assigned by
CVSS score	None supplied	Google (CNA)
Problem type	Elevation of privilege	Google (CNA)
Affected product	Android, version given as Android kernel	Google (CNA)
Severity	High	Google, Pixel bulletin
CVSS 3.1, first	8.0, with PR:L (low privileges required)	CISA-ADP, 15 Sep 19:17
CVSS 3.1, current	8.8, with PR:N (no privileges required)	CISA-ADP, 16 Sep 17:17
Weakness	CWE-285 and CWE-693	CISA-ADP
SSVC	Exploitation none, then active. Automatable: no. Technical impact: total.	CISA-ADP
Applicability	cpe:2.3:o:google:android:- (all Android, no version)	NVD analysis, 16 Sep 18:25
KEV entry	Product Pixel, added 16 Sep, due 19 Sep, CWE-693	CISA KEV

Two details in that table carry practical weight. The first is the score arithmetic. Changing privileges required from low to none raises the CVSS exploitability sub-score from 2.1 to 2.8, while the impact sub-score stays at 5.9. The finding was not reclassified; the scorer changed its view of one precondition. The public record does not say why. CISA-ADP's SSVC judgement that exploitation is not automatable also sits comfortably with Google's "limited, targeted" wording.

The second is the applicability data, and it is the friendly-name problem in miniature. NVD's configuration matches Android, with no version and no device qualifier. Google's own container names the product as Android with a version of "Android kernel", which is a category label rather than a version. A vulnerability scanner that maps CVEs through CPE alone may flag every Android handset you own, including a fleet with no Pixels in it. A tool that maps through vendor bulletins may flag nothing at all. Neither matches what the primary source says, which is: Pixel.

Scope: Pixel on the record, and nothing more

KEV names the product as Pixel. The CVE appears in the Pixel bulletin, not in the September Android Security Bulletin that every Android maker works from. That bulletin lists 180 CVEs, and none of them overlap with the Pixel bulletin's 110. The CVE's reference is a plain Android bug ID with no partner prefix, whereas the modem issues in the Android bulletin that belong to chip suppliers carry MediaTek or Unisoc reference numbers. No primary source names the supplier of the affected modem, and neither do we.

One consequence is easy to miss. The Android Security Bulletin states that fixes documented in device and partner bulletins, such as Google's Pixel bulletin, are not required for declaring a security patch level. So on a Samsung or Motorola handset, a 2026-09-05 patch level tells you nothing, either way, about CVE-2026-58704. Nothing we read suggests those devices are affected. You simply cannot use the patch string to prove it.

Which devices the record puts in scope. Sources: Pixel Update Bulletin and Android Security Bulletin September 2026, Google Pixel update support page, NVD, read 17 September 2026.

Device group	In scope on the record?	What to do
Pixel phones on Google's update schedule: Pixel 6 series to Pixel 11 series, a-models and Folds	Yes. The bulletin covers supported Google devices; KEV names Pixel.	Require patch level 2026-09-05 or later.
Pixel 5a and older	Not stated. Google says they no longer receive security updates.	Retire, or cut off access to organisational data.
Pixel Tablet, Pixel Watch	Not stated.	Check the device's own update status; do not assume either way.
Other Android makers	Not stated by any source.	Apply each maker's September update on its own schedule; do not report it as this CVE.
Scanner hits from NVD CPE	The CPE covers all Android.	Check the device make before escalating.

Google's Pixel update page lists 24 phones on its update schedules: seven with five years of updates (Pixel 6, 6 Pro, 6a, 7, 7 Pro, 7a and the original Fold) and 17 with seven years, from Pixel 8 through the Pixel 11 family. It names Pixel 5a and everything older as no longer receiving security updates. Google does not say which of them carry the vulnerable modem code. It says all supported devices will receive the fix, which is the only instruction that matters for a fleet.

The UK clock is 14 days, not three

CISA's 19 September deadline applies to US federal civilian agencies under its binding directive. The nearest UK equivalent for most organisations is Cyber Essentials: Requirements for IT Infrastructure v3.3, published by the NCSC in April 2026. It lists mobile phones under security update management. Software must be updated within 14 days of release where the vendor describes the fix as critical or high risk, or where the CVSS v3 base score is 7 or above. It also covers bundled updates: if one update fixes several issues and any of them is critical or high risk, the whole update must go on within 14 days.

The September Pixel update clears that bar several times over. It includes 46 Critical fixes, and CVE-2026-58704 is itself High, with a CISA-ADP score of 8.8. Counting 14 days from the bulletin date of 15 September gives 29 September 2026. Two cautions apply. First, Google says Pixel updates roll out gradually and can take a few weeks to reach a device, so how an assessor treats a staggered rollout is a question for your certification body, not something to assume. Second, under the scheme, personally owned devices that access organisational data or services are in scope, unless they are used only for native voice, native text or MFA apps. A director's personal Pixel that reads work email counts.

How to see the real patch level, and what MDM can enforce

On the handset, Google's Android version help page points users to Settings, then About phone, then Android version. That screen shows four separate items: Android version, Android security update, Google Play system update and build number. Only Android security update is the security patch level. The Google Play system update date is a different mechanism, and the Android Security Bulletin notes that on some devices it carries a date string matching the 2026-09-01 patch level. A line reading September 2026 next to Google Play system update is not the modem fix.

Google's help page also notes that Pixel phones install downloaded updates in the background, and that the update only becomes active after the next restart. A phone that has downloaded the September update but not restarted is still running the old code. For devices you can reach over USB in a lab or on a service desk, the patch level is a single system property; Google's bulletin names it.

adb shell getprop ro.build.version.security_patch
# A fixed Pixel returns 2026-09-05 or later

At fleet scale, the controls exist in the mainstream MDM platforms:

• Microsoft Intune Android Enterprise compliance policies include a Minimum security patch level setting, entered as a YYYY-MM-DD date. Devices below it are marked noncompliant. The setting is available for fully managed, dedicated and corporate-owned work profile devices, and for personally owned work profiles.
• Android Management API, which sits under many third-party MDMs, reports each device's securityPatchLevel in its device software information, plus a pending-update status that can read SECURITY_UPDATE_AVAILABLE.
• The same API's system update policy offers AUTOMATIC (install as soon as available) and WINDOWED (install in a daily maintenance window). Its POSTPONE option, according to Google, does not affect monthly security patches.
• Freeze periods are the trap. Google's reference says that during a freeze period all incoming system updates, security patches included, are blocked. If you set a freeze for a change-control window, check whether one is active now.

A practical warning about compliance rules: a policy requiring 2026-09-05 across all Android devices will also mark down other makers' handsets whose September update has not landed yet. That breaks access for people who were never exposed to this CVE. If your MDM can target by manufacturer or model, scope the rule to Pixels.

Patching closes the door; it does not tell you who came in

The KEV entry marks the flaw for forensic triage, and CISA's alert says its new directive sets expectations for when agencies must check whether a system was compromised before the patch went on. That is the right instinct for a targeted exploit. The difficulty is that Google has published nothing to check against: no indicators, no description of the payload, no timeframe. A patch level tells you the device is protected from now on. It tells you nothing about last month.

Our judgement, not a sourced finding: "limited, targeted" exploitation is the category where the victim list is short and chosen. For most UK organisations the realistic response is to name the few people whose roles make them plausible targets, such as senior executives, staff handling sensitive negotiations or investigations, and people who travel to higher-risk jurisdictions, and then decide whether their Pixels warrant a specialist check or simple replacement.

Expect mobile threat defence vendors to market detection for this flaw. Some may have genuine telemetry. Ask any vendor what specifically they detect, given that no public indicators exist, and whether that detection comes from this campaign or from generic behaviour. That is a question about method, not an accusation. Vendors have a commercial interest in the answer, and so does your budget.

What to do, in order

The question that exposes the gap

Google has done the most important thing: it shipped a fix and said plainly that the flaw was being exploited. CISA did the next thing: it put a date on it. Nobody on the record has done the part a targeted organisation needs most, which is to help it find out whether it was one of the targets. The 8.0 and the 8.8 were both answers to a question nobody in a UK security team is actually asking.

So the question to put to your mobile team, your MDM provider and, through your account manager, to Google is this: if one of our Pixel users was among the limited, targeted few, what would we look at to know, when nothing has been published to look for?

Key facts