[treve]

Depends. Many applications will have their login screens on simple server-generated HTML forms without heaps of Javascript, rendered by a service with higher security standards.

If an XSS vulnerability appears on some other page, it may not be the same page that normally has a login form.

Generally I'd say the gates are kinda open if XSS is possible, but many real exploits do require more than 1 vulnerability working together; so defense in depth applies.

[deathanatos]

So the attacker uses the XSS to change the "Login" link to not send you to the secure page, but rather to do a History.pushState with the same URL as the "secure" page, mimics the secure page, and exfils the credentials.

The OP is on the other side of the airtight hatch already.

(This does require said login page to be on the same origin. But even if the attacker just ignores that, and otherwise mimics the page as closely as possible, would you notice? Heck, even if you moved it to just being in the same page without the URL change, as long as the branding was close enough, I bet most folks would go "uh, the UI changed again" not "uh oh! it's not on a secure subdomain!". Let's hope your password manager notices. But even then, I suspect that most of them would just not autofill, and a confused user would manually fill, wondering what happened.)