Bug: Race condition in timestamp-based queue lock fallback #115

New Issue

2026-06-06T11:50:08Z

jmiller commented

2026-06-06 11:50:08 +00:00

Audit Finding

Severity: Medium

Issue:
acquireTimestampLock() reads lock time, checks staleness, then writes — classic TOCTOU race. Two concurrent processes could both acquire the lock. MySQL/PostgreSQL advisory lock paths are correct but the fallback is unreliable.

Fix: Use atomic UPDATE with WHERE clause checking old value, then verify getAffectedRows() > 0.

Files: QueueProcessor.php

## Audit Finding **Severity:** Medium **Issue:** `acquireTimestampLock()` reads lock time, checks staleness, then writes — classic TOCTOU race. Two concurrent processes could both acquire the lock. MySQL/PostgreSQL advisory lock paths are correct but the fallback is unreliable. **Fix:** Use atomic UPDATE with WHERE clause checking old value, then verify `getAffectedRows()` > 0. **Files:** `QueueProcessor.php`

jmiller commented

2026-06-06 11:50:12 +00:00

Branch created: feature/115-bug-race-condition-in-timestamp-based-qu

git fetch origin
git checkout feature/115-bug-race-condition-in-timestamp-based-qu

Branch created: [`feature/115-bug-race-condition-in-timestamp-based-qu`](https://git.mokoconsulting.tech/MokoConsulting/MokoJoomCross/src/branch/feature/115-bug-race-condition-in-timestamp-based-qu) ```bash git fetch origin git checkout feature/115-bug-race-condition-in-timestamp-based-qu ```

jmiller referenced this issue from a commit

2026-06-06 14:33:22 +00:00

security: fix 9 security and critical bugs (#107-#115, #120)

jmiller closed this issue

2026-06-06 14:35:11 +00:00

Sign in to join this conversation.

Type —

Status —

Priority —

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoJoomCross#115