Report description

Android Autofill prefill session reuse maps authenticated victim credentials into cross-origin iframe fields

Bug location

Where do you want to report your vulnerability?

Chrome VRP – Report security issues affecting the Chrome browser. See program rules

The problem

Please describe the technical details of the vulnerability

Summary

Chrome Android reuses a cached platform-Autofill prefill session after a frame-transcending login form changes field order. The similarity decision compares only the password parser’s selected username/password FieldGlobalIds; Android virtual IDs encode only the reused Chrome session and the field’s numeric position. If a cross-origin child frame inserts two fields before the unchanged victim login fields after prefill, authenticated values returned for cached positions 0 and 1 are resolved against the new positions and filled into the attacker frame.

Official Google Chrome Stable 152.0.7977.75 reproduced the full ordinary-web path on Android 15.

Bisect

• Range: 1249369 → 1249370 — https://chromium.googlesource.com/chromium/src/+log/152cc8489821e33424b31439e17f95c0ab57693a..b7240deab66b4bb9170fdcfe72ccbbed8509f983
• Introduced by: https://chromium.googlesource.com/chromium/src/+/b7240deab66b4bb9170fdcfe72ccbbed8509f983 — “Use PWM::FormDataParser predictions to perform similarity check.”
• Landed on: M122.0.6259.0

The introducing diff replaced whole-form similarity with a decision that the two forms are similar when the parser-selected username/password fields are identical. Commit 50840faf96313b10a76eafb23390833dab166fe0 later removed the experiment guard after that branch had been used in production.

Affected versions and validation

• Independent runtime: official Google Chrome Stable 152.0.7977.75 (com.android.chrome, versionCode 797707504), signed by Google’s Android release certificate, on Android 15 / API 35 build AE3A.240806.019.
• Runtime-matched Stable source: Chromium 152.0.7977.75, revision 8733d5f725f6d261c6023b73b466e81e84fda941, contains the complete chain.
• Current Android Stable source: Chrome 154.0.8037.21, revision 0fa6d91e2faf313da8332688a96bd98b9d983a4d, still contains the same parser-override comparison, cached session-ID reuse, and positional lookup.
• Current main source: Chromium 155.0.8053.0, revision 0a4b6ddf05517df35bc87e279bce4d4c9a545e9a, also contains the complete vulnerable chain.
• Platforms: Chrome Android using the user-enabled Android platform Autofill service on Android 14 or Android 15. Chrome’s built-in password manager and Android 16 are not claimed.

The end-to-end validation used a disposable Android profile, normal public HTTPS, the supported Chrome setting Autofill using another service.

Security boundary and prerequisites

The protected asset is the credential dataset selected for a victim-origin login form. The attacker controls ordinary JavaScript in a cross-origin iframe embedded before the victim’s username/password fields. The victim page has delegated the autofill permission to that child frame, but that delegation does not authorize delivery of the victim form’s credential dataset into the child origin.

The prerequisites are:

• the top-level login form contains a cross-origin iframe before its credential controls and delegates autofill to the frame;
• Chrome receives normal login-form predictions and prefetches the Android platform-Autofill response;
• the attacker inserts two non-login text fields only after that prefill;
• the user focuses the first attacker field and selects the cached Autofill suggestion; and
• a selected Android Autofill provider returns the dataset after its normal authentication step.

The supplied provider is an ordinary Android AutofillService. It does not patch, drive, or substitute for Chrome, and nothing in the chain depends on how it is implemented: it receives the standard prefill request, returns a standard Dataset, and the platform applies that dataset by virtual id. Any conforming third-party provider reaches the same sink, because the defect is Chrome’s reuse of a cached prefill session across a changed field vector rather than any provider behaviour. A dedicated provider is used only so the filled value is a fresh synthetic UUID rather than a real credential.

The supplied provider returns that UUID only after an explicit authentication button, so no real credential is placed at risk. The claim is limited to confidentiality: no account action, credential modification, integrity loss, or availability impact is claimed.

