CVE-2026-28658 AI-generated analysis

platform/frameworks/base, services/core AccountManager (com.android.server.accounts.AccountsDb)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (3 corrections). Verify against the commit before relying on it.

AccountsDb.findMetaAuthUid now strips the fixed "auth_uid_for_type:" prefix from the meta_key by length instead of splitting on ":" and taking the second token, so authenticator types containing a colon are no longer truncated when the type-to-UID map is built.

Root cause

In services/core/java/com/android/server/accounts/AccountsDb.java, findMetaAuthUid builds a Map<String, Integer> of authenticator type to UID from meta table rows whose key is "auth_uid_for_type:<type>". The old code derived the type with TextUtils.split(metaCursor.getString(0), ":")[1], i.e. it tokenized the whole key on ":" and took only the second token. Any authenticator type that itself contains ":" was therefore truncated to the portion before its first colon, so the stored UID was recorded in the map under a different (shorter) type name than the one it was persisted for. The commit message states the entries are stored with the "auth_uid_for_type:" prefix and that the prefix must be removed properly.

How the fix works

• AccountsDb.java (class constants): the META_KEY_DELIMITER = ":" constant is removed and replaced with META_KEY_PREFIX_LEN = META_KEY_FOR_AUTHENTICATOR_UID_FOR_TYPE_PREFIX.length().
• AccountsDb.java:findMetaAuthUid: the loop now reads typeWithPrefix = metaCursor.getString(0) and computes type = typeWithPrefix.substring(META_KEY_PREFIX_LEN), so everything after the fixed prefix (including any embedded colons) is kept as the type. The existing TextUtils.isEmpty(type) || TextUtils.isEmpty(uidStr) check that follows is unchanged.

Completeness

• The fix covers the single parsing site in findMetaAuthUid; it is the only place in the diff that interpreted the meta_key.
• The new substring call assumes every row returned by the query starts with the full prefix; the material shows the selection is META_KEY LIKE ? but not the bound argument, so whether a shorter key could reach substring and throw StringIndexOutOfBoundsException is not visible.
• The writer side (how the key is composed when a UID is stored for a type) is not in the diff, so the fix relies on the stored format being exactly prefix + type as the commit message states.

Behavior changes

• Authenticator types containing ':' are now returned intact by findMetaAuthUid instead of being truncated at the first colon, so the type-to-UID map keys match the stored types.
• A key equal to just the prefix yields an empty type, which is then subject to the existing isEmpty check; no new error codes or API changes.

Per major

• Android 14: same fix: platform/frameworks/base 051431afaec5 in android-security-14.0.0_r29, identical diff (hunks at lines 177 and 1055).
• Android 15: same fix: platform/frameworks/base 38dbed092b9d in android-security-15.0.0_r17, identical diff and line offsets.
• Android 16: same fix: platform/frameworks/base 8c2ce8c567a2 in android-security-16.0.0_r8, identical diff and line offsets.
• Android 17: same fix: platform/frameworks/base 31e7981c9d23 in android-security-17.0.0_r1, identical content, hunks shifted to lines 173 and 1094.

Unknowns

• The callers of findMetaAuthUid and how the resulting type-to-UID map is consumed are not shown.
• The LIKE argument bound to SELECTION_META_BY_AUTHENTICATOR_TYPE and the code that writes the meta_key are not in the material.
• The concrete EoP consequence (which check used the truncated type) is not shown beyond the bulletin's High/EoP rating.
• How the old split behaved for a key consisting of only the prefix is not shown.

Back to September 2026 · Findings