0-Click Account Takeover via Cookie Switching

A router reseller running both a staging and a production environment, the kind of setup every company has somewhere, test build on one subdomain, the real thing on another. The brief itself asks the obvious question straight out, are they actually separate, or just pretending to be. This one's listed as being based on a real critical finding, improper session handling across environments leading to a full account takeover with zero interaction from the victim, though unlike the DeepSeek challenge, Wiz's own training page for this one doesn't link out to a specific named incident the way the DeepLeak one did, so I'm not going to pretend I tracked down which exact company this happened to, just going off what the challenge itself describes.

Started the same way every time, subdomain enumeration against the root domain.

Two subdomains jumped out immediately next to each other, stage.router-resellers and prod.router-resellers. Same product name sitting on both, which on its own doesn't mean much, plenty of companies run a staging and production pair with completely separate backing infrastructure behind them. Worth actually checking rather than assuming either way.

Staging loaded up as exactly what the banner across the top said it was, a visibly marked staging environment, open for testing, letting anyone sign in as a guest with no credentials required at all.

Signed in as that guest and had a look at the session itself rather than just clicking around the dashboard. The cookie set for that guest login was sitting right there in the request, plain to read, so I took note of the exact value before doing anything else.

Switched over to production next, same product, different subdomain, and this one wasn't handing out guest access the same way staging had been, which is exactly what you'd expect from an actual live environment.

Here's the part worth actually sitting with for a second. Instead of trying to find a login bypass or hunting for a separate bug on the production side entirely, I just took that same guest session cookie from staging and dropped it straight into a request against production, swapping nothing else about it. If the two environments were properly isolated, production should reject a cookie it never issued and never heard of. It didn't.

It came back in, and not just logged in, the page itself threw up a banner reading "Session Notice: your session was created in a different environment," along with a message confirming the vulnerability had been triggered successfully. Production was trusting a session token that staging had handed out, which means the two environments were sharing the exact same session validation logic and signing key behind the scenes, whatever issued that cookie didn't actually care which subdomain it came from, only that the signature checked out.

That's the whole chain, and it's worth noticing how little there actually was to it. No password guessing, no injection, no chained exploit, just noticing that a cookie minted on a throwaway testing environment was accepted at full trust by the real one sitting right next to it. Nobody clicked anything, nobody got phished, there's no victim interaction anywhere in this story at all, which is exactly what makes "0-click" the right word for it rather than just a convenient title. Staging environments get treated like they don't matter because they're not the "real" system, but if they're validating sessions against the same backend as production, they're not actually separate at all, they're just an unlocked side door standing right next to the front one.

Happy hunting, see you in the next scope :)