AIKIDO-2026-198254

TL;DR

The Kysely adapter's guarded delete and update paths select matching row IDs under the caller supplied guard condition, then write to those IDs without re-checking the guard. A concurrent write to the same row between the select and the write can change which rows still match the guard, so the write runs against the now stale IDs and bypasses the condition it was meant to enforce. The fix re-applies the guard to the final delete and update query so it is checked again against the row's current state.