mutated × shared — the answer changes between runs

Predictable ID Collision Under Load

Deriving a 'unique' id from the clock works until two requests land in the same tick.

01the recipe

In the wild

compound ofTime, Money & EntropyCWE-330 Weak RandomnessRace ConditionsCWE-366 Thread RacecompoundCWE-340 Predictable IDs CWE-362 Race Condition

example.py

# SMELL: derive a 'unique' id from the clock; two requests in one tick collide.
# (time / money / entropy x race conditions)
import time
def new_id():
    return int(time.time() * 1000)    # ms timestamp -- not unique under load
# two concurrent requests can read the same millisecond -> duplicate id.

# RIGHT: use a real source of uniqueness, not the clock.
import uuid
def new_id():
    return uuid.uuid4().hex           # collision-resistant regardless of timing

A timestamp looks unique until two requests share a tick; under concurrency that window is hit constantly, and the duplicate id appears only under load -- never on a developer's single call.

// observed

race:  two requests share id 1718...204 -> one record overwrites the other
right: independent ids; no timing-dependent collisions

02weakness catalog

Mapped weaknesses (CWE)

On its own, this defect is catalogued by MITRE as one or more of these weaknesses. The exploitable vulnerability usually appears only when it chains or combines with another.