CVE-2026-28600 AI-generated analysis

platform/packages/apps/Settings, NFC payment default dialog (src/com/android/settings/nfc/PaymentDefaultDialog.java)

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 (4 corrections). Verify against the commit before relying on it.

PaymentDefaultDialog.onCreate no longer reads a UserHandle from the Intent.EXTRA_USER extra; the user id passed to buildDialog is now always UserHandle.myUserId().

Root cause

PaymentDefaultDialog.onCreate took a UserHandle from the launching intent's Intent.EXTRA_USER extra. When one was present, it passed userHandle.getIdentifier() as the userId to buildDialog(component, category, userId). onCreate did not check that this user matched the user running the dialog. onClick(BUTTON_POSITIVE) calls mBackend.setDefaultPaymentApp(mNewDefault.componentName, mNewDefault.userId); mNewDefault is presumably filled in buildDialog from that userId, but the material does not show this.

How the fix works

• src/com/android/settings/nfc/PaymentDefaultDialog.java:onCreate: the fix deletes the getParcelableExtra(Intent.EXTRA_USER) read and the null-check branch that chose between UserHandle.myUserId() and userHandle.getIdentifier(). userId is now always set to UserHandle.myUserId().
• As a result, buildDialog(component, category, userId) always gets the user the Settings activity runs in. The intent can no longer choose the user id at this point.
• The commit title says dialog building logic is removed from onCreate. The actual diff keeps buildDialog() in onCreate and only removes the EXTRA_USER handling. EXTRA_SERVICE_COMPONENT and EXTRA_CATEGORY are still read from the intent.

Completeness

• The fix covers the place in onCreate where the user id supplied by the intent entered the flow. Whether mNewDefault.userId (used in onClick) always comes from this value depends on buildDialog code that the material does not show.
• Component (EXTRA_SERVICE_COMPONENT) and category (EXTRA_CATEGORY) are still taken from the intent. The shown context does not reveal how buildDialog validates them beyond the null check.
• The diff does not change the activity declaration or PaymentBackend.setDefaultPaymentApp itself. The fix is purely in the dialog's input handling.

Behavior changes

• Intent.EXTRA_USER passed to PaymentDefaultDialog is now ignored. Any caller that relied on it to target a different user (for example a profile) will now target the user running Settings.
• No new error paths in onCreate. The dialog is built as before, with the user id fixed to UserHandle.myUserId().

Per major

• Android 14: Not affected: the bulletin does not list Android 14.
• Android 15: Same fix: commit 1d0237d77a38 in android-security-15.0.0_r17 (cherry-pick of c2f680bf6093, Change-Id I9224a3aec3ecb2c8bbf3fe3ee966afaf782cb9c4).
• Android 16: Same fix: commit bf85ca6c87fc in android-security-16.0.0_r8. Identical diff against the same file blob (d333b3da6ac -> d556b6df929).
• Android 17: Same fix: commit d1db7e8d9994 in android-security-17.0.0_r1. Identical diff against the same file blob.

Unknowns

• How PaymentDefaultDialog is declared in the Settings manifest (exported state, intent filter, permission), and which system component normally launches it.
• How buildDialog fills mNewDefault, and what validation buildDialog and PaymentBackend.setDefaultPaymentApp apply to the component, category and userId beyond the null check visible in the context.
• Why the commit title refers to removing dialog building logic when the diff only removes the EXTRA_USER handling; whether a related change exists elsewhere is not shown.
• What causes the NullPointerException in the PaymentBackend constructor.

Back to September 2026 · Findings