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: The Automated Password Change (APC) verification step fails to restrict page content capture to same-site frames. This potentially allows cross-site iframes to inject content into the data sent to the AI verification model, leading to incorrect password store updates.

Affected files:

• chrome/browser/password_manager/password_change/password_change_submission_verifier.cc
• chrome/browser/password_manager/password_change_delegate_impl.cc

Estimated timestamp from git blame: 2025-05-14

Description

In Chrome’s Automated Password Change (APC) flow, the browser uses an AI model to verify whether a password change attempt on a website was successful. This verification occurs in the PasswordChangeSubmissionVerifier component, which captures page content and sends it to an Optimization Guide model for analysis.

A potential logic flaw exists in PasswordChangeSubmissionVerifier::GetAIPageContentOptions where it omits the include_same_site_only = true flag in the blink::mojom::AIPageContentOptions. This flag is correctly set in sibling components of the same flow (ChangePasswordFormFinder and ChangePasswordFormFillingSubmissionHelper), ensuring that cross-site iframe content is redacted from the capture.

Because this flag is missing during the verification step, content from all live cross-site out-of-process iframes (OOPIFs) is included in the DOM proto sent to the model. This could allow a third-party origin (such as an ad network or support widget) embedded on the target site’s post-submission page to influence the verification result through a ‘prompt-injection’ style attack.

Root Cause

The GetAIPageContentOptions() function in chrome/browser/password_manager/password_change/password_change_submission_verifier.cc does not set the include_same_site_only flag:

// chrome/browser/password_manager/password_change/password_change_submission_verifier.cc
blink::mojom::AIPageContentOptionsPtr GetAIPageContentOptions() {
  auto options = optimization_guide::ActionableAIPageContentOptions(
      /*on_critical_path =*/true);
  return options; // include_same_site_only remains false (default)
}

When this flag is false, the browser’s content extraction logic in components/optimization_guide/content/browser/page_content_proto_provider.cc bypasses origin-based redaction and collects content from all frames.

Potential Impact

An attacker controlling a cross-site iframe on a legitimate site’s settings or password-change confirmation page could render text such as “Your password has been changed successfully.” This could trick the AI model into returning a SUCCESSFUL_OUTCOME verdict even if the actual password change failed.

If a successful outcome is incorrectly returned:

1. Credential Corruption: The browser calls form_manager_->Save(), overwriting the user’s stored credential with a new generated password that was never actually accepted by the website.
2. UI Spoofing: The browser displays a trusted native notification (toast) claiming the password was successfully changed.
3. Security Exposure: The user’s original password remains valid on the site, but the user is misled into believing their account is secured with a new password. The password manager now holds an incorrect credential, potentially locking the user out.

Suggested Reproduction Steps (Potential)

1. Use a desktop Chrome instance with a saved credential for a site where APC is enabled.
2. The target site must have a post-change-password page that embeds a cross-site iframe.
3. Initiate the APC flow for the site.
4. Ensure the actual password change fails on the server side (e.g., via a simulated network error), but the resulting page still embeds an attacker-controlled iframe.
5. The attacker-controlled iframe renders text such as “Your password has been changed successfully.”
6. Observe (via internal logs or debugging) that PasswordChangeSubmissionVerifier captures this text and sends it to the AI model.
7. If the AI model returns SUCCESSFUL_OUTCOME, observe that the browser updates the password store and shows a success notification.

Recommended Fix

Update GetAIPageContentOptions() in chrome/browser/password_manager/password_change/password_change_submission_verifier.cc (and potentially chrome/browser/password_manager/password_change/login_state_checker.cc) to explicitly set options->include_same_site_only = true;. This ensures consistency with other components in the APC flow and prevents cross-origin interference.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

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.