[kah-ja]

What

The action extension fills a login form by writing the decrypted password to
both the value content attribute and the value IDL property
(passExtension/passProcessor.js:31 and :32, and the same pair for the user
name at :41 and :42). Only the property is read when the form is
submitted. The attribute is part of the serialised DOM, so after a fill the
page markup contains the plaintext password, and a CSS attribute selector can
match on it one character at a time.

Why

The value the extension hands over is the decrypted secret itself
(passExtension/Services/CredentialProvider.swift:48). Writing it to the
attribute adds nothing: element.value = ... sets what the browser submits and
what scripts read, which is why the next two lines dispatch input and
change on the element.

How

The two setAttribute('value', ...) calls are removed. The property
assignments and the event dispatch are unchanged, so the fill behaves the same
for the page and for any framework listening on those events.

Testing

The repository has no JavaScript test setup, so no test file was added.

The script was exercised under jsdom against a form with a text and a password
input. With the current script the serialised body contains
value="<password>" and an attribute selector matches it. With the change the
password is absent from the markup, input.value still carries it, both
input and change still fire on both elements, and the password field has no
value attribute at all.

The iOS test suite was not run, this host has no macOS toolchain.

References

GHSA-gxf7-ph6f-4fg6 (reported privately, unpublished at time of writing)

Found during a penetration test by turingpoint.