Inside the Fake-Jar Exploit That Drained 19.7M DAI From Pickle Finance

Pickle Finance's cDAI jar was drained of 19.7 million DAI through a vulnerability that allowed an attacker to substitute a counterfeit "Pickle Jar" into the protocol's swap logic, adding the project to the growing list of DeFi hacks that year.

What set this incident apart was the response that followed. As the news spread on Twitter, Rekt began looking into what had happened and reached out to the Stake Capital team, who reviewed the code and cautioned that additional jars could be exposed to the same flaw. Rekt then contacted Pickle Finance directly, and a joint effort quickly formed involving Stake Capital (@bneiluj, @vasa_develop), Yearn's @bantg, the Pickle Finance team, and independent developers @samczsun and @emilianobonassi.

The mechanism, not an arbitrage

Unlike the composability-driven exploits that had characterized several recent DeFi incidents, this attack reflected deep familiarity with Solidity and the EVM, and appeared to draw on close study of Yearn's codebase — the underlying flaw closely resembled one disclosed in Yearn's own contracts about a month prior.

Pickle Jars are structured as a fork of Yearn's yVaults and are governed by a Controller contract that includes a function permitting users to move assets between jars. That function, however, had no whitelist restricting which jars were valid destinations. The attacker exploited this gap by deploying a fraudulent Pickle Jar and using the unguarded swapExactJarForJar function to redirect funds out of the legitimate jar and into their own.

A race against the clock

Once alerted, the Pickle Finance team moved to cooperate fully with the investigating group. An attempted withdrawAll call failed, since withdrawal requests had to pass through the protocol's Governance DAO, which enforced a 12-hour timelock. Only one signer on the Pickle multisig held the ability to bypass that delay, and that person was asleep at the time — meaning the team could neither immediately empty the remaining jars nor guarantee they were safe from a repeat attack.

Pickle Finance and Curve both issued public warnings urging users to withdraw immediately, even as roughly $50 million sat in potentially exposed jars while the white-hat group worked to assess the risk. The rescue effort effectively had two options: wake the multisig member who could override the timelock, or find another way to secure the funds first.

The team identified five distinct problems that needed to be solved simultaneously:

1. Coordinating Pickle Finance team members across multiple time zones to push withdrawal transactions through the 12-hour timelock using 3-of-6 multisig approval.
2. Persuading thousands of depositors to withdraw their funds, while discouraging them from redepositing once the pool's total value locked fell and its advertised APY spiked above 1000%.
3. Auditing the remaining jars for similar vulnerabilities that could enable further attacks.
4. Reproducing the exploit internally and executing a white-hat version of it before anyone else could repeat the attack.
5. Completing the rescue of the last roughly $50,000 without being front-run.

The episode raises a recurring concern about the DeFi security model: recovery efforts of this kind depend heavily on the willingness of pseudonymous white-hat researchers to volunteer their time under pressure, even though the financial incentives point the other way — attackers profit directly, while defenders gain only reputation. That imbalance is not obviously sustainable, and it leaves open the question of how long researchers operating in this gray area will continue choosing disclosure and remediation over exploitation themselves.

On disclosure

The team weighed the risk that publishing a technical breakdown could invite copycat attacks. After discussing the tradeoffs with Pickle Finance and other developers, and confirming no known active forks of the Pickle codebase appeared vulnerable, they concluded that selective disclosure would create its own liability problems and opted to publish the technical details openly. Any project running a fork of Pickle's code was expected to already be aware of the incident and taking its own precautions.

An overview diagram of the exploit, produced by @vasa_develop, is available here, and a full technical post-mortem was published by the response team. Separately, it remained to be seen how Cover Protocol, a relatively new DeFi insurance product, would handle what stood to be its largest claim to date; the relevant snapshot vote is recorded here.

On audits and iteration speed

The incident also highlights the tension between the "move fast" ethos common in software development and the cost of failure in a financial system where mistakes are immediately and irreversibly monetized. A one-time audit offers, at best, a snapshot of a codebase's security at a single point in time — not a durable guarantee, particularly for protocols that continue to evolve after launch. In Pickle's case, audits performed by MixBytes (October 3rd) and Haechi (October 20th) both predated the addition of ControllerV4 on October 23rd, the contract update that introduced the vulnerable code path. Sustainable security in this environment likely requires audits to be treated as an ongoing, recurring process rather than a one-off milestone before deployment.

Update — July 18, 2021

Haechi later contacted Rekt to clarify the scope of its original audit, noting that it had reviewed part of Pickle's contracts, but that the vulnerable swapExactJarForJar function resided in controller-v4.sol, a contract added after Haechi's review, which had covered controller-v3.sol — a version that did not yet contain that function. Haechi pointed to two of its own posts for further detail: here and here.