The validity store treats a transaction with stored block number = X as "in window" only when X > last bn - transaction validity window blocks (strict inequality). However the protocol's Transaction::is valid at accepts a transaction for inclusion in any block in [validity start height - blocks per batch, validity start height + window - 1]. By choosing validity start height = X + blocks per batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity start height + window, i.e., a contiguous window of blocks per batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.

No known workarounds