Android’s September patches: the adbd flaw and the update fields to check

“Android is up to date” can hide several different states. A work phone has an Android version, a security patch level, a Google Play system-update date and a manufacturer build. The September bulletin is a good example of why those details matter.

What the September bulletin says

Google published the September 2026 Android Security Bulletin on September 8. It describes a critical System issue with potential remote code execution and no required user interaction. Those are impact and prerequisite statements; the bulletin does not establish an observed attack campaign from them.

The bulletin uses two security patch levels: 2026-09-01 and 2026-09-05. Google says the September 5 level or a later level addresses all applicable issues in this bulletin. The September 1 level covers its own group of fixes and the required earlier fixes. Treat those dates as different claims about coverage.

Google’s September 2026 Android Security Bulletin

CVE-2026-28604: an object outlives its valid lifetime

Google’s September table lists CVE-2026-28604 as a critical System remote-code-execution issue and maps it to the adbd Mainline component. The public CVE record describes a race-related use-after-free. It states that exploitation does not require additional execution privileges or user interaction. The affected Android versions listed in that record are 14, 15, 16, 16-qpr2 and 17.

The public CVE record for CVE-2026-28604

Machine-readable CVE record published by Google

A race condition makes correctness depend on the coordination of activities that may overlap. In a use-after-free, code continues using an object after its lifetime has ended. Together, they describe a class of failure in which one activity releases an object another still expects to use. The public description does not give the exact sequence involved in this CVE.

MITRE’s explanation of synchronization failures, CWE-362

The record does not explain network reachability for every handset. “No user interaction” does not mean an arbitrary internet sender can reach the vulnerable component on every default device. Nor does a matching Android version establish the patch status of a particular manufacturer’s build.

Code execution still has a process context

Android uses process separation and application identities to isolate work. SELinux applies mandatory access-control policy to processes, including privileged ones. Google’s architecture documentation describes enforcing mode and default-deny behavior. Code execution within one component therefore needs to be distinguished from escaping its policy domain or obtaining unrestricted control of the device.

Android’s SELinux security model

Google’s severity assessment considers cases where platform protections are disabled or bypassed. That warrants attention without settling the outcome on every production phone. Isolation may limit what a compromised component can do, while the update repairs the component’s defect.

The Android version is only one part of the update record

The major version names the Android platform release. The security patch level represents a set of required corrections. Google Play system updates can deliver modular components; manufacturer updates cover applicable platform and vendor changes for the device. These are related delivery paths, but their labels cannot substitute for one another.

The adbd entry appears in both the vulnerability table and the Mainline mapping. That tells you something about component delivery. It does not mean one successful Play update covers every kernel, chipset and vendor issue in the bulletin. Check the manufacturer’s support information and record each relevant update state.

Keep the model, build, security patch level, Play system-update date and vendor availability statement together. A phone below the required coverage with no offered update still needs a support decision. The absence of an update button to press does not make the gap disappear.

Record the fields from the actual device

Google’s Android Help guide distinguishes the Android version, Android security update, Google Play system update and build number. It also explains that update schedules vary by device, manufacturer and carrier. A newer value in one field does not make it a substitute for every other field.

Google’s guide to checking and updating Android

For each work phone, record its model, owner, Android security update date, Play system-update date and the time checked. Use normal settings or your management platform. Menu names vary, so follow the manufacturer’s instructions for that model.

• Check the Android security update date after installation and any required restart.

• Check Google Play system updates separately where the device supports them.

• If the relevant manufacturer update is unavailable, record that limitation and a follow-up date. Keep it separate from an available update the user has simply postponed.

Publication does not mean the handset received the fix

Google’s bulletin overview distinguishes the publication of platform fixes from the work device manufacturers do to deliver updates. The release of a bulletin alone is therefore not evidence that a particular handset has received its update.

Google’s overview of Android security bulletins

The next action depends on why a phone is behind. A pending available update calls for installation. If the manufacturer has not supplied one for that model, somebody needs to confirm support status and decide what business access remains appropriate. Sending another update reminder will not resolve that second problem.

Decide what to do with unsupported or delayed devices

Two staff phones can run the same Android version while differing by months in security updates. Checking the patch dates exposes that difference without collecting personal messages or other unrelated information from either device.

Define who assesses an unresolved update gap, what access the device may retain and when replacement becomes necessary. Apply the decision through the normal management process, and provide an alternative for staff who depend on the phone for authentication.

The review should leave you with three clear groups: phones meeting the intended patch level, phones awaiting a vendor release and phones needing a support decision. Each unresolved device needs a next step.

Source check: September 8, 2026. This article is independent analysis of Google’s published Android security information.