It's a reentry bug - native ETH always calls the recipient contract's code on transfer, which can call back into the current function. If you manage native ETH

It's a reentry bug - native ETH always calls the recipient contract's code on transfer, which can call back into the current function. If you manage native ETH do accounting in the wrong order, you can "withdraw" multiple times. It doesn't "go missing", presumably the hacker will drain it into Bitcoin via any anonymous exchange accounts they have. Everyone loses big time (except the attacker if they manage to launder some of the coins). Watch for a wave of rebranding. > How severe could this attack be - does it pose an existential threat to The DAO (or Ethereum, more broadly)? We will see. The group behind TheDAO has a lot of pull - if Ethereum successfully rejects calls for a hard fork that will damage it severely in the public's eye, but will be the ultimate proof of concept. > How is this attack being perpetrated? Has the attack vector been previously anticipated? Why is this unexpected? Why, take a look: https://blog.slock.it/no-dao-funds-at-risk-following-the-ethereum-smart-contract-recursive-call-bug-discovery-29f482d348b#.skdl752nu https://blog.slock.it/no-dao-funds-at-risk-following-the-eth... Copied: """ No DAO funds at risk following the Ethereum smart contract ‘recursive call’ bug discovery Our team is blessed to have Dr. Christian Reitwießner, Father of Solidity, as its Advisor. During the early development of the DAO Framework 1.1 and thanks to his guidance we were made aware of a generic vulnerability common to all Ethereum smart contracts. We promptly circumvented this so-called “recursive call vulnerability” or “race to empty” from the DAO Framework 1.1 as can be seen on line 580: // we are setting this here before the CALL() value transfer to // assure that in the case of a malicious recipient contract trying // to call executeProposal() recursively money can’t be transferred // multiple times out of the DAO p.proposalPassed = true; Three days ago this design vulnerability potential was raised in a blog post which subsequently led to the discovery of such an issue in an unrelated project, MakerDAO. This was highlighted in a reddit post, with MakerDAO being able to drain their own funds safely before the vulnerability could be exploited. Around 12 hours ago user Eththrowa on the DAOHub Forum spotted that while we had identified the vulnerability in one aspect of the DAO Framework, the existing (and deployed) DAO reward account mechanism was affected. His message and our prompt confirmation can be found here. We issued a fix immediately as part of the DAO Framework 1.1 milestone. The important takeaway from this is: as there is no ether whatsoever in the DAO’s rewards account — this is NOT an issue that is putting any DAO funds at risk today. """