Source chain / root cause

All line-numbered citations below were verified against unmodified files in Chromium revision 34a482b3cd98d6d599f43091babae366fb9c3d8e. The same named constructs were separately verified in current Stable revision 0fa6d91e2faf313da8332688a96bd98b9d983a4d and current main revision 0a4b6ddf05517df35bc87e279bce4d4c9a545e9a.

1. components/autofill/core/browser/foundations/form_forest.h:79-87 defines the attacker-controllable positional order of a frame-transcending form:

   > “fields are stored as children of their root forms. The fields are > ordered according to pre-order depth-first (DOM order) traversal”

2. components/android_autofill/browser/android_autofill_provider.cc:263-281 treats the changed form as similar by comparing only parser-selected credential identities:

   PasswordParserOverrides overrides =
       PasswordParserOverrides::FromLoginForm(*pw_form, *form_structure)
           .value_or(PasswordParserOverrides());
   return cached_data_->password_parser_overrides == overrides;
   

   components/android_autofill/browser/android_autofill_provider.cc:292-310 then assigns the changed current form the cached session ID:

   const bool use_cached_form =
       is_similar_to_cached_form && !has_used_cached_form_;
   session_state_->form = std::make_unique<FormDataAndroid>(
       form, use_cached_form ? cached_form->session_id() : CreateSessionId());
   

3. components/android_autofill/browser/java/src/org/chromium/components/autofill/FormData.java:61-79 assigns virtual children in current vector order, and FormData.java:148-150 encodes only session and position:

   int virtualId = toFieldVirtualId(mSessionId, fieldIndex++);
   child.setAutofillId(assumeNonNull(structure.getAutofillId()), virtualId);
   ...
   return (sessionId << 16) | index;
   

   The attached runtime log shows this arithmetic directly. The prefill request carried id=0:i65536 and id=0:i65537, which are exactly toFieldVirtualId(1, 0) and toFieldVirtualId(1, 1): session 1, positions 0 and 1. The dataset is therefore addressed to positions, not to the fields it was built from, and nothing in the cached identifiers records which document owned position 0 at prefill time.

4. components/android_autofill/browser/java/src/org/chromium/components/autofill/AutofillProvider.java:366-381 permits the cached bottom sheet when only the cached/current session IDs match:

   if (mPrefillRequest == null
           || mPrefillRequest.getForm().mSessionId != mRequest.getForm().mSessionId) {
       return false;
   }
   boolean bottomSheetShown = showAutofillDialog(mContainerView, focus);
   

5. components/android_autofill/browser/java/src/org/chromium/components/autofill/AutofillRequest.java:68-92 accepts the returned numeric index and writes the value into the current field at that position; AutofillRequest.java:148-153 extracts only the packed session and index:

   if (toSessionId(id) != mFormData.mSessionId) continue;
   short index = toIndex(id);
   FormFieldData field = mFormData.mFields.get(index);
   field.setAutofillValue((String) value.getTextValue());
   

6. components/android_autofill/browser/android_autofill_provider.cc:401-412 reads the Java-backed current form, and components/android_autofill/browser/android_autofill_manager.cc:237-263 forwards its filled current fields. Finally, components/autofill/core/browser/foundations/autofill_driver_router.cc:610-628 routes those already-remapped fields to their owning frame:

   if (IsSafeToFill(field, field_type_map.at(field.global_id()),
                    main_origin, triggered_origin)) {
     fields_of_driver[target].emplace_back(field);
   }
   

The downstream origin check therefore sees current attacker fields and the attacker trigger origin. It cannot recover that the returned values were authorized for cached victim fields at the same numeric positions.

Steps to reproduce

1. Publish poc_victim.html and poc_attacker.html on the two HTTPS origins specified in repro.txt, or use the already deployed URLs. Use Android 14 or Android 15 with a disposable profile in official Chrome Stable.

