PatchGap
Chrome · Payments › SPC

CVE-2026-95321

Spoofing in Payments (SPC)
Medium watch CVSS 5.4 chrome Spoofing 🔧 Commit mapped

Overview

Medium
Severity
5.4
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactUI misrepresentation in Payments
DescriptionUI misrepresentation in Payments
ComponentPayments
Sub-componentSPC
Bug ClassSpoofing
Action tierwatch — logic/policy bug — security-relevant, no memory-unsafety
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Tracker545879261
Fix commit56388ada0d24 (chromium/src) +9/-0
CWECWE-451
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
CISA KEVNot listed
Creditedjodyritonga
Reported2026-08-13 (per vendor advisory)
Fix landed2026-08-20 (public git)
Disclosed2026-09-22
Patch gap33 days — fix public in source before the advisory

Background

Secure Payment Confirmation (SPC)
a web payments mechanism where the browser displays a trusted, browser-controlled dialog showing the payment instrument the user is about to authenticate with WebAuthn.
Payment instrument display name
the user-facing label (and detail row) identifying a card or account, often including distinguishing suffixes such as the last four card digits.
`android:ellipsize`
an Android TextView attribute that controls how text exceeding the view’s bounds is truncated; end appends a trailing ellipsis to signal that content was cut off.
`android:maxLines`
an Android TextView attribute limiting the number of rendered lines, which silently clips overflow when no ellipsize behavior is set.

Root Cause Analysis

On Chrome Android, the SPC dialog rendered the payment instrument’s primary and secondary text rows from payments_instrument.xml using android:maxLines="1" without any android:ellipsize attribute. When a display name exceeded the available width, Android clipped the overflow at the view boundary with no visual indication, so trailing characters — including the distinguishing card-digit suffix — were silently dropped from the user’s view. This violated the invariant that the trusted payment UI must faithfully represent the instrument being authorized, allowing two instruments whose names differ only in a truncated suffix to appear identical.

The fix adds android:ellipsize="end" to both the primary and secondary TextView elements, matching Desktop behavior so that any truncation is now visibly marked with a trailing ellipsis. The accompanying SecurePaymentConfirmationViewBinderTest.java assertions confirm both views report TextUtils.TruncateAt.END, locking in the corrected rendering.

Key insight
The core mistake was pairing android:maxLines="1" with no android:ellipsize value, causing overflowing instrument names to be truncated invisibly; adding android:ellipsize="end" restores a visible cue so users can tell that the displayed name is incomplete.

Attack Path

  1. Craft a long instrument name An attacker or ambiguous data source arranges for a payment instrument whose display name or detail row is long enough to overflow the single-line TextView on a typical Android device width.
  2. Trigger the SPC dialog A payment flow invokes Secure Payment Confirmation, and Chrome renders the instrument rows from payments_instrument.xml with maxLines="1" and no ellipsize.
  3. Silent truncation hides the suffix Android clips the overflowing text with no trailing ellipsis, omitting distinguishing characters such as the card-digit suffix, so the visible name matches another, different instrument. (inferred)
  4. User authorizes under misapprehension Believing they are confirming the intended instrument, the user completes the WebAuthn authentication for a payment they did not intend to distinguish. (inferred)

Impact Assessment

An attacker gains UI misrepresentation within Chrome’s trusted Secure Payment Confirmation dialog on Android, where a truncated instrument name can be made visually indistinguishable from another, potentially misleading the user about what they are authorizing. This is confined to the browser UI/renderer surface of the Payments component and requires a display name long enough to overflow the single-line row on the user’s device. The advisory classifies this as UI misrepresentation in Payments (LogicError); no exploited-in-the-wild status is stated, and any escalation to actual fraudulent authorization beyond the display flaw is (inferred).

Files Changed

  • components/payments/content/android/minimal_java_res/layout/payments_instrument.xml
  • components/payments/content/android/spc/javatests/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinderTest.java

