A replay attack exploits the fact that, immediately after a hard fork, both resulting blockchains share an identical transaction history up to the split block and often use the same address format and signature scheme. A transaction broadcast on one chain can therefore still look perfectly valid to the other chain's nodes, so the same signed transaction gets "replayed" and confirmed twice, once on each ledger, without the sender's consent.
The best-known case is the 2016 split between Ethereum and Ethereum Classic after the DAO hack rollback: because neither chain initially tagged transactions as belonging to one network or the other, a payment made on Ethereum could be copied and rebroadcast on Ethereum Classic, and vice versa, draining balances the sender never meant to move. Developers responded with strong or opt-in replay protection: unique chain identifiers embedded in each transaction (such as Ethereum's EIP-155 chain ID, or Bitcoin Cash's SIGHASH_FORKID flag added during its 2017 split from Bitcoin) that make a transaction signed for one network cryptographically invalid on the other.
Not every fork implements this safeguard. Some later splits, where both camps claimed to be the legitimate continuation, launched without replay protection on either side. Anyone claiming coins from a new fork should therefore first confirm protection exists, or manually separate holdings using specialized "splitter" tools, before moving any funds.