Failure pattern · 7 documented incidents

Automation acts on stale state or authorization

A background job or automation acts on a plan, permission or record that changed after it was read.

See it happen

Watch how this failure unfolds, then switch to the same situation with the safeguard in place. Click any step to replay it.

Scroll the diagram sideways to see every system.

12 / 12 s

A customer who cancelled is charged anyway.

What goes wrong:

  1. At 01:00 the job reads the list of accounts it will bill.
  2. At 01:20 an admin cancels account #77.
  3. At 02:00 the job acts on the list it read an hour ago.
  4. A customer who cancelled is charged anyway.

With the safeguard:

  1. At 01:00 the job reads the list of accounts it will bill.
  2. At 01:20 an admin cancels account #77.
  3. Just before acting, the job re-checks each account’s current version.
  4. The change is caught and the charge is skipped.

What it is

An automated job reads the state of the world, then acts on it later. In between, something changed: an account was cancelled, a permission removed, a newer plan applied. The job does the wrong thing with complete confidence.

How it happens

  • A job reads its list of work well before acting on it
  • Two automations can update the same thing at once
  • Permissions or configuration are cached and not re-checked

What it causes

  • Charges, deletions or changes applied to things that changed
  • An older plan overwriting a newer one
  • Access granted after it had already been revoked

Warning signs

  • Actions that contradict the current state of the record
  • Race conditions that only appear under load
  • Two automations repeatedly undoing each other’s changes

How to prevent it

Re-check state and permission at the moment of action. Use version checks or optimistic locking on every mutation, re-validate authorization when the action runs rather than when it was queued, and refuse to apply plans that are older than the current state.

  • Before acting, a job re-reads the record and checks it hasn’t changed (a version or compare-and-set check)
  • Only one automation can own a given change at a time
  • Permissions are checked at the moment of action, not when the job was planned

Key ideas:Optimistic concurrency control

Check your system against the full launch checklist

Real incidents with this pattern

Documented incidents first. Each links to its public source.

Open in the database
12 security advisories and illustrative scenarios with this pattern
Illustrative scenarioDate not recorded

JWT Secret Key Confusion & Privilege Escalation

Backend accepted HMAC-SHA256 tokens signed with public RSA key, allowing attacker to forge administrator tokens.

Duplicate action after an ambiguous result
Illustrative scenarioDate not recorded

DNSSEC Key Rollback & Global Domain Invalidation

Mismatched DS records during planned Key Signing Key (KSK) rollover caused recursive resolvers worldwide to return SERVFAIL.

Automation acts on stale state or authorization

In the standards

CollectSEA's mapping; not an official determination by the standards bodies.