The Priors advisory identifies a wallet-state race in @priors/mcp 0.2.3 through 0.18.1. A process compared Date.now() with a lock file's modification time to decide whether another writer was stale. A forward clock movement exceeding ten seconds, or sufficiently skewed storage time, could make a live owner appear abandoned. A second writer could remove the…
Case · DiggingBeagle record
Priors clock skew could discard a live payment-state lock
A forward clock step or skewed filesystem timestamp could allow concurrent writers to lose an unsettled purchase record. The disclosed duplicate-payment path requires unusual timing, and the repair retains a documented unlocked fallback.
Public disclosure: Nov 7, 2026
Scope
Vulnerability reported in a controlled research or disclosure setting. Exact prerequisites, versions and absence of documented exploitation must be preserved.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- WITH AI
Basis and provenance
The cited first-party advisory or research establishes the stated mechanism only within its documented conditions. No unrelated production compromise, extended victim scope, financial harm or universal mitigation is inferred.
Assessed Nov 9, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-PRIORS-CLOCK-LOCK · Priors MCP stale lock clock-skew duplicate payment advisory
At a glance
Idempotent purchase and ledger accounting require transactional concurrency guarantees rather than wall-clock-expiry assumptions.
Read the implicationsPriors rates the outcome low and requires unusual concurrent timing and clock conditions; no field duplicate payment established.
Limits and uncertaintyFull account
The Priors advisory identifies a wallet-state race in @priors/mcp 0.2.3 through 0.18.1. A process compared Date.now() with a lock file's modification time to decide whether another writer was stale. A forward clock movement exceeding ten seconds, or sufficiently skewed storage time, could make a live owner appear abandoned.
A second writer could remove the lock while the original owner was still active, and the original cleanup could remove the replacement. Concurrent updates could then lose an unsettled x402 purchase entry. A later retry might sign another payment because the original pending purchase was no longer recorded.
Patch scope and residual behavior
Version 0.18.2 changes ownership tracking and elapsed-time handling. The advisory nevertheless documents a fallback that can proceed after two seconds without the lock. The repair is therefore not evidence of transactional serialization under every process or storage failure.
Priors rates this issue Low because the clock and concurrency conditions depend on an unusual local setup. That rating is distinct from the consequence once a duplicate signature occurs. No field duplicate payment or customer loss was established. This state-file race is a different mechanism from the AgentKit response-stream retry disclosure.
Mechanism and trust boundary
- 01
An agent-wallet installation runs concurrent wallet requests with shared state tracking unsettled x402 purchases.
- 02
Clock skew causes one session to remove a live lock before its previous owner finishes.
- 03
Unserialized state updates may lose the original unsettled purchase record and a later retry signs another payment.
Claims & evidence
CLM-PRIORS-CLOCK-LOCKPriors identifies a race in @priors/mcp 0.2.3 through 0.18.1 where Date.now and mtimeMs could mistake a live lock for a stale lock; version 0.18.2 changes lock ownership and timing.supported
Basis: reported finding
- supportsPriors MCP stale lock clock-skew duplicate payment advisoryvendor statement
GHSA-wqww-vjpx-w8mq, Affected versions, Patched versions and Status
CLM-ENR231-PRIORS-LOCK-RESIDUALThe Priors advisory reports that the 0.18.2 lock repair tracks ownership and monotonic elapsed time, but its documented fallback can still proceed after two seconds without the lock.supported
Basis: reported finding
- supportsPriors MCP stale lock clock-skew duplicate payment advisoryvendor statement
Status and Summary, fixed 0.18.2 mechanism and two-second fallback
Implications
Idempotent purchase and ledger accounting require transactional concurrency guarantees rather than wall-clock-expiry assumptions.
Controls and mitigations
- Upgrade to the patched MCP implementation and independently enforce purchase idempotency at payment commitment.
Unknowns and contradictions
- Priors rates the outcome low and requires unusual concurrent timing and clock conditions; no field duplicate payment established.
Sources and citation
Material revision history
- Nov 9, 2026 · Published version · first publication · revision 233