The Anatomy of a Race Condition

Every serious bug I have shipped shared one property: it was obvious in hindsight and invisible in the diff. This one was a time-of-check to time-of-use flaw — a race between validating a request and acting on it — and it is the perfect specimen for showing you how this blog renders a writeup. Read it for the bug if you like; read it for the formatting if that is why you are here.

How the paragraph, the quote, and the aside read

Body text is set in Fraunces, a serif with real optical sizing, because security writing should read like an essay and not like a config file. You get the usual inline tools: bold for the load-bearing claim, italic for a term of art, inline code for an identifier like SELECT ... FOR UPDATE, and links underlined in stamp red.

Rule of thumb. If a check and the action it guards are not in the same transaction, assume an attacker can slip between them. The window is never “too small to matter” — it is only too small to notice.

Lists come in both flavors. Unordered items are set with an em-dash marker:

• The check reads state.
• The attacker mutates state.
• The action trusts the stale read.

And ordered when sequence is the point:

1. Request A checks the balance: sufficient.
2. Request B checks the same balance: also sufficient.
3. Both withdraw. The ledger goes negative.

Code, in any language you throw at it

Syntax highlighting runs at build time via Shiki, so there is zero JavaScript on the page and it covers essentially every language. Here is the vulnerable path in Python:

def withdraw(account_id: int, amount: Decimal) -> bool:
    balance = db.fetch_balance(account_id)   # time of check
    if balance < amount:
        return False
    # 👇 another request can land right here
    db.set_balance(account_id, balance - amount)  # time of use
    return True

The fix is to let the database do the arbitration it was built for:

-- Atomic: the check and the mutation are one statement.
UPDATE accounts
   SET balance = balance - :amount
 WHERE id = :account_id
   AND balance >= :amount;   -- no row updated ⇒ insufficient funds

And the same idea expressed as an optimistic-locking guard in Go, to prove the highlighting is not language-specific:

res, err := db.Exec(
    `UPDATE accounts SET balance = balance - $1, version = version + 1
     WHERE id = $2 AND version = $3`,
    amount, accountID, expectedVersion,
)
if n, _ := res.RowsAffected(); n == 0 {
    return ErrConcurrentModification // someone moved first; retry
}

Config and markup highlight too — here is a snippet of the offending deploy config:

service:
  isolation: read-committed   # ← too weak for this workload
  retries: 3

Tables, for when prose stops scaling

Isolation level	Prevents this bug?	Cost
Read Committed	No	Cheapest
Repeatable Read	Partially	Moderate
Serializable	Yes	Retries under load
Explicit row lock	Yes	Contention

The part only a security blog needs

Some details you can publish, and some you can only publish shaped. This blog supports redaction that declassifies when you hover it — useful for gesturing at a real incident without naming it. The affected service was internal-billing-gateway-v2 and the reporter was paid a bounty of $4,000.¹

Severity, the advisory ID, and read time all live in the masthead block at the top of every post, driven by the frontmatter — so a post declares itself severity: high and the chip colors itself accordingly.

Writing your own post

Drop a Markdown file in src/content/posts/. The frontmatter is the whole contract:

---
title: "Your Title Here"
description: "One line the index and the meta description share."
date: 2026-08-08
severity: medium        # info | low | medium | high | critical
tags: ["dfir", "rev"]
---

Everything below it is ordinary Markdown. Write, save, and it appears in the register on the front page — sorted by date, stamped with its own advisory reference. That is the entire workflow.

Footnotes

1. Details altered. Any resemblance to a gateway you operate is a good reason to check your isolation level. ↩