CVE-2026-87501
Overview
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_FEATUREflag 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_FEATUREis on for users who have not overridden it, expressed asbase::FEATURE_ENABLED_BY_DEFAULTorbase::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.
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
- 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.
- Restriction is off by default
Because
kAutofillRestrictOtpToSameTldPlusOnedefaults tobase::FEATURE_DISABLED_BY_DEFAULTpre-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. - 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
(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 disabledGrep
autofill_features.ccand sibling*_features.ccfiles forFEATURE_DISABLED_BY_DEFAULTon 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/PasswordsAudit 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 invariantsWhere 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
From 55261892dbb055677a33cf33539055d225122615 Mon Sep 17 00:00:00 2001
From: Matthias Koerber <koerber@google.com>
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 <trangm@google.com>
Commit-Queue: Matthias Körber <koerber@google.com>
Auto-Submit: Matthias Körber <koerber@google.com>
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.
Original Bug Report
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.ccchrome/browser/password_manager/password_change_delegate_impl.cccomponents/autofill/core/common/autofill_features.ccchrome/browser/ui/passwords/manage_passwords_ui_controller.ccchrome/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:
- The Omnibox password/leak icon is hidden because
ManagePasswordsUIController::GetState()returnsINACTIVE_STATEwhile a delegate exists. - If the user navigates away or closes the tab,
PasswordChangeDelegateImpl::OnCrossOriginNavigationDetectedis 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
- Host a page at
https://victim.comthat embeds a cross-origin iframe fromhttps://attacker.com(e.g., via a malicious advertisement). - The attacker iframe contains a focusable input:
<input type="text" autocomplete="one-time-code">. - The user signs in to
https://victim.comusing a password known to be leaked. - 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.
- 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.