CISA has added CVE-2026-58704, a Google Pixel improper authorization vulnerability, to the Known Exploited Vulnerabilities Catalog based on evidence of active exploitation. For defenders, KEV inclusion is the signal that matters: this is not theoretical, and remediation should be handled as an emergency change for managed Pixel fleets and as a compliance event for Federal Civilian Executive Branch agencies under BOD 26-04.
The immediate risk is unauthorized access to protected Android components or data paths on unpatched Pixel devices. Treat any corporate Pixel with a stale Android security patch level as exposed until proven patched. Prioritize inventory, patch verification, conditional-access quarantine for noncompliant devices, and high-signal hunting for developer-mode abuse, unknown-source installs, and ADB/fastboot activity.
What Happened and Why It Matters
On 2026-09-16, CISA added one vulnerability to the KEV Catalog: CVE-2026-58704, described as a Google Pixel improper authorization issue. The summary does not provide a CVSS score or exact build number, so defenders should anchor on the KEV listing, the applicable Google Pixel security bulletin, and their MDM-reported Android security patch level rather than waiting for perfect scoring metadata.
Improper authorization flaws are especially operationally relevant on mobile devices because they can turn a legitimate permission prompt, privileged service call, binder transaction, or protected API path into a bypass. A successful exploit may allow a malicious app or local attacker to invoke functionality that should require a higher privilege, stronger user consent, or a different process identity.
For FCEB agencies, BOD 26-04 reinforces that KEV-listed CVEs must be prioritized for rapid remediation. For private-sector organizations, the practical standard should be the same: verify patch state quickly, isolate devices that cannot prove compliance, and hunt for local privilege-abuse behaviors that frequently accompany mobile exploitation.
Technical Analysis
Affected platform
- Vendor/Product: Google Pixel devices running Android.
- Vulnerability type: Improper authorization, commonly aligned to CWE-863.
- Exact affected builds: Not specified in the CISA alert summary. Confirm scope through the Google Pixel security bulletin referenced by the KEV entry and your MDM inventory.
- Enterprise exposure: Corporate-owned Pixel devices, BYOD Pixel devices with work profiles, executive devices, field devices, and any Pixel used for MFA, email, VPN, or privileged administrative apps.
How this class of flaw is exploited
From a defensive perspective, an improper authorization bug on Android usually means a security decision was made without validating the caller identity, permission state, user consent, package signature, or process boundary. The realistic enterprise attack chain is:
- User is lured into installing a malicious or trojanized app, or an attacker gains local access through another bug or physical/ADB path.
- The malicious component invokes a protected Android API, privileged service, activity, broadcast receiver, content provider, or binder interface.
- The affected component fails to enforce the correct authorization check.
- The attacker reads data, changes state, escalates privileges within the device context, disables controls, or stages follow-on credential/token theft.
- Post-exploitation commonly includes persistence through legitimate Android features, abuse of device admin APIs, accessibility services, notification access, or token/session theft rather than obvious malware files.
Exploitation requirements are likely local or app-mediated rather than purely remote. Do not let that lower urgency: mobile exploitation chains frequently combine a low-friction initial foothold with a local authorization bypass to reach enterprise credentials, MFA sessions, email, or MDM control.
Exploitation status
- CISA KEV: Listed.
- Active exploitation: Confirmed by CISA inclusion criteria.
- Public PoC: Not stated in the provided summary. Absence of a public PoC does not reduce priority once KEV-listed.
- CVSS: Not provided in the summary. Do not delay remediation while waiting for scoring.
Detection and Response
The highest-value detections are not generic Android malware signatures. Focus on control-weakening and local privilege-abuse behaviors around unpatched Pixel devices: unknown-source installs, package verifier tampering, developer options/ADB enablement, fastboot/bootloader activity from admin workstations, and MDM compliance failures.
The following Sigma rules assume Android Enterprise, MDE, MTD, or MDM telemetry is normalized into a SIEM. Tune field names to your schema and scope to managed devices to avoid developer-lab noise.
---
title: Android Pixel Unknown Source Install or Package Control Abuse
id: 3b7f4a10-9c2d-4d1f-9a7b-6f2c0a51d001
status: experimental
description: Detects package installation, install-existing, or package-management shell activity on managed Android/Pixel devices that may indicate sideloading or post-exploitation staging.
references:
- https://attack.mitre.org/techniques/T1476/
- https://attack.mitre.org/techniques/T1626/
author: Security Arsenal
date: 2026/09/17
tags:
- attack.defense_evasion
- attack.persistence
logsource:
category: process_creation
product: android
detection:
selection_pkg:
Image|endswith:
- '/pm'
- '/cmd'
- '/sh'
CommandLine|contains:
- 'pm install'
- 'cmd package install'
- 'install-existing'
- 'install-create'
- 'pm grant'
- 'appops set'
filter_managed:
DeviceManaged: true
condition: selection_pkg and filter_managed
falsepositives:
- Enterprise mobility management pushes
- Android Enterprise work profile provisioning
- Authorized developer builds in designated test groups
level: high
---
title: Android Security Control Weakening via Settings Shell
id: 8a1c5e22-4b90-44b8-b3de-2b0f7d6aa002
status: experimental
description: Detects attempts to enable unknown sources, disable package verification, or toggle developer options through settings shell commands on managed Android devices.
references:
- https://attack.mitre.org/techniques/T1562/
- https://attack.mitre.org/techniques/T1626/
author: Security Arsenal
date: 2026/09/17
tags:
- attack.defense_evasion
- attack.t1562
logsource:
category: process_creation
product: android
detection:
selection:
Image|endswith:
- '/settings'
- '/cmd'
- '/sh'
CommandLine|contains:
- 'install_non_market_apps 1'
- 'package_verifier_enable 0'
- 'development_settings_enabled 1'
- 'adb_enabled 1'
- 'verifier_verify_adb_installs 0'
falsepositives:
- Managed kiosk configuration
- Explicitly approved developer devices
level: high
---
title: Admin Workstation ADB or Fastboot Interaction With Android Device
id: f41db0aa-7b31-4d1c-8f6d-91b0ac550003
status: experimental
description: Detects ADB or Fastboot execution on Windows or Linux admin workstations, including bootloader, unlock, shell, push, or install actions that may indicate unauthorized device tampering.
references:
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1200/
author: Security Arsenal
date: 2026/09/17
tags:
- attack.execution
- attack.initial_access
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- 'adb.exe'
- 'fastboot.exe'
selection_cmd:
CommandLine|contains:
- 'adb shell'
- 'adb install'
- 'adb push'
- 'adb reboot bootloader'
- 'fastboot flashing unlock'
- 'fastboot oem unlock'
- 'fastboot flash'
condition: selection_img and selection_cmd
falsepositives:
- Approved mobile engineering and forensic acquisition
- OEM repair workflow with ticket reference
level: medium
Use this KQL in Microsoft Sentinel or Defender to correlate managed-device process signals, MDM/CEF compliance events, and workstation ADB activity. Scope first to Pixel devices and stale patch levels, then pivot to control-weakening events.
let Lookback = 14d;
let PixelDevices =
DeviceInfo
| where Timestamp >= ago(Lookback)
| where Model has "Pixel" or DeviceName has "Pixel" or OSPlatform has "Android"
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceId, DeviceName, Model, OSPlatform, OSVersion, LastSeen=Timestamp;
union isfuzzy=true
(DeviceProcessEvents
| where Timestamp >= ago(Lookback)
| where DeviceId in (PixelDevices | project DeviceId)
| where ProcessCommandLine has_any ("pm install","cmd package install","install-existing","pm grant","appops set","package_verifier_enable 0","development_settings_enabled 1","adb_enabled 1")
| project TimeGenerated=Timestamp, DeviceId, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine, AccountName, Source="DeviceProcessEvents"),
(CommonSecurityLog
| where TimeGenerated >= ago(Lookback)
| where Message has_any ("security patch","patch level","noncompliant","unknown sources","developer options","usb debugging") and (DeviceProduct has "Pixel" or DeviceName has "Pixel" or Message has "Pixel")
| project TimeGenerated, DeviceName, DeviceProduct, Message, SourceIP, DestinationUserName, Source="MDM_CEF"),
(DeviceProcessEvents
| where Timestamp >= ago(Lookback)
| where ProcessVersionInfoInternalFileName in~ ("adb.exe","fastboot.exe") or ProcessCommandLine has_any ("adb shell","adb install","adb push","fastboot flashing unlock","fastboot oem unlock","fastboot flash")
| project TimeGenerated=Timestamp, DeviceId, DeviceName, InitiatingProcessAccountName=AccountName, ProcessCommandLine, Source="AdminWorkstation")
| join kind=leftouter (PixelDevices) on DeviceId
| summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Sources=make_set(Source), Commands=make_set(ProcessCommandLine, 20) by DeviceName, Model, OSVersion, Source
| order by LastSeen desc
Velociraptor is most useful here on the workstation and server side: hunt for ADB/Fastboot execution, unexpected mobile tooling, and evidence of bootloader or package manipulation outside approved mobile engineering groups.
-- Hunt admin workstations and servers for ADB/Fastboot execution and Android tampering commands
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)adb|fastboot'
OR CommandLine =~ '(?i)adb shell|adb install|adb push|adb reboot bootloader|fastboot flashing unlock|fastboot oem unlock|fastboot flash'
Run this Bash workflow against an ADB-connected test device or through an approved mobile engineering jump host to verify patch level and control state. Do not use it to bypass enrollment or erase devices; use MDM for fleet-wide enforcement.
# Verify device identity, build, and Android security patch level
adb shell getprop ro.product.model
adb shell getprop ro.build.display.id
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch
# Check high-risk control state; values vary by Android version and MDM policy
adb shell settings get global development_settings_enabled
adb shell settings get global adb_enabled
adb shell settings get global package_verifier_enable
adb shell settings get global verifier_verify_adb_installs
adb shell settings get secure install_non_market_apps
# Re-enable verification where policy permits; coordinate changes with MDM owner
adb shell settings put global package_verifier_enable 1
adb shell settings put global verifier_verify_adb_installs 1
# List recently installed third-party packages for triage; export to case ticket
adb shell pm list packages -3 | sort
adb shell dumpsys package | grep -i -E 'installerPackageName|lastUpdateTime' | head -200
Remediation
- Patch immediately: Deploy the Google Pixel security update that corresponds to the KEV entry. Require the MDM-reported Android security patch level to meet or exceed the fixed level listed in Google’s bulletin; do not assume OS version alone proves remediation.
- Enforce compliance gates: Mark Pixel devices noncompliant if patch level is stale, USB debugging/developer options are enabled, unknown-source installs are permitted, or Play Protect/package verification is disabled. Quarantine from email, VPN, M365, and SSO until remediated.
- Prioritize KEV deadlines: FCEB agencies must follow the KEV due date and BOD 26-04 requirements. Non-federal organizations should treat KEV-listed mobile CVEs as emergency-change candidates with a 24-72 hour verification goal for high-risk users and a strict fleet deadline.
- Reduce attack surface: Disable developer options and ADB for standard users, block unknown sources, restrict accessibility/device-admin grants, require work profile for BYOD, and enforce strong device encryption and screen lock.
- Protect credentials: Revoke active sessions and refresh tokens for users whose devices were noncompliant during the exposure window. Rotate high-value credentials if suspicious package, ADB, or control-weakening events are found.
- Monitor post-patch: Continue hunting for 14 days after patch completion. A patched device can still carry persistence or stolen tokens acquired before remediation.
- Validate exceptions: Any developer, lab, kiosk, or forensic use of ADB/Fastboot must be ticketed, time-bound, network-segmented, and excluded from production conditional access.
Authoritative references: CISA KEV Catalog entry for CVE-2026-58704 at https://www.cisa.gov/known-exploited-vulnerabilities-catalog, the CISA alert at https://www.cisa.gov/news-events/alerts/2026/09/16/cisa-adds-one-known-exploited-vulnerability-catalog, and the applicable Google Pixel/Android security bulletin linked from Google’s security bulletin index at https://source.android.com/docs/security/bulletin/pixel.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.