BluffKing Security Bounty Audit: All Three Targets Are Defended

BluffKing’s security bounty sets three challenges: predict the community cards early, obtain another player’s hidden hole cards, or change your own hand so the server settles on it, with RMB 10,000 for each reproduced and confirmed challenge and RMB 30,000 for all three. On October 30, 2026 we ran a full audit of the three with models from two vendors. Three Claude audit agents each took exactly one challenge, read the source line by line and returned an exploitable or not-exploitable verdict with the file locations behind it. Codex then acted as the adversarial reviewer: its job was not to agree but to do its best to break the three not-exploitable verdicts. Everything was read-only on the source; no file was changed and nothing was run on production servers. The result: in every path reviewed, no exploit that would qualify for any of the three bounties was found. During a hand, all three targets are correctly defended in both default sealed dealing and advanced encrypted dealing, both vendors’ models agree on all three verdicts, and zero bounties are claimable. We will not fabricate a non-existent exploit to claim a reward. The adversarial review did, however, find a genuine fairness defect outside the bounty scope, fixed the same day; see the end.

Predicting the board: advanced encrypted dealing uses n-of-n threshold encryption, so every community card needs a decryption share from every participant before it opens, and the server holds no share of its own. Shares are requested and accepted only for the current street, checked against both the card index and the contributing party, so there is no way to ask for the turn’s share during the flop. Default sealed dealing publishes only the SHA-256 commitment of the secret seed before the deal, and the seed itself is disclosed only after the hand ends; the fallback random number generator is seeded from operating-system randomness and its key is never sent. Knowing the board early would require inverting SHA-256 or obtaining a leaked seed, and the source has no path to either. Reading others’ hole cards: the table snapshot sent to each connection has a single exit, and it redacts by viewer seat: during a hand, hole cards are included only when the seat matches the viewer, and a connection with unknown identity is treated as fully redacted. In advanced encrypted dealing, hole-card shares are relayed only to the card’s owner, and the sender’s identity comes from the authenticated connection rather than from a field in the message, so a seat cannot be spoofed. At showdown you can only open your own cards; cards shown publicly are visible to everyone, and a reconnect snapshot restores only those public cards. Folded cards never appear in anyone’s snapshot during the hand, and spectator snapshots have hole-card fields stripped at every depth. One boundary bears repeating: after a hand ends, default sealed dealing gives its participants the seeds for recomputation, so they can recover folded and unshown hole cards. That is the default mechanism by design, already disclosed in Three poker security challenges; it is not reading cards during play, and whether it counts for the bounty depends on the time window in the campaign rules. The default-mode paths for these two challenges are also walked through in Can cheats see undealt cards?

Changing your hand in settlement: the engine is the sole ranker, and winners are computed from server-authoritative cards. The showdown message in advanced encrypted dealing carries only a deck index and a threshold proof, with no field for a card value; the server recovers the card from the ciphertext it committed to earlier, and a seat whose proof fails forfeits rather than winning with the hand it claims. Pot arithmetic uses overflow-checked operations with conservation assertions. Any winner, rank or card a client might send is never a settlement input, so there is nothing to forge. These three challenges are exactly the attack surface the server-blind mental poker plus commit-reveal architecture was built to close; what this audit adds is confirmation that the implementation matches the design, not a claim about how good the design is.

The out-of-scope finding: see your own cards, then back out. While trying to break the second verdict, Codex noticed that when advanced encrypted dealing exchanges hole-card decryption shares at deal time, handing over the shares you owe others and receiving the shares for your own cards were not bound into one atomic step, so a seat had a window in which it could see its two hole cards and only then decide whether to stay in the hand. The old logic classified such a pre-betting exit, with only blinds posted, as a blameless void and refunded every blind. That is a free look followed by the option to take your blind back, an expected-value arbitrage against forced blinds. It is none of the three bounty classes: no board was predicted, no one else’s cards were seen, and no settlement card was altered, and the only asset involved is play-money beans. The existing mitigation, a sticky downgrade to default dealing for the rest of that table session after one void, limited the rate but did not remove the edge. After verifying the mechanism line by line we changed it the same day: deal time now follows the same rule as the flop and showdown. A seat that exits, withholds a share, or has no connection able to receive its own shares when judgement is made is attributed; the chips it put into the pot go to the honest players in settlement, with any uncalled excess refunded as usual, and as long as an honest player remains in the hand it no longer voids or downgrades the table. An honest drop is treated the same way, as in live poker. The fix went through four rounds of Codex review before merging to main; it ships with the next backend release, and this post is published only after that release.

Some boundaries need stating. This was a source review, not a penetration test against production, and we did not separately verify that the production binary matches the source; the conclusions do not extend to other games or tournaments. Both modes still require trusting the operator and the client program, and a leaked seed, a compromised server or an undiscovered bug would change the conclusions above, so we do not say “absolutely secure”. The bounty is still open; the rules and deadline are on the bounty page, and the prompts and materials from this audit are available from the administrator as described there. If you want to do the same for your own project, the division of labour transfers directly: one audit agent per attack target, responsible for nothing else, with verdicts that must land on file locations; then a model from a different vendor as the adversarial reviewer. The core of that prompt is one sentence: “Below are three not-exploitable verdicts with their evidence. Your job is to overturn them; if you cannot find a counterexample, explain why, and if you can, give the full attack sequence and the code behind it.” The out-of-scope defect above is what that sentence produced.