The disclosure doing the rounds this month is GitLab's CVE-2023-7028, patched in their January security release: a flaw where password-reset emails could be delivered to an unverified, attacker-controlled address. Zero-click account takeover, rated critical, and grim for anyone who hadn't enforced two-factor across the board. The thing that's stuck with me isn't the severity. It's how boring the bug is.
Password reset is the part of authentication everybody writes and nobody respects. The login form gets the security review. The reset flow gets bolted on later by whoever drew the short straw, and it is, functionally, a second login that bypasses the password entirely. You prove you control an email address and the system hands you the account. So every assumption about which email address gets the reset link is a security boundary, and it's a boundary that lives in a feature most teams treat as plumbing.
Why this class of bug keeps happening
The reset email is the credential. Once you internalise that, the failure modes line up. If the form accepts a list of addresses and sends to all of them, one of them being yours is enough. If the address can be supplied rather than looked up from the verified account, you supply your own. If verification is checked in one code path and skipped in another, you find the other one. None of this requires breaking cryptography or a clever memory-corruption chain. It requires the application to trust an input it shouldn't, in a corner of the codebase that doesn't get the attention the front door does.
I've reviewed enough of these flows to have a checklist, and it's short. The reset link goes only to the address already verified on the account, full stop. The token is single-use, short-lived, and tied to that specific account. The form's response is identical whether or not the account exists, so it isn't a free user-enumeration oracle. And the whole thing assumes nothing about the request that an attacker can't also assert. The GitLab bug, from the public description, comes down to the first item: the link could reach an address the user supplied rather than the one the account had on file.
What I actually did about it
Two things, beyond the obvious "patch the self-hosted instance, which I'd already automated". First, I went and read my own password-reset code, the one in a side project I'd half-forgotten, with the specific question "can the recipient address be influenced by the request?" The answer was no, but I'm glad I checked rather than assumed, because past-me is not a developer I fully trust.
Second, and this is the bit I'd push on anyone reading: 2FA is what turns this class of bug from a catastrophe into a near miss. The GitLab advisory is clear that accounts with two-factor enabled were materially better off, because the stolen reset still hit a second wall. A password-reset takeover is, ultimately, a single-factor failure. If the password is the only thing standing between an attacker and the account, then any path to resetting it without consent is total. Add a second factor and the same bug becomes a bad day instead of a breach.
So: enforce 2FA where you can, treat your reset flow as authentication rather than plumbing, and read the boring code. The exciting vulnerabilities make the headlines. The boring ones own your account.