A password manager kept a spare copy of your master password. That was the whole bug.

Forget your master password and most password managers give you exactly two options. Reset the vault and start over with nothing, or ask the company to help you get back in.

The first one is honest and painful. The second one is where this week’s bug lives.

The bug

UpSignOn is a French password manager — a free personal vault plus a paid tier for organizations, built around a “zero knowledge” pitch, the same three words we wrote about two weeks ago. On September 2nd the vendor shipped version 7.19.0, fixing CVE-2026-75135 : on Windows, the application kept a “backup key” sitting in the process memory of UpSignOn.exe, and it stayed there even after the vault had been locked back up.

That backup key existed to protect a file called v6-vault1.DATA.txt — an encrypted backup of the user’s master password, kept on disk for exactly the situation this article opened with. Someone with local access to the machine could read that key straight out of memory, use it to decrypt the backup file, recover the plaintext master password, and from there unlock and export the entire vault. VulnCheck’s advisory  lays out the chain plainly: backup key, to backup file, to master password, to everything.

It rates a middling CVSS 6.9 — an attacker needs to already be on your machine, which is a real bar, not a low one. The vendor’s own release notes for 7.19.0 say only “security fixes,” which is common enough for a patch like this; the technical detail comes from VulnCheck’s write-up rather than from UpSignOn itself. That’s a small, ordinary gap worth noticing on its own: the plain-language explanation of what a fix actually protects you from usually comes from someone other than the company that shipped it.

The mechanism is worth dwelling on regardless of the CVSS score, because it isn’t really a story about a coding mistake. It’s a story about what a company has to build the moment it promises to help you when you forget.

Why the backup key had to exist at all

Here’s the tension nobody advertises. A password manager’s whole pitch is that one thing you remember protects everything you don’t have to. That’s the product. But the “one thing you remember” is also the “one thing you can forget,” and a company selling that product has to decide what happens on the day you do.

Refuse to help, and a forgotten master password means a genuinely destroyed vault — every saved login gone, no appeal. That’s a real design choice some products make deliberately, on the theory that any softer answer is a lock with a spare key taped to the door. Other products take the view that a single lapse of memory shouldn’t cost someone everything they have saved, and build a recovery path instead.

A recovery path for a single master password only has one honest shape: somewhere, in some form, something has to be able to reconstruct that password. Encrypt it, split it, escrow it, wrap it in a second key — the packaging varies, but the fact underneath doesn’t. You can’t recover a secret you genuinely never kept a way back to. UpSignOn chose to keep that way back, protected by a key of its own. And then that protecting key turned out to be exactly as breakable as anything else running in an unlocked process on your machine.

None of this makes UpSignOn’s engineers careless. It makes them a company that took the harder, kinder path — try to save the customer’s vault rather than shrug — and discovered that the harder path had its own sharp edge. That’s the same shape as the four teams landing in one ditch we wrote about after the USENIX password-manager paper: different codebases, different years, the same difficult problem, and a recognizable family of ways to get it slightly wrong.

The tradeoff you’re actually being asked to make

So when a password manager offers to rescue you from a forgotten master password, that convenience is not free. It is a promise that something, somewhere, can turn a lost secret back into a working one — and anything that can do that is worth an attacker’s attention, memory scrapers very much included. The forgiveness and the risk are the same feature.

That’s worth asking about directly, before you’re the one who forgot. Does this product recover a forgotten master password at all, or does forgetting mean starting over? If it recovers it, what does that recovery mechanism actually hold, and where does it live — on a server, in a file next to the vault, in memory while the app runs? A vendor that can answer that plainly is one that has thought about the tradeoff on purpose, rather than backed into it.

It’s also worth noticing what the bug did not require. Nobody had to breach a server, guess a password, or trick anyone into clicking anything. The attacker’s only job was to already be on the machine — a stolen laptop left unlocked, a colleague at a shared workstation, malware that got there some other way. A vault’s threat model usually spends most of its attention on the internet: phishing pages, breached servers, credential stuffing. A recovery feature quietly adds a second one — the person standing at your keyboard — and that second threat model doesn’t go away just because it’s less discussed.

Where Vauz sits

Vauz  doesn’t make the promise that creates this problem. There is no master-password recovery: the V-Key — Vauz’s unlock credential — is optional, and our threat model  says it plainly, in the section about what this design does not defend against. There is no recovery mechanism for a forgotten V-Key, and the hint you can set cannot reliably recreate one.

That matters here specifically because it means there is no equivalent of v6-vault1.DATA.txt to protect in the first place. UpSignOn’s bug required a recoverable master secret worth backing up, and a backup worth stealing. Without the recovery promise there is no such object, and so no backup key guarding it — not by hardening the backup, but by never needing one shaped like that. There is also no single key here that opens everything. No two stored values share an encryption key , so cracking one of them open does not unwrap the vault around it — and what protects them is derived from the machine itself rather than from something you memorised. That is the deeper reason there is no spare copy to find: the protection was never resting on a secret you could forget.

One clarification, since a careful reader might reasonably push back here: Vauz does let you set a hint for your V-Key. It is not sitting there on the unlock screen — it stays out of sight until you get the V-Key wrong, at which point Vauz offers a button, and the hint appears only if you press it. It’s fair to ask whether that’s really any different from the kind of forgiveness that got UpSignOn into trouble. It is, in the one way that matters: a hint jogs your memory, it doesn’t reconstruct anything. There’s no decryptable copy of your V-Key sitting anywhere for a hint to hand back — if it doesn’t ring a bell, you’re exactly as locked out as if it didn’t exist.

If you unlock Vauz with biometrics, that’s a second door you set up in advance, and it’s worth being precise about the difference. Unlocking with your own fingerprint or face on your own hardware is not the same act as recovering a secret. Nothing decrypts your old V-Key or tells you what it was. A recovery feature is one that can hand a lost secret back to whoever asks convincingly enough; a device unlock is one you configured ahead of time on hardware you’re holding. Only the first kind creates a new object for an attacker to go looking for, which is why only the first kind produces a bug shaped like CVE-2026-75135.

None of that comes for nothing, and we would rather say so ourselves than let the comparison read as a boast. The tradeoff is different rather than absent: what actually protects a Vauz vault isn’t a secret you’re asked to remember, so there’s nothing shaped like a recoverable master secret for a bug like this one to target — but that also means losing the device itself is a sharper risk than losing a password would be elsewhere. Our threat model says that part out loud too: if the only copy of the vault goes with the laptop, it’s gone, and there is no copy on our side to fall back on. That’s the honest cost of keeping nothing recoverable. It closes off exactly the kind of leak that hit UpSignOn, and it means nobody, including us, can rescue you from your own memory unless you gave yourself another way in ahead of time.

The actual question

Every password manager eventually has to answer “what happens when the user forgets,” because everyone forgets things eventually. There’s no version of that answer that costs nothing. Refuse to help and the cost lands on the customer who loses everything. Offer to help and the cost is a new thing worth attacking, somewhere in the system, for as long as the product exists.

UpSignOn’s engineers picked the second cost, tried to protect it properly, and a researcher found the seam anyway — which is exactly what responsible disclosure and a shipped fix look like working as intended. A fix only helps once it is actually on the machine, mind, and only if the build you installed is the one the vendor really published — a separate habit, and worth having. The more useful habit for the rest of us is knowing which cost a given password manager chose before we’re the one who needs the answer, not after.