The demo did not work for me when I had chrome://flags/#fill-on-account-select set to Enabled. I'll try again with it turned off in a moment.

And yes, the demo does work when I have Fill On Account Select turned off.

I think Medium is right given https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md#Medium-severity.

Thanks for the report.

I'm running bisect to check which change caused this. I recall we made a few changes regarding form action. I admit that I was not aware that the SOP should apply to the action.

In the meantime, I'd like to understand the impact better (especially interested in palmer@'s thoughts): IIUC,, while fill-on-account-select does not autofill the password, the user still can select the account and make Chrome fill the form, yes? And the user has no clue what the action is, because that is not visible until a peek into DevTools.

So how much security is gained by not filling the form automatically but allowing fill on demand?

So the change was https://chromium.googlesource.com/chromium/src/+/40f676517d2d8b840c41eb67a7f874a154e7f54a, about a year ago.

Assigning to Vasilii, who authored that change and provided reasons for it, which include support for Credential Manager API (and also a fix to a randomly related bug).

Let's see if we can clarify the security concern (my question in #4) and figure out how to address the result.

RE 4#: Good question. Maybe a warning Popup just like chrome://flags/#enable-http-form-warning is more secure.

However, if Password Manager apply SOP to the action URL, attackers will have to make XSS payload form visible to trick users into filling the form, that 
make the attack more difficult and users may be alert.

I don't understand what the bug is. You could create a form with the same action and then send the credentials to hacker.cn in the same function steal(), could not you?
If a page has an XSS bug then the password can be stolen. It has always been the case.

RE 7: I think you are partially correct. 

Just as your security blog said：

"Consider a scenario that occurred a few years ago on a popular social networking site that let users (or in this case, attackers) customize their profile pages. At the time, an attacker could not include JavaScript on his profile page, but could still use malicious HTML — a password field set to send data back to the attacker's web server. When users viewed the attacker's profile, their password managers would automatically fill in their passwords because the profile page was part of the same origin as the site's login page. Lacking JavaScript, the attacker could not read these passwords immediately, but once the users clicked on the page, their data was sent to the attacker's server. "

How was it sent automatically? If the attacker doesn't inject JS then the user should manually submit the password form.

Yeah, indeed not automatically. 
But attacker can make the XSS form's <input> tags invisible, and trick user to click a facke submit button. Users wouldn't know his credentials have been autofilled and then sent to attacker's server.

It seems I mis-triaged this bug. I apologize for that.

Given that XSS/control of origin A is a precondition, the attacker can exfiltrate the passwords by any means. Setting the form action to point to origin B is just 1 of many possibilities. The real bug is XSS.

The 10-year-old blog post does talk about the importance of where the browser sends the password. But really, the browser can't really distinguish legitimate cross-origin form submissions from XSS attacks, especially (but not only) in a case of dynamically-generated forms. Unfortunately, I don't think there is a mechanism that could reliably get that right.

That said, Fill On Account Select remains a decent mitigation for this and other problems, and I continue to believe it should be the default mode of operation.