
CVE-2026-6765, Test only FormAutofill handlers exposed in Firefox
Reporter credited by Mozilla in MFSA 2026-30: Abdulaziz Alasaiqah. This directory holds a real reproduction harness for the vulnerability. It is meant to be run against a locally downloaded vulnerable Firefox build. It never touches any live or third party system.
Matching PoC repository: https://github.com/defineid/SkeletonKey
Writeup: writeup-ff-autofill.html in this portfolio.
| Field | Value | Source |
|---|
| CVE | CVE-2026-6765 | MITRE cvelistV5 (state PUBLISHED, CNA Mozilla) |
| Title | Information disclosure in the Form Autofill component | NVD · MFSA 2026-30 |
| Severity | Moderate · CVSS 5.3 · AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N | NVD |
| CWE | 359 · Exposure of Private Information | NVD |
| Fixed in | Firefox 150 · Firefox ESR 140.10 · Thunderbird 150 / 140.10 | MFSA 2026-30 |
| Bug | bugzilla.mozilla.org/show_bug.cgi?id=2022419 (security restricted) | NVD reference |
| Reporter | Abdulaziz Alasaiqah | MFSA 2026-30 |
The FormAutofill JSWindowActor pair (FormAutofillChild in content and
FormAutofillParent in the parent process) exchanges messages. In current
mozilla-central FormAutofillParent.receiveMessage gates anything outside the
allow set behind the automation check:
// toolkit/components/formautofill/FormAutofillParent.sys.mjs (fixed tree)
if (!FORM_AUTOFILL_MESSAGES.has(name) && !Cu.isInAutomation) {
return undefined;
}
The source comment states that the Save and Remove handlers are invoked only by tests:
FormAutofill:SaveAddressFormAutofill:SaveCreditCardFormAutofill:RemoveAddressesFormAutofill:RemoveCreditCardsOn the affected builds those test-only handlers were reachable without the
Cu.isInAutomation gate so a content context could reach FormAutofill paths
that were never meant to face web content. Mozilla rated the resulting exposure
as information disclosure of stored autofill data.
Note on reach: getActor lives on windowGlobalChild, a chrome only property.
Ordinary page script never sees it, so the threat model is a content process an
attacker already influences (a renderer compromise or a content side code path)
issuing the actor message, not a plain web page. The harness attempts the
content path and reports honestly whether the parent answered or the boundary
held.
The exact disclosure primitive lives in bug 2022419 which is security restricted. This harness demonstrates the reachability of a test-only handler that a fixed build blocks. Pass the precise call your own report used with
--message.
A content process that an attacker already influences (a renderer compromise or a content side code path) sends a FormAutofill actor message that should only ever come from the test harness. On a vulnerable build the parent answers. On a fixed build the automation gate drops it.
https://ftp.mozilla.org/pub/firefox/releases/140.9.0esr/.pip install marionette-driver
Start the vulnerable build with a fresh profile and Marionette enabled:
/path/to/firefox --marionette --no-remote --profile ./poc-profile about:blank
Then in about:preferences#privacy add one synthetic saved address and one
synthetic card, for example name POC TESTER, card number 4111 1111 1111 1111. This is test data only.
python3 poc.py # default handler and 127.0.0.1:2828
python3 poc.py --help # options
python3 poc.py --message FormAutofill:SaveAddress
getActor is chrome only, so from the content sandbox the plain harness reports
the actor as unreachable (see poc-run.png). To drive the message from a context
that actually holds the actor, on a vulnerable build enable the Browser
Toolbox (devtools.chrome.enabled and devtools.debugger.remote-enabled), open
it with Ctrl+Alt+Shift+I, and from the content-process console fetch the actor
off windowGlobalChild and call sendQuery with the same synthetic payload.
This mirrors the compromised-content-process threat model without any real data.
undefined because Cu.isInAutomation is false. The script reports that the
gate is enforced.This harness was authored from the public record and the current mozilla-central
source. It was executed here against the local Firefox 140.11.0esr build,
which is already patched for CVE-2026-6765. The captured run is in
poc-run.png: from the content context the FormAutofill actor is not reachable
(windowGlobalChild.getActor is not exposed to content), so the parent boundary
holds. That is the correct, honest outcome on a fixed build.
To observe the boundary being crossed you need a vulnerable build (Firefox
before 150 or ESR before 140.10, for example 140.9.0esr) plus a throwaway profile
seeded with synthetic autofill data, and you drive the actor message from a
content-process context per the browser-toolbox fallback above. Adjust
--message to the exact primitive from your original report.
This targets a locally downloaded build with synthetic data for a writeup of the author's own reported and already patched CVE. It does not attack any live or third party service.