PatchGap
Chrome · Passwords

CVE-2026-87501

Spoofing in Passwords
Medium watch CVSS 5.4 chrome Spoofing 📄 Reporter bug report 🔧 Commit mapped 🧬 A robustness or init safeguard the rest of the code assumes is on is silently off

Overview

Medium
Severity
5.4
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactUI misrepresentation in Passwords
DescriptionUI misrepresentation in Passwords
ComponentPasswords
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.
Tracker513509804
Fix commit55261892dbb0 (chromium/src) +1/-1
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
CreditedGoogle
Reported2026-05-15 (per vendor advisory)
Fix landed2026-08-06 (public git)
Disclosed2026-09-08
Patch gap33 days — fix public in source before the advisory

Background

OTP field detection
Autofill’s logic that identifies one-time-password input fields on a page so it can offer or fill OTP values, referenced in the diff’s comment as “OTP fields detection and fetching.”
TLD+1 (eTLD+1)
The registrable domain (effective top-level domain plus one label, e.g. example.com); comparing a subframe’s TLD+1 to the main frame’s TLD+1 distinguishes same-site frames from cross-site third-party frames.
`kAutofillRestrictOtpToSameTldPlusOne`
The BASE_FEATURE flag whose comment states it “Restricts OTP fields detection and fetching to forms that are in a frame with the same TLD+1 as the main frame.”
Feature default state
Whether a Chromium BASE_FEATURE is on for users who have not overridden it, expressed as base::FEATURE_ENABLED_BY_DEFAULT or base::FEATURE_DISABLED_BY_DEFAULT.

Root Cause Analysis

The diff changes exactly one thing: the default state of kAutofillRestrictOtpToSameTldPlusOne is flipped from base::FEATURE_DISABLED_BY_DEFAULT to base::FEATURE_ENABLED_BY_DEFAULT in autofill_features.cc. The removed line shows that, pre-patch, the restriction described by the feature’s own comment — confining OTP detection and fetching to frames whose TLD+1 matches the main frame — was off for default users, so OTP handling was not gated on the subframe’s TLD+1 matching the main frame. Because the guarding condition defaulted off, OTP fields hosted in a cross-TLD+1 (third-party) frame were treated the same as first-party OTP fields, which (per the advisory’s “UI misrepresentation in Passwords” classification) let a cross-site frame participate in the OTP autofill surface it should not have been trusted for.

The fix works purely by making the same-TLD+1 restriction the default, so the existing TLD+1 comparison now runs for ordinary users and cross-site frames are excluded from OTP detection and fetching.

The patch does not add, remove, or alter any check mechanism itself — the comparison logic already existed and is unchanged; only its default enablement moved. (inferred) The concrete misrepresentation (e.g. an OTP prompt appearing to belong to the top-level site while a third-party frame is present) is implied by the advisory class and the feature’s comment, not demonstrated by the diff.

Key insight
The single mistake was shipping a security-relevant same-origin-style restriction (kAutofillRestrictOtpToSameTldPlusOne) as opt-in rather than default-on, leaving OTP detection cross-frame-permissive for default users; the fix is the one-token change of the feature’s default to base::FEATURE_ENABLED_BY_DEFAULT.

Attack Path

  1. Embed a cross-site frame An attacker page (or a page under attacker influence) includes a subframe whose TLD+1 differs from the main frame’s TLD+1, hosting an OTP-style input field.
  2. Restriction is off by default Because kAutofillRestrictOtpToSameTldPlusOne defaults to base::FEATURE_DISABLED_BY_DEFAULT pre-patch, the TLD+1 match is not enforced, so Autofill performs OTP field detection and fetching for that cross-TLD+1 frame as if it were same-site.
  3. User is misled about OTP context (inferred) The OTP autofill surface is presented in a way that misrepresents which site/frame the OTP is associated with, consistent with the advisory’s “UI misrepresentation in Passwords” / spoofing classification; the specific UI element and the OTP disclosure it enables are not shown by the diff.

Impact Assessment

An attacker gains a UI-misrepresentation / spoofing primitive in the Passwords/Autofill surface of the browser (renderer-facing UI context), whereby OTP field detection and fetching operate for a cross-TLD+1 frame that should have been excluded, enabling misleading presentation of OTP autofill. (inferred) Any escalation beyond misrepresentation (such as an OTP value reaching an attacker-controlled third-party frame) is not demonstrated by the diff. The vendor advisory rates this medium severity and does not report in-the-wild exploitation; NVD scores it CVSS 5.4. The advisory states no exploited-in-the-wild status or severity rating beyond the “Spoofing” bug class and “UI misrepresentation in Passwords” impact.

Files Changed

  • components/autofill/core/common/autofill_features.cc

Audit Directions

  • Security-relevant features defaulting to disabled
    Grep autofill_features.cc and sibling *_features.cc files for FEATURE_DISABLED_BY_DEFAULT on flags whose comments describe an origin/TLD/frame restriction; a mitigation shipped opt-in leaves default users exposed until it is flipped.
  • Cross-frame trust in Autofill/Passwords
    Audit OTP, password, and credential detection/fetching paths for places that operate on subframes without comparing the subframe’s TLD+1 (or origin) to the main frame, since the underlying comparison is only as effective as the flag that enables it.
  • Flag-gated invariants
    Where a security invariant (same-site, same-TLD+1, same-origin) is enforced only behind a runtime feature check, verify the feature’s default matches the intended security posture and that no code path bypasses the flag.

