Imagine losing your entire Rabby Wallet not to a phishing link, not to a fake app, not even to a moment of carelessness, but simply by playing a browser game for ten minutes while your extension quietly locked itself.
That's genuinely what security researchers found buried inside one of the more trusted names in self-custody browser extensions.
No suspicious click. No visible warning ignored. Just a wallet, a countdown timer, and a signature request nobody ever saw.
Security researcher v12sec laid out the discovery in detail, describing it as a silent signature extraction leading to a full wallet drain.
The setup was disarmingly simple. A malicious page connects to a user's wallet, then presents something completely mundane, in this case, a browser game modeled on Temple Run. As the game starts, the page quietly queues a signature request permitted to drain the connected wallet. Here's where it gets genuinely sneaky: a pop-under bug in Chrome hides the confirmation dialogue entirely, so the user never sees a request waiting for their approval at all. After ten minutes pass, the wallet auto-locks with that request still pending, and critically, the auto-lock does not cancel it.
I think this is the part of the exploit that's genuinely hard to wrap your head around. When the user eventually comes back and types their password to simply unlock their wallet, that password entry itself gets consumed as approval for the pending request instead. The signature gets signed and returned to the malicious page automatically, without the user ever seeing or confirming anything they were actually agreeing to.
The technical root cause traces back to how Rabby manages pending requests. The wallet maintains exactly one in-flight approval at a time, stored in a background singleton called notificationService.currentApproval. When the auto-lock timer fires, the function handling that lock, setLocked(), clears the password and drops the wallet's keyrings, but it never touches the approval queue sitting alongside it. There's only one subscriber listening for that lock event anywhere in the codebase, and its only job is clearing an unrelated analytics interval. The pending approval, still holding a live callback into the actual signing process, simply survives the lock untouched.
Here's what I find most striking about this whole case: Rabby actually had a guard built specifically to prevent exactly this kind of mismatch. The relevant check in resolveApproval reads plainly: if an approval ID exists and doesn't match the current approval's ID, the function returns without resolving anything. That's precisely the kind of protection you'd want here. The problem is that check only fires if an approval ID is actually passed in the first place, and it turns out nearly every approval screen in Rabby's codebase does pass that ID, except one.
The unlock screen is the sole approval screen that calls resolveApproval() without an ID at all, despite being specifically whitelisted to coexist with other pending approvals in the queue. Resolving with no arguments hands the signing process an undefined result, and because the actual signing paths only read a specific extra property off that result, undefined gets tolerated rather than rejected. The keyring signs anyway. This affects personal_sign and all four eth_signTypedData variants, including v4, producing a cryptographically valid signature sent straight back to whatever site requested it, with the user never having seen or confirmed a thing.
What makes this genuinely concerning rather than just a narrow edge case is that there's a second way to trigger the exact same flaw, one that requires zero interaction with the notification window whatsoever. Rabby's unlock function also resolves through an internal event bus via a UNLOCK_WALLET listener, and calling wallet.unlock() broadcasts that event to every UI surface simultaneously.
That means unlocking Rabby through the toolbar popup, a completely separate, normal action most users perform dozens of times, invokes handleUnlockSuccess() inside a notification window the user may never have opened or even known existed, silently resolving whatever pending request sits in that queue. The window that actually produced the signature is never viewed at all. I think that detail is what elevates this from a clever exploit into a genuinely serious design flaw: the core issue is that consent and the specific request it's supposed to apply to were never actually bound together anywhere in the system. A background singleton holds one approval. A lock destroys the session keys but leaves that approval sitting there. An unlock resolves whatever's in the queue with no verification of which screen triggered it or whether a user ever actually confirmed anything. Entering a correct password alone was enough to produce a valid signature.
To Rabby's genuine credit, the response here was fast. v12sec confirmed the finding was disclosed on August 3, and that Rabby's team acknowledged and fixed the bug in less than 24 hours, with the researchers themselves reviewing the patch afterward and confirming it was effective.
Rabby's own official account confirmed the fix directly, stating the vulnerability was resolved upon discovery and that an update addressing it was released on August 11.
The team specifically urged users to make sure their Rabby extension is fully updated, and confirmed the mobile app was never affected by this issue in the first place, since the exploit relied specifically on browser extension behavior.
I think it's worth ending on the genuinely reassuring part of this story, because the conditions required to actually trigger this exploit were quite narrow. Two things had to be true simultaneously: the wallet needed to be connected to a malicious website in the first place, and the user needed to have manually changed their auto-lock timer to specifically ten minutes, since every other timer setting was completely unaffected by this flaw. Both Rabby and the researchers who found it confirmed no exploits were ever detected in the wild before the patch shipped.
That's genuinely good news, but I don't think it should make anyone complacent about what this case actually reveals. A fully patched wallet, built by a serious team, with an existing safety check specifically designed to prevent this exact scenario, still had a gap sitting quietly in its code for however long it existed before someone happened to find it. If you're running Rabby, updating your extension isn't optional at this point, it's the only thing standing between you and an exploit that required nothing more from an attacker than convincing you to play a game while your wallet's clock quietly ran out.
Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services. Follow us on X @nulltxnews
