Online poker has always had a cheating problem, but PokerNow, the browser based, no download platform that became the default choice for home games, private tables and casual play during and after the pandemic, has faced a specific and recurring category of exploit: players finding ways to see cards that should be completely hidden from them. Unlike bot play or collusion, which are behavioral problems, hole card leaks are an engineering problem. They come from how the application is built, not how people play it. This piece walks through why that category of bug keeps showing up, what actually makes it possible at a technical level, and what a properly hardened version of the same product would look like.
Why PokerNow Is Structurally More Exposed
Traditional online poker clients, the kind used by PokerStars, GGPoker and other licensed real money operators, run as compiled desktop applications. They ship with obfuscated binaries, custom network protocols, kernel level anti tamper systems, and dedicated security teams whose entire job is closing exactly this kind of hole. PokerNow runs in the browser. That single design decision is the root of almost everything else in this article.
As of August 2026, numerous instances have circulated that Poker Now opponents’ hole-card information may be accessible through data transmitted during live play, including WebSocket traffic. Currently, there has been no communcation from PokerNow in response to thr recent wave of exploits. With sensitive card data being exposed to an unauthorised player in this way, a relatively experienced programmer analyses that traffic and exploit the flaw, making it a serious game-integrity and security issue that should be reported privately and addressed by the platform.
A browser is, by design, an inspectable environment. Every modern browser ships with a full set of developer tools built in and available to anyone, for free, with no special skill required beyond knowing where the menu is. Those tools let a user open the page’s underlying document structure, watch every request and response moving across the network in real time, inspect variables sitting in memory, and even attach a debugger that pauses the application’s own code mid execution. That is an enormous asset for web developers building and testing software. It is a serious liability for any application whose core mechanic depends on some players not being allowed to see information that other players have.
In other words, PokerNow is trying to run a game of hidden information on a platform whose defining feature is that nothing run on it is truly hidden from the person operating the machine. That tension is not a bug in the traditional sense. It is a mismatch between the security model poker requires and the security model a browser can actually provide without extraordinary additional effort.
The Technical Anatomy of a Hole Card Leak
At a conceptual level, real time browser based card games can leak hidden state through a small number of well understood channels. None of these require exotic hacking skill. Most require nothing more than opening developer tools and reading what is already sitting on the page. For PokerNow, hackers have had to gain access to much more than what is in the web coonsole. The sections below go into more detail on how each mechanism typically looks from an engineering standpoint, without providing a working method to reproduce them against a live table.
Over delivery of game state
The single most common root cause of card visibility exploits in web based card games generally is what security researchers call over delivery, or sending more information to the client than that client is supposed to see, and then relying on the interface alone to hide the parts it should not display. In a properly secured system, a player’s browser should only ever receive the two cards that belong to that specific player. Everyone else’s hole cards should never leave the server until the moment they legitimately become public, for example at a showdown.
A useful way to think about this is the shape of the data object describing table state. A poorly designed table state object might look, in simplified conceptual form, something like a single structure containing every seat’s cards as plain values, with a separate flag per seat indicating whether that seat’s cards are currently supposed to be visible to the viewer:
{ "seats": [
{ "id": "p1", "cards": ["5h","6d"], "visibleToMe": false },
{ "id": "p2", "cards": ["Ah","Kd"], "visibleToMe": true }
] }The problem with that shape is structural, not cosmetic. The value of visibleToMe only controls what the interface chooses to draw. The actual card values for every seat at the table are already present in the payload the moment it arrives in the browser, which means they are already readable through the network inspector or by reading the in memory object directly, regardless of what visibleToMe says. A correctly designed system does not include a visibility flag at all, because it never sends the hidden values to that connection in the first place. The server computes, per connection, a filtered view of the table and only that filtered view is ever transmitted. There is no client side flag to bypass because there is nothing sitting behind it to reveal.
This pattern shows up constantly in web games and PokerNow consistently. Sending everything and filtering on the client is less code than building a permissions system on the server that tracks, per connection, exactly what that connection is currently allowed to know, and that authorization state has to be recomputed correctly every single time the underlying game state changes.
Client side rendering leaks
A closely related but distinct issue is what happens even when a platform is not blatantly sending every hole card to every player. A card can be visually hidden, shown only as a generic card back image, while the actual data describing what that card is still exists somewhere accessible in the page. That might be a hidden element in the page’s document structure that was never actually removed, just given a style property that keeps it off screen. It might be a JavaScript variable sitting in the browser’s memory that the rendering code chooses not to read from. It might be a field inside a WebSocket message that arrives constantly but is simply ignored by the part of the code responsible for drawing the table.
Front end frameworks that use a central state store, a pattern extremely common in real time web applications, tend to make this worse rather than better if used carelessly. The store exists precisely so that any component in the application can read from a single shared object describing the current state of everything. That is good practice for maintainability. It also means that if hidden card values are ever written into that shared store at all, in any form, they are then reachable from anywhere in the running application, including from the browser’s own developer console, simply by referencing the store object directly and printing its contents. The distinction that matters is whether hidden values are ever placed into client side memory in the first place, not whether the interface currently has a way to display them.
State desync and replay issues around transitions
Real time multiplayer applications (PokerNow) keep every connected browser in sync using a persistent connection, typically a WebSocket, that streams updates as the game state changes. Most of the time this works exactly as intended. The edges of the system are where things go wrong. Reconnecting after a dropped connection, refreshing the page mid hand, switching from spectator to player, joining a table that already has a hand in progress, or requesting a full replay of recent action are all situations where the server has to decide, again, exactly what state to send to that particular connection.
Each of those transitions is a separate opportunity for the same over delivery mistake to happen even in a codebase that otherwise filters data correctly during normal play. A common failure mode is a developer building careful, correct filtering into the main game loop, and then building a separate, much simpler reconnect or replay handler later that just serializes and sends the full current game object to get the feature working quickly. That handler is often never revisited once it appears to work, because from the outside, a reconnect that works looks identical whether or not it happens to also be leaking hidden information in the underlying payload. This is why a security review of this class of application has to specifically test every transition path, not just the steady state of an ongoing hand.
Third party extensions and scripts
A large share of publicized PokerNow cheating tools are not platform vulnerabilities in themselves. They are browser extensions or injected scripts that hook into the page after the fact, reading whatever data the underlying application is already exposing through one of the mechanisms described above, and repackaging it into a convenient overlay that sits on top of the table. Mechanically, this typically works by attaching a listener to the browser’s own networking layer or to the state store described earlier, watching for messages or fields that match the expected shape of card data, and rendering that data in an overlay positioned on top of the existing table graphics. From a technical standpoint this is not especially sophisticated. It is automating the exact same developer tools inspection any curious player could do manually, and presenting the result in a friendlier interface.
This distinction matters for understanding the problem correctly. The extension is the delivery mechanism, not the root cause. Banning a specific extension, or detecting and blocking it, does nothing to fix the underlying data exposure that made it possible in the first place. A new extension, or simply manual use of developer tools, will work again immediately unless the actual leak is closed at the source, meaning the server has to stop sending the data rather than the client being asked nicely not to display it.
How This Class of Bug Is Actually Found
It is worth being specific about what auditing for this looks like in practice, since the process itself illustrates why the underlying fix has to happen server side. A reviewer opens the browser’s built in network inspector before a hand starts, filters the traffic to WebSocket frames, and simply watches what arrives as the hand progresses. If a frame arriving before showdown contains card values for seats other than the reviewer’s own, that is the leak, independent of anything the interface is currently choosing to render. The interface is irrelevant to this test entirely. The only question that matters is what bytes crossed the network to that specific connection and when.
The same logic applies to memory inspection. A reviewer can pause execution with the debugger at a point in the code responsible for drawing the table, and inspect the objects available in scope at that moment. If hidden card values are present in any object reachable at that point, again independent of whether they are currently being drawn, the application has already failed the relevant security property. Passing this kind of review requires the server to have made the correct filtering decision before anything was transmitted, not the client to have made a correct display decision after receiving everything.
A Documented Case: The June 2024 Injection Vulnerability
This isn’t a purely theoretical category of bug. Security researcher Kevin Roleke documented a concrete example of exactly this kind of failure on PokerNow, disclosed on June 12, 2024.
The root cause was slightly different from the over-delivery pattern described above, but it lands in the same place: the browser ends up holding, and executing, more than it should. PokerNow sanitizes user-supplied text like display names in most places, but according to the writeup that sanitization was applied inconsistently across the codebase. Two spots stood out:
- Club admin approve and reject controls built their
onclickhandlers by concatenating a player’s username directly into JavaScript, e.g.onclick="club.approveWaitingUser('${this.club.id}', '${player.user_id}', '${player.username}')", which allowed code execution inside a username field despite a 14-character limit. - The private club “description” field had no length limit and no filtering at all before being written into the lobby page’s HTML, so a malicious description would execute automatically for anyone who opened that club.
From there, the reported proof of concept used an iframe to reach into the live table on the same subdomain, read hole card data that JavaScript running in that context could already see, and exfiltrate it to an attacker-controlled server, all without the victim doing anything beyond opening a club page.
Two things are worth taking from this case specifically. First, it’s a real, independently verified instance of the general principle this article has been making: once code can run in the same browser context as the table, hidden information stops being hidden, regardless of the specific mechanism. Second, per the disclosure timeline, PokerNow has not responded to the recent exploits as of August 2026. It does not change the fact that this exact class of vulnerability, unsanitized input reaching a browser context that also holds hidden card state, is structurally likely to recur, precisely for the reasons laid out earlier in this piece.
Why This Keeps Happening Instead of Getting Fixed
PokerNow’s entire value proposition rests on being frictionless. No installation, no account creation in many cases, no download, just a link that opens a working poker table in seconds. That simplicity is precisely what makes the security side difficult. Every one of the anti cheat techniques available to a desktop client, binary obfuscation, kernel level anti tamper, detection of memory editing tools, simply does not exist inside a browser sandbox. The platform is fundamentally trusting JavaScript code running on a machine that the player themselves fully controls. That is an adversarial environment by definition, and no amount of front end cleverness changes that basic fact.
There is also a straightforward incentive problem. PokerNow largely serves free social games and private home games rather than licensed real money tables regulated by a gaming authority. Regulated operators face legal and financial consequences for exactly this class of vulnerability, and that pressure funds dedicated security teams, regular third party audits and formal bug bounty programs. A platform whose core product is free has a much harder time justifying that level of ongoing investment, even though the underlying engineering problem is exactly as serious.
What Correct Mitigation Actually Looks Like
The fix for essentially every category of leak described above comes down to one principle applied consistently and without exception. Never send data to a client that the client is not currently allowed to see. That sounds simple, and conceptually it is, but it requires discipline applied at every single point where state moves from server to browser, not just the obvious ones.
- Hole cards should only ever be transmitted to the specific connection that owns them, filtered on the server before anything is sent, never broadcast to every client with a flag telling the interface to hide it.
- The per seat card fields simply should not exist in the payload delivered to a connection that is not entitled to see them, rather than existing but being marked hidden, so there is no value present to extract in the first place.
- Cards should be actively pushed to other players only at the exact moment they become legitimately public, such as a showdown or a voluntary reveal, rather than being delivered earlier and simply withheld by the interface until that moment.
- Reconnect, rejoin, replay and spectate code paths need the exact same server side filtering logic applied independently, since these are consistently where over delivery mistakes slip through even in codebases that get the main game loop right.
- Security review needs to happen at the level of raw WebSocket payloads and network traffic, not just the rendered interface, since a table can look completely correct on screen while the underlying data stream is already leaking everything.
- Automated tests should specifically assert that hidden information never appears in a given connection’s payload, rather than only testing that the visible interface renders correctly, since the two are not the same guarantee.
None of this requires exotic technology. It requires treating every network message as a potential leak point and auditing accordingly, which is a discipline problem as much as a technical one.
The Bigger Picture
This pattern is not unique to PokerNow. It shows up across almost every real time browser application that handles some form of hidden information, from other browser card games to hidden role party games to fog of war strategy titles. The lesson security researchers keep rediscovering across all of these products is the same one. Hiding something on the client is not the same thing as keeping it secret. If a piece of data reaches the browser at all, in any form, a sufficiently curious user can generally get to it using tools that already ship with every browser on the market, no special software required.
For any platform operator building something similar, the practical takeaway is to treat interface level hiding as a cosmetic choice rather than a security boundary. Real secrecy has to be enforced at the point where data leaves the server, not at the point where it is drawn on screen. Until that principle is applied consistently across every code path, including the ones that only run during edge cases like reconnects and replays, this exact category of exploit will keep resurfacing under new names on new platforms.
Our Recommendation
PokerNow doesn’t process real money itself, but that’s not how most of its private tables actually work in practice. Its whole appeal is hosting home games, and home games are overwhelmingly real-money games, tracked through the built-in ledger and settled outside the app between friends. Functionally, a lot of PokerNow traffic is real-money poker, even though the platform never touches a deposit or withdrawal.
Given that, and given everything above, our recommendation is straightforward: don’t rely on PokerNow for any game where real money is actually on the line. The core issue isn’t any single bug, including the ones documented above. It’s that the platform’s entire security model rests on browser-side trust, and browsers are, by design, not a trustworthy place to hide information from the person operating them. A regulated real money operator absorbs that risk with compiled clients, dedicated security teams, and regulatory pressure to keep investing in it. PokerNow, built to be free and frictionless, structurally cannot match that, and the June 2024 case shows the category of bug that gap produces is real, not hypothetical. If the stakes are purely social, that tradeoff is probably fine. If real money is changing hands, it isn’t.