Patch

view commit
From 55261892dbb055677a33cf33539055d225122615 Mon Sep 17 00:00:00 2001
From: Matthias Koerber <[email protected]>
Date: Thu, 06 Aug 2026 03:05:32 -0700
Subject: [PATCH] Enable TldP1 matching for OTP by default

Fixed: 498725213, 513509804
Change-Id: Icf51e64aa7c3530bb76b788230c4c86519cb1799
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8213739
Reviewed-by: Trang Mai <[email protected]>
Commit-Queue: Matthias Körber <[email protected]>
Auto-Submit: Matthias Körber <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1674835}
---
diff --git a/components/autofill/core/common/autofill_features.cc b/components/autofill/core/common/autofill_features.cc
index 8fadce2..1680643 100644
--- a/components/autofill/core/common/autofill_features.cc
+++ b/components/autofill/core/common/autofill_features.cc
@@ -868,7 +868,7 @@
 // Restricts OTP fields detection and fetching to forms that are in a frame
 // with the same TLD+1 as the main frame.
 BASE_FEATURE(kAutofillRestrictOtpToSameTldPlusOne,
-             base::FEATURE_DISABLED_BY_DEFAULT);
+             base::FEATURE_ENABLED_BY_DEFAULT);
 
 // TODO(crbug.com/435646513) - Clean-up after feature lands at 100% Stable.
 // Enables the new experimental server-side signatures for evaluation purposes.
Loading diff…

Original Bug Report

reported by [email protected]

Potential suppression of credential leak warnings via cross-origin iframes

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 logic flaw in the OtpFieldDetector component allows cross-origin iframes to incorrectly signal the presence of a one-time password (OTP) flow for the main frame. This can be used to silently defer and ultimately suppress Chrome’s compromised-password warnings and Automated Password Change (APC) offers.

Affected files:

  • components/autofill/core/browser/integrators/one_time_tokens/otp_field_detector.cc
  • chrome/browser/password_manager/password_change_delegate_impl.cc
  • components/autofill/core/common/autofill_features.cc
  • chrome/browser/ui/passwords/manage_passwords_ui_controller.cc
  • chrome/browser/password_manager/chrome_password_change_service.cc

Estimated timestamp from git blame: 2025-09-15

Summary

A potential vulnerability exists in Chrome’s Password Manager where a third-party, cross-origin iframe can prevent Chrome from displaying critical security notifications regarding leaked credentials. This occurs because the OtpFieldDetector incorrectly aggregates OTP field detection across all frames in a tab without verifying that the fields belong to the same origin as the main frame.

Technical Details

When Chrome detects that a user has signed in using a leaked password, ManagePasswordsUIController::OnCredentialLeak is triggered. If the site supports Automated Password Change (APC), Chrome initiates an APC flow via PasswordChangeDelegateImpl instead of showing a standard leak dialog.

In chrome/browser/password_manager/password_change_delegate_impl.cc, the delegate checks autofill::OtpFieldDetector::IsOtpFieldPresent() to determine if the user is currently in a multi-step login process (e.g., waiting to enter a 2FA code). If an OTP field is detected, the delegate defers showing the APC offer UI to avoid interrupting the login.

However, the OtpFieldDetector (in components/autofill/core/browser/integrators/one_time_tokens/otp_field_detector.cc) incorrectly considers focusable OTP fields in all frames. Due to the kAutofillRestrictOtpToSameTldPlusOne feature being disabled by default, no origin check is performed. An attacker-controlled iframe can simply include an <input autocomplete="one-time-code"> to trigger this state.

While the UI is deferred:

  1. The Omnibox password/leak icon is hidden because ManagePasswordsUIController::GetState() returns INACTIVE_STATE while a delegate exists.
  2. If the user navigates away or closes the tab, PasswordChangeDelegateImpl::OnCrossOriginNavigationDetected is called, which terminates the flow silently if no UI was ever displayed.

As a result, a user may never be informed that their credentials have been compromised.

Potential Reproduction Steps

  1. Host a page at https://victim.com that embeds a cross-origin iframe from https://attacker.com (e.g., via a malicious advertisement).
  2. The attacker iframe contains a focusable input: <input type="text" autocomplete="one-time-code">.
  3. The user signs in to https://victim.com using a password known to be leaked.
  4. Observe that Chrome initiates the APC flow internally but suppresses all UI (no dialog, no omnibox icon) due to the detected OTP field in the iframe.
  5. The user navigates to a new site; the APC flow terminates, and no leak warning is ever shown.

Suggested Fix

Enable the kAutofillRestrictOtpToSameTldPlusOne feature by default, or modify OtpFieldDetector::IsOtpForm to always verify that detected OTP fields are same-origin (or same-site) with the main frame’s origin before signaling their presence to the Password Manager.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.

View on issue tracker
Links in the report
On This Page