2. Install poc_autofill_witness.apk, select VRP Autofill Witness in Android’s Autofill settings, then select Autofill using another service in Chrome and accept Chrome’s requested restart.

3. Start the provider-only log command from repro.txt. Open the exact victim URL and do not focus any field until the provider prints:

   PREFILL_CAPTURED flags=80 ids=2
   

   The preceding lines identify position 0 as victim login and position 1 as victim password, both under victim.example.

4. Click Insert attacker fields after PREFILL_CAPTURED inside the framed attacker page. Focus Attacker B0 and select Authenticate fresh victim credential from the Android Autofill suggestion.

5. Press AUTHENTICATE AND RELEASE FRESH CREDENTIAL. Compare the complete AUTHENTICATED_FRESH_VALUE log value with the red ATTACKER_READBACK block. Confirm that both victim fields remain empty.

6. For the negative control, reopen the exact victim URL and wait for a new prefill marker. Do not insert attacker fields. Focus the victim username, select the dataset, and authenticate. The value fills the victim fields and the attacker frame remains ATTACKER_EMPTY.

7. Run the cleanup commands in repro.txt to destroy Autofill sessions, uninstall the synthetic provider, and clear the disposable Chrome profile.

Actual result

The prefill contained only the victim-origin fields:

field[0] ... domain=victim.example htmlType=text htmlName=login
field[1] ... domain=victim.example htmlType=password htmlName=password
PREFILL_CAPTURED flags=80 ids=2

After attacker fields were inserted and B0 was focused, authentication generated this fresh value:

AUTHENTICATED_FRESH_VALUE=VRP_PREFILL_FRESH_33eb6022-adb1-4e56-9b23-37be61bdf3a5

Attacker JavaScript read the same value from both attacker-origin fields:

ATTACKER_READBACK
b0=VRP_PREFILL_FRESH_33eb6022-adb1-4e56-9b23-37be61bdf3a5
b1=VRP_PREFILL_FRESH_33eb6022-adb1-4e56-9b23-37be61bdf3a5

The victim username and password fields remained empty. In the negative control, the authenticated fresh value filled the victim fields and the attacker frame remained ATTACKER_EMPTY.

Expected result

Chrome should invalidate the cached prefill session whenever the current flattened field vector no longer has the same field identities, order, and origins as the prefilled vector. A dataset authorized for the victim login fields must never be resolved against newly inserted cross-origin fields that occupy the old numeric positions.

Suggested fix

Require whole-form structural similarity in addition to matching password-parser overrides before reusing the cached prefill session. At minimum, field count, order, FieldGlobalId, and origin at every virtual position must remain stable; otherwise Chrome should discard the cached response and create a new local session ID. A stronger defense would bind each Android virtual ID to a stable field identity or form-version digest rather than to a reusable numeric index alone.

fix_require_structural_form_similarity.patch implements the minimal guard by requiring FormDataAndroid::SimilarFormAs(form) before the parser-override comparison. It applies cleanly to the cited current source. The touched code is browser-process Android Autofill code; no renderer or multi-process PoC code is added.

Attachments

Impact analysis

Impact

• A cross-origin iframe can receive a victim login form’s authenticated Android Autofill dataset after shifting attacker-controlled fields into cached numeric positions.
• Attacker JavaScript can read the fresh credential values directly from its own fields; the demonstrated UUID was never present before authentication.
• The platform authentication step does not prevent disclosure because the identity loss occurs when Chrome resolves returned cached IDs against the changed current field vector.
• Scope is limited to Android 14/15, user-enabled Android platform Autofill, the stated embedding/delegation layout, normal prefill prediction, and user selection of the presented dataset.

The cause

What version of Chrome have you found the security issue in?

152.0.7977.75 + stable

Is the security issue related to a crash?

No, it is not related to a crash.

Choose the type of vulnerability

Sensitive data exposure

How would you like to be publicly acknowledged for your report?

Anonymous