What made it click for me was that smart contracts are similar to stored procedures in db speak. So in this case someone wrote a smart contract/stored procedur

What made it click for me was that smart contracts are similar to stored procedures in db speak. So in this case someone wrote a smart contract/stored procedure that: - loan $a_lot_of_money from $defi_a - do something with $a_lot_of_money to confuse an oracle (e.g. a price feed) - exploit $defi_b who relies on above oracle data - return $a_lot_of_money to $defi_a This all happens in a single "db transaction" so as long as $defi_a receives its money back the tx is going to pass. If $defi_b relies on an oracle that takes it's data from on-chain, and thus is manipulatable with $a_lot_of_money, it is suspectible to those attacks. To counteract this, $defi_b could only rely on oracles that are secure against manipulation from $a_lot_of_money, but they don't always exist. This mechanism can be used for good (riskless arbitrage across decentralized exchange) or for bad exploits.