Audit Directions

  • maxLines without ellipsize
    Search Android layout XML for android:maxLines (especially ="1") on TextView elements in trusted or security-sensitive UI that lack a matching android:ellipsize, since these silently clip overflow.
  • Trusted UI parity across platforms
    Compare Desktop and Android renderings of security-critical dialogs (Payments, permissions, WebAuthn) for divergent truncation or formatting behavior that could hide distinguishing details.
  • Distinguishing-suffix omission
    Review UI that displays identifiers whose trailing portion carries the disambiguating information (card digits, account tails, hostnames) to ensure overflow never drops the discriminating suffix without a visible cue.

Patch

view commit
From 56388ada0d24833af302df56c319db7b6f6f5a6d Mon Sep 17 00:00:00 2001
From: Stephen McGruer <[email protected]>
Date: Thu, 20 Aug 2026 08:16:27 -0700
Subject: [PATCH] [SPC] Ellipsize payment instrument display name on overflow

Previously, on Chrome Android, the payment instrument display name and
details rows in Secure Payment Confirmation (SPC) had maxLines="1"
without an ellipsize attribute. As a result, long display names were
silently truncated without any visual indication (e.g. trailing
ellipsis), omitting distinguishing suffixes like card digits.

This CL adds android:ellipsize="end" to the primary and secondary text
views in payments_instrument.xml to match Desktop behavior and ensure
overflow is visibly indicated with an ellipsis.

Bug: 545879261
Test: components_junit_tests -f "*SecurePaymentConfirmation*"
Change-Id: I21488659e5c410508b243d45e67d6849e4642354
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8272448
Commit-Queue: Stephen McGruer <[email protected]>
Reviewed-by: Darwin Yang <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1683170}
---
diff --git a/components/payments/content/android/minimal_java_res/layout/payments_instrument.xml b/components/payments/content/android/minimal_java_res/layout/payments_instrument.xml
index fb211521..337aa72 100644
--- a/components/payments/content/android/minimal_java_res/layout/payments_instrument.xml
+++ b/components/payments/content/android/minimal_java_res/layout/payments_instrument.xml
@@ -32,6 +32,7 @@
             android:layout_width="wrap_content"
             android:layout_height="wrap_content"
             android:maxLines="1"
+            android:ellipsize="end"
             android:includeFontPadding="false"
             android:textAppearance="@style/TextAppearance.TextMedium.Primary" />
         <TextView
@@ -39,6 +40,7 @@
             android:layout_width="wrap_content"
             android:layout_height="wrap_content"
             android:maxLines="1"
+            android:ellipsize="end"
             android:includeFontPadding="false"
             android:textAppearance="@style/TextAppearance.TextMedium.Primary"
             android:visibility="gone"/>
diff --git a/components/payments/content/android/spc/javatests/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinderTest.java b/components/payments/content/android/spc/javatests/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinderTest.java
index 3a90a17f..10ab93f 100644
--- a/components/payments/content/android/spc/javatests/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinderTest.java
+++ b/components/payments/content/android/spc/javatests/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinderTest.java
@@ -15,6 +15,7 @@
 import android.graphics.Color;
 import android.graphics.drawable.BitmapDrawable;
 import android.text.SpannableString;
+import android.text.TextUtils;
 import android.view.View;
 import android.widget.ImageView;
 import android.widget.TextView;
@@ -259,9 +260,15 @@
         assertSame(icon, ((ImageView) itemView.findViewById(R.id.icon)).getDrawable());
         assertEquals(iconLabel, itemView.findViewById(R.id.icon).getContentDescription());
         assertEquals(primaryText, ((TextView) itemView.findViewById(R.id.primary_text)).getText());
+        assertEquals(
+                TextUtils.TruncateAt.END,
+                ((TextView) itemView.findViewById(R.id.primary_text)).getEllipsize());
         assertEquals(View.VISIBLE, itemView.findViewById(R.id.secondary_text).getVisibility());
         assertEquals(
                 secondaryText, ((TextView) itemView.findViewById(R.id.secondary_text)).getText());
+        assertEquals(
+                TextUtils.TruncateAt.END,
+                ((TextView) itemView.findViewById(R.id.secondary_text)).getEllipsize());
     }
 
     @Test
Loading diff…

Original Bug Report

The reporter's bug is still restricted on the tracker. Chrome de-restricts security bugs ~30–90 days after the fix ships; a later run will backfill it here.
On This Page