The analytics host set a session cookie that was an HS256 JWT. The signing key in the server was an environment variable with a hardcoded fallback. That fallback string was in the public client bundle.
A real session cookie from the live host verified against the fallback. The fallback was the production key, not a dead default. With it, an unauthenticated caller minted a cookie for any user id, any email, and the staff flag.
The server rendered that identity into the page payload. A theme API read and wrote state under the forged user id. No password, no victim click.
What we proved
An unsigned-by-us, signed-with-the-public-fallback cookie was accepted. The page greeted the forged identity. A write to the theme endpoint persisted against the forged user id. A cookie signed with a different secret was rejected.
What this is not
Not a cloud account takeover and not a reading of other customers' stores beyond the identity and the state that endpoint stores. The impact we showed is authentication bypass and a cross-user write on that panel.
Why a scanner misses it
Secret scanners flag high-entropy strings. A short fallback next to JWT_SECRET looks like a dev leftover. The proof is verifying a live cookie against it and showing the server acts on the forged id.
Buyer takeaway: A fallback secret in client code is the production secret until a live cookie fails to verify against it. Check that before calling it dead code.
