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 Android selection popup controller fails to check the sticky HAS_BEEN_PASSWORD flag when evaluating if a text selection is in a password field. If a user toggles a password field’s visibility to plaintext and selects it, the plaintext credential is exposed to third-party ACTION_PROCESS_TEXT intent handlers. This bypasses Chrome’s security gate designed to keep sensitive credential selections isolated.

Affected files:

• content/browser/android/selection/selection_popup_controller.cc
• content/public/android/java/src/org/chromium/content/browser/selection/SelectionPopupControllerImpl.java
• content/public/android/java/src/org/chromium/content/browser/input/ImeAdapterImpl.java
• content/public/android/java/src/org/chromium/content/browser/selection/SelectActionMenuHelper.java

Estimated timestamp from git blame: 2015-09-25

Potential Vulnerability: Plaintext Password Exposure to Third-Party Android Handlers

Root Cause

The Android selection menu controller derives its password classification state solely from the active/current input element type, ignoring the sticky has-been-password flag (WebTextInputFlags.HAS_BEEN_PASSWORD_FIELD) propagated by Blink. Because of this, when a password field is revealed to plaintext (a common UX design pattern on login pages), both the native and Java layers of Chrome treat the field selection as ordinary text.

There are two main propagation sites where this occurs:

1. Native (selection_popup_controller.cc):

   const bool is_password_type =
       params.form_control_type == blink::mojom::FormControlType::kInputPassword;
   

   is_password_type evaluates to false when the input type changes to text.

2. Java (ImeAdapterImpl.java):

   boolean password = textInputType == TextInputType.PASSWORD; // mTextInputFlags is ignored here
   updateNodeAttributes(editable, password);
   

   password evaluates to false when the input type becomes TextInputType.TEXT.

Because the popup controller determines isSelectionPassword is false, it allows SelectActionMenuHelper.getTextProcessingItems() to query and show registered third-party ACTION_PROCESS_TEXT handlers in the selection popup menu. When the user taps one of these items, Chrome sends the raw selected plaintext password in the EXTRA_PROCESS_TEXT intent extra to the target third-party application.

Note: These are suggested/potential steps and analysis; our current tooling agent does not have the ability to run code or compile a working proof-of-concept.

Potential Trigger Steps

1. An Android device has a third-party application installed that declares an <intent-filter> for android.intent.action.PROCESS_TEXT with mimeType text/plain.
2. The user navigates to a login page containing a password field with a show/hide toggle in Chrome for Android.
3. The user types their credential, then taps the visibility toggle to show the plaintext password.
4. The user long-presses to select the revealed password text.
5. The custom selection menu appears, exposing third-party application options (which would otherwise be suppressed if the field were recognized as having been a password field).
6. The user taps the third-party application’s action. The external application receives the plaintext password via the ACTION_PROCESS_TEXT intent.

Suggested Fix

Update both the native and Java state-propagation logic to consult the sticky has-been-password bit:

• In ImeAdapterImpl.java:

  boolean password = textInputType == TextInputType.PASSWORD 
      || (mTextInputFlags & WebTextInputFlags.HAS_BEEN_PASSWORD_FIELD) != 0;
  

• In selection_popup_controller.cc, retrieve and consult the state of the active input’s has-been-password flag (which is already tracked in Blink) to correctly mark is_password_type as true if the field has ever been a password field.

Evaluated with Chrome root at commit: 9ebf4302210513a012c901d87a2668b3aadf8cc1

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.