# BUGS.md — audit of 2026-08-03 Third full-codebase audit, opened after the 2026-07-26 (B-01 … B-24) and 2026-07-27 (B-25 … B-49) lists were emptied. Numbering continues from the last fixed finding, B-51. The list opened at B-52 … B-72 and holds only what is still **open**: a finding is removed from this file once it is fixed. Per CLAUDE.md's convention each entry gets its own commit with its own regression test, and the `B-nn` marker goes in a comment next to the fix so `git log --all --grep 'B-nn'` finds it later. Already fixed and removed: B-52 (a round past ~50 participants deadlocked the payout — `025754c`), B-53 (a bet could pay into the pool of a round it was left out of — `PLACEHOLDER`). State of the tree at audit time: 264 unit tests, all passing; `tests/integration/` still empty; withdrawal and the RBF bump path still never live-broadcast. Verified as *not* broken while looking for these: i18n key parity (146 identical keys across all 7 languages), HTML escaping of every user-controlled value in `admin.js`, the Alembic chain (linear, single head, matching `models.py`), strictly-integer satoshi arithmetic everywhere, and `.gitignore` coverage of secrets/DB/logs (nothing sensitive is tracked in git). Severity is about consequence, not likelihood: **critical** = money stuck or lost, or the lottery stops; **high** = a security control that does not hold; **medium** = wrong behaviour with a bounded blast radius; **low** = drift between documentation and code. --- ## Critical ### (not new) `drawing` does not resume after a restart Already tracked as an accepted gap in CLAUDE.md's "Known gaps", not re-numbered here. Worth restating in context: with `restart: unless-stopped` on the app container, this is the one state that gets stuck with money in play, and it remains the last prerequisite for running unattended. --- ## High — security ### B-54 — `X-Forwarded-For` is trusted blindly, so every IP-keyed control is bypassable `app/api/client_ip.py:14-17`, `Caddyfile`. `client_ip()` returns `xff.split(",")[0]`. Caddy's `reverse_proxy` *appends* the real peer address to an incoming `X-Forwarded-For` rather than replacing it, so the first element is whatever the client sent. Rotating a fake value per request defeats `login_ip`, `register_ip` (B-33) and the per-IP SSE subscriber cap (B-38) outright; only the per-username login bucket still bites. Fix: take the *last* element of the header, or force it at the proxy with `header_up X-Forwarded-For {remote_host}` and keep reading element 0. The proxy-side fix is the more robust of the two, since it makes the app's assumption true. ### B-55 — Argon2 hashing runs on the event loop `app/auth/security.py:20-39`, called from `app/auth/routes.py` and `app/api/routes/users.py`. `hash_password`/`verify_password` are synchronous and cost tens of milliseconds each, so every login, registration and password change blocks the whole process — including all six background tasks (scheduler, confirmation poller, RBF bumper, listener, both reconcilers). A burst of unauthenticated login attempts (which, per B-54, is not effectively throttled) is a cheap denial of service that also delays draws and confirmations. Fix: run both through `starlette.concurrency.run_in_threadpool`. ### B-56 — `RateLimiter._buckets` is never pruned `app/auth/rate_limit.py:37`. The dict grows without bound, keyed by attacker-chosen strings (arbitrary usernames, and — via B-54 — arbitrary IPs). `decay_seconds` ages a bucket's *counter* but never removes the entry. Fix: evict entries whose last failure is older than `decay_seconds` (opportunistically on `record_failure`, or on a periodic sweep), and cap the dict size. ### B-57 — username matching is case-sensitive while the login throttle key is not `app/auth/routes.py:126` (`body.username.lower()`) vs `:132` (`User.username == body.username`). Two consequences: `Bob` and `bob` are separate accounts sharing a single rate-limit bucket (one locks the other out), and registration happily accepts near-duplicate usernames, which is an impersonation vector on a custodial system. Fix: make username uniqueness case-insensitive (store a normalized form, or a functional unique index) and key the throttle on the same normalized value. ### B-58 — the registration throttle counts successes as failures and is IP-only `app/auth/routes.py:66-71`. `record_failure` is called on every registration attempt, successful ones included. Five legitimate signups from one shared/NAT address lock the sixth real user out with exponential backoff up to 600 s — while an attacker skips the limiter entirely through B-54. The intent (bounding accounts per source) is reasonable; the current shape punishes only honest users. The inline comment also cites B-31 (the resubscribe finding) where it means B-33. Fix: keep an accounts-per-IP quota if that is the goal, but express it as a quota rather than as failure backoff, and fix the B-nn reference. ### B-59 — deposit crediting is not corroborated, unlike external-spend detection `app/deposits/service.py:31-45`, `app/electrum/listener.py:401-433`. A candidate external spend is corroborated across the other configured servers before it can reduce a balance (B-29), but `value` and `height` for a *credit* are taken from the single active connection with no cross-check. A hostile or broken server can inflate a user's displayed balance with outpoints that do not exist. The blast radius is bounded — a bet or withdrawal built on a phantom UTXO is refused at broadcast and the rollback releases it — but it wedges the user's balance display and burns build attempts. Fix: either corroborate credits the same way (symmetry with B-29), or record the asymmetry explicitly as an accepted risk in CLAUDE.md with its bound stated. ### B-60 — `POST /admin/bug-reports/{id}/status` writes no audit entry `app/api/routes/admin.py:404-419`. Every other admin mutation (config edit, pause/resume, privkey export, password reset) is audit-logged. This one is not, so a report can be silently marked `resolved` with no trace — and with one shared `ADMIN_TOKEN` and no per-admin identity, the audit log is the only accountability there is. --- ## Medium — correctness and robustness ### B-61 — config edits apply retroactively to the round already in progress `app/rounds/scheduler.py:71`, `app/rounds/service.py:51-61`, `app/api/routes/admin.py:106-128`. `round_duration_seconds` is read live on every tick and on every bet check, and the deadline is computed as `opened_at + duration`. Lowering it from 600 to 60 while a round is 300 s in closes that round instantly; raising it moves the `closes_at` clients are already counting down to. `round_cooldown_seconds` has the same property for the gap after a close. B-11 fixed exactly this class of problem for `bet_amount_sats` (an in-progress round's advertised jackpot must not move when an operator edits the bet amount); the timing fields were left live. Fix: snapshot the duration (and cooldown) onto the `Round` row when it opens and read them from there, leaving the config row as the value for the *next* round. ### B-62 — "withdraw the full amount" reliably produces an unbumpable transaction `app/static/app.js:798-807`, `app/wallet/psbt_builder.py:138-141`, `app/tx/broadcast.py:150-152`. The max-amount checkbox sends `amount_sats == myBalanceSats == total_in`, so `change == 0`, the change output is dropped, and the tx has a single output. `bump_fee` then finds no change output to absorb the increase and raises `RbfError` every 30 s until the reconciler abandons the row six hours later. The RBF single-change-output limitation is a documented gap, but the UI makes it the *default* withdrawal path rather than a corner case (the same applies to an exact-amount bet). Fix directions: leave a change output above `DUST_LIMIT_SATS` when the requested amount would consume the whole input total (i.e. reserve a little), or warn in the UI that a full-balance withdrawal cannot be fee-bumped, or implement the extra-input RBF fallback. ### B-63 — `tip_height == 0` window right after connecting can seed a draw from a pre-close block `app/electrum/listener.py:160-167`, `app/rounds/scheduler.py:153`. `_run_once` assigns `self.client` *before* `subscribe_headers()` returns, so there is a window in which the client looks alive while `tip_height` is still 0 and `tip_header_hex` is `None`. A `_close_and_draw` entering that window records `tip_at_close = 0`, and the first header applied — the current tip, a block mined *before* the round closed — satisfies `tip_height > tip_at_close` and becomes the draw's entropy. The draw must use a block that did not exist at close time; a block whose hash was already public before betting closed is not the guarantee the flowchart describes. Fix: publish `self.client` only after the first header has been applied, or refuse to draw while `tip_header_hex is None` / `tip_height == 0`. ### B-64 — `_apply_header` accepts a same-height header without the chaining check `app/electrum/listener.py:271-296`. The chain check only runs for `height == self.tip_height + 1`. A header at exactly the current tip height replaces `tip_header_hex` after passing only the self-target check — which, as the docstring of `header_meets_its_own_target` already notes, a server can satisfy with a self-declared easy target. Separately, a header with no `hex` field sets `tip_header_hex = None`, discarding a tip we otherwise accepted. Fix: treat a same-height header as either ignorable or as a reorg signal rather than silently replacing the entropy source, and don't clear `tip_header_hex` on a hex-less notification. ### B-65 — `/rounds/current` counts unconfirmed participants; the draw and payout do not `app/api/routes/rounds.py:131-143` vs `app/rounds/scheduler.py:126`. `participant_count` and `jackpot_sats` are computed over *all* `round_participants` rows, while the draw and the payout only use `status == "confirmed"`. So the advertised jackpot can exceed what is actually paid out, and a participant whose bet is later abandoned appears in the count and then vanishes from it. Fix: either count only `confirmed` (and accept that a fresh bet takes a block to show up), or expose the two figures separately (confirmed vs in-flight) so the number on screen and the number that gets paid agree by construction. ### B-66 — nothing stops rounds from opening with no `fee_address` configured `app/rounds/config.py:12-17`, `app/rounds/scheduler.py:330-335`. A fresh instance starts with `fee_address = ""`. Rounds open, bets are accepted and confirm, and only then does the payout refuse to build — leaving the round in `paying_out`, retrying every 60 s, with the audit log as the only signal. Fix: refuse to open a round while `fee_address` is unset (and surface it on `/admin` and as a maintenance-style banner), so the failure happens before anyone's money is committed. ### B-67 — `/qr/{address}` is unauthenticated, synchronous and only shape-validated `app/api/routes/qr.py:11-21`. `qrcode.make` runs on the event loop, so the endpoint is a cheap CPU amplifier for an unauthenticated caller, and the regex accepts any `plm1[a-z0-9]{10,90}` string without validating the bech32 checksum — so it happily renders a QR for a non-address. Fix: validate with `is_valid_plm_address` (already used by withdrawals and by the admin `fee_address` validator), and either offload the render or cache it per address. --- ## Low — documentation and consistency drift ### B-68 — CLAUDE.md and README describe a state the code has moved past - CLAUDE.md's tech-stack line still says JWT has **no revocation (B-34)**; `token_version` implements exactly that revocation (`app/db/models.py:29`, `app/auth/dependencies.py:26`). - "Known gaps" still says **no rate limiting anywhere (B-33)**; login and registration are throttled (`app/auth/rate_limit.py`). What is genuinely still unthrottled is bets, withdrawals and the admin endpoints — that is the claim worth keeping. - "Known gaps" still says **`/report-bug` is a placeholder**; it is fully implemented and translated, with admin triage. Only `/guida` is still a stub. - Test counts are stale in three places: 264 actual, CLAUDE.md says 253 twice, README says 232. - The code map omits `app/auth/rate_limit.py`, `app/api/client_ip.py` and `app/api/routes/bug_reports.py`. - README links `flowchart.mmd`, which does not exist (the diagrams live in `flowchart/`), describes `docs/running-the-server.md` as covering "local venv vs. Docker" (that workflow was removed in B-44), and links the anchor `CLAUDE.md#tech-stack-mvp`, which no longer exists. ### B-69 — stale in-code comments - `app/tx/reconcile.py:206` calls the payout retry "a future payout-retry routine — still an open gap"; it exists (B-26). - `app/db/base.py:9` says "five concurrent background tasks"; there are six. - `app/auth/routes.py:31` cites B-31 where it means B-33 (see B-58). ### B-70 — the flowchart's WITHDRAW precondition is not implemented as written `flowchart/platform-overview.mmd:39` (node E1) states a withdrawal cannot happen together with a bet in progress. The code only serializes the *builds* through the per-user lock (`app/tx/locks.py`): a withdrawal is accepted while a bet is still unconfirmed, as long as confirmed UTXOs cover it. CLAUDE.md declares every node and edge label of the diagrams a behaviour that must be implemented as described, so one of the two has to move — most likely the diagram, since the lock already prevents the actual double-spend hazard, but that is a decision, not a cleanup. ### B-71 — `.env` points `MASTER_KEY_PATH` at a second copy of the master key CLAUDE.md's deployment section prescribes pointing `MASTER_KEY_PATH` at the host-side `./data/keys/master.xprv.enc` so the venv scripts and the container read one file. `.env` instead sets `./master.xprv.enc`, and both files now exist in the working tree (both gitignored). They were verified during this audit to decrypt to the *same* xprv, so nothing has diverged yet — but `scripts/decrypt_master_key.py` reads a different file from the one the container uses, and a future `generate_master_key.py --overwrite` would split them silently, with an ops recovery path that then reports the wrong key. The same duplication exists for the database (`./plm_lottery.db` next to `data/db/plm_lottery.db`), which is less dangerous but equally confusing. Fix: set `MASTER_KEY_PATH=./data/keys/master.xprv.enc` in `.env`, delete the stray root copy once confirmed redundant, and state the same for `DATABASE_URL`. ### B-72 — `docs/setup.md` still frames setup as "locally or via Docker" `docs/setup.md:1-10` lists Python as a prerequisite "for the local/venv workflow" and describes the master-key step as local *or* Docker, while B-44 made Docker the only supported way to run the server (`docs/running-the-server.md` and README were updated, this file was not). The venv genuinely is needed for tests, migrations and the key scripts — the wording just needs to say that instead of implying a second way to run the server.