Two GraphQL mutations, on two hosts, neither of them shown as a pair in the UI.
The first created an identity for any address that was not already a credentialed consumer, and returned the internal user id. The second, on the business portal, accepted that id, a password we chose, and a default invite code. Login with that password returned the MFA-next step. A wrong password returned unauthenticated. The inbox was not required.
Addresses that were already credentialed were rejected. The hole is the window before the real owner signs up, including mailboxes that existed only as stubs.
A sibling on the fleet portal distinguished provisioned internal mailboxes from absent ones, and exposed a 6-digit one-time code on the password-set mutation with no useful rate limit. We did not run that code against a real employee mailbox. MFA on the consumer path still fires. For a mailbox we own, we finish MFA and receive tokens. For a mailbox the victim owns, the password is ours and the victim receives the code.
What we proved
Three disposable mailboxes we controlled: create, set the password with the default invite code, login accepts that password and rejects a wrong one.
What this is not
Not a login to a named employee's car account. A broken registration and invite-code control, proven on identities we created.
Why a scanner misses it
The UI never offers that invite code. The two mutations live on two hosts. The field names were in the bundle, not in the docs.
Buyer takeaway: Provisional and invite flows are authentication. A default code is a password.
