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.

This might however require a reconsideration of the Proposal Framework 1.0 taking place before the deployment of a DAO Framework 1.1. We are currently assessing the situation and will update you via further posts throughout our investigation as to what the potential next step(s) will be.

We extend our gratitude to the community and in particular Eththrowa who once again proved that an open development process leads to the rapid identification, isolation and resolution of potential vulnerabilities, and in this case, the overall improvement of design patterns as part of programming languages.