Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A logical flaw in Secure Payment Confirmation (SPC) allows a potential attacker to include unshown payment logos in the cryptographically signed clientDataJSON payload. The browser attempts to cap the logo array size to two elements but uses a single-iterator std::vector::erase, which only removes one element. These extra elements are subsequently signed by the WebAuthn credential without ever being displayed to the user.

Affected files:

• components/payments/content/secure_payment_confirmation_app_factory.cc
• components/payments/content/secure_payment_confirmation_app.cc
• content/browser/webauth/client_data_json.cc
• chrome/browser/ui/views/payments/secure_payment_confirmation_dialog_view.cc
• components/payments/content/android/spc/java/src/org/chromium/components/payments/secure_payment_confirmation/SecurePaymentConfirmationViewBinder.java

Estimated timestamp from git blame: 2025-06-06

Root Cause

In SecurePaymentConfirmationAppFactory::Create, the browser attempts to restrict the renderer-supplied payment_entities_logos vector to a maximum of two entries. However, on lines 184–187, it incorrectly uses the single-iterator overload of std::vector::erase, which only deletes exactly one element instead of truncating all elements from that point onward:

// components/payments/content/secure_payment_confirmation_app_factory.cc:184-187
if (spc_request->payment_entities_logos.size() > 2) {
  spc_request->payment_entities_logos.erase(
      spc_request->payment_entities_logos.begin() + 2);
}

For an input vector of length $N \ge 4$ (e.g. [L0, L1, L2, L3]), this operation results in [L0, L1, L3], which retains $N - 1 = 3$ elements and completely preserves elements at index 3 and above. No other size validation boundaries or IDL array limits are enforced in the pipeline to restrict the array length.

Potential Vulnerability Mechanism

1. Triggering the Request: A page initiates an SPC payment flow via the PaymentRequest API containing four or more logos in paymentEntitiesLogos (e.g., [L0, L1, L2, L3]).
2. Defective Truncation: The request passes browser-side validation. The defective erase is executed, which erases only L2. This leaves a vector of size 3: [L0, L1, L3].
3. UI Rendering (Omission of Indices $\ge 2$):
   • Desktop UI (secure_payment_confirmation_dialog_view.cc): Explicitly renders only the logos at index 0 and index 1. Any logo at index 2 or higher is silently dropped from the display.
   • Android UI (SecurePaymentConfirmationViewBinder.java): Only displays the primary (index 0) and secondary (index 1) logos. Although there is an assertion assert (logos.size() == 2);, Java assertions compile out in release builds, enabling the execution to proceed silently.
4. Signing Path: After the user approves and completes authentication, all elements stored in payment_entities_logos_ (including the hidden logos at indices $\ge 2$) are mapped into ShownPaymentEntityLogo Mojom structures, serialized into the paymentEntitiesLogos array within the clientDataJSON block inside content/browser/webauth/client_data_json.cc, and cryptographically signed.

Potential Impact

This constitutes a potential direct violation of Secure Payment Confirmation’s What-You-See-Is-What-You-Sign (WYSIWYS) integrity guarantee. A malicious merchant could present the user with two benign logos while smuggling additional, arbitrary {url, label} pairs into the signed payment evidence. Since the verifying Relying Party relies on the signed clientDataJSON as browser-attested proof of what transaction details the user actually saw, they will be misled into believing the user consented to/saw logos and labels that were completely hidden from view.

Potential Reproduction Steps

1. On a web page with an enrolled SPC credential, execute the following script:

   const req = new PaymentRequest([{
     supportedMethods: 'secure-payment-confirmation',
     data: {
       rpId: 'rp.example',
       credentialIds: [knownId],
       challenge: new Uint8Array([1]),
       instrument: {displayName: 'Card', icon: 'https://rp.example/card.png'},
       payeeOrigin: 'https://merchant.example',
       paymentEntitiesLogos: [
         {url: 'https://a/benign1.png', label: 'Visa'},
         {url: 'https://a/benign2.png', label: 'Bank'},
         {url: 'https://a/x.png',       label: 'erased-by-bug'},
         {url: 'https://a/hidden.png',  label: 'HIDDEN-NOT-SHOWN'}
       ]
     }
   }], {total: {label: 'Total', amount: {currency: 'USD', value: '1.00'}}});
   
   const resp = await req.show();
   

2. Observe that the SPC confirmation dialog displays only ‘Visa’ and ‘Bank’.
3. Authenticate and complete the payment flow.
4. Decode the returned resp.details.response.clientDataJSON. Note that the paymentEntitiesLogos array contains three entries, including the HIDDEN-NOT-SHOWN logo (https://a/hidden.png), cryptographically signed as if it were displayed to the user.

(Note: Our tooling agent doesn’t yet have the ability to run code, and these reproduction steps are suggested/potential steps.)

Suggested Fix

Modify SecurePaymentConfirmationAppFactory::Create in components/payments/content/secure_payment_confirmation_app_factory.cc to use the range-based erase overload to remove all elements from index 2 to the end of the vector:

if (spc_request->payment_entities_logos.size() > 2) {
  spc_request->payment_entities_logos.erase(
      spc_request->payment_entities_logos.begin() + 2,
      spc_request->payment_entities_logos.end());
}

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.