The $100M Balancer Exploit Could Have Been Prevented

Our system flagged the same vulnerability days before it was exploited.

Yesterday, Balancer suffered a major exploit that drained over $100 million in funds. The attack stemmed from a flaw in how the Vault handled callbacks and authorization, a reentrancy-like logic issue rather than a looping attack.

Our system had previously flagged this vulnerability pattern in Balancer’s Vault codebase before the exploit (October 2025 scan).

DD.xyz’s source code analyzer flagged multiple high-severity risks, including:

• Reentrancy vulnerabilities in manageUserBalance(), swap(), and _joinOrExit().
• Authorization check weaknesses, where the Vault trusted user-supplied sender parameters instead of validating msg.sender.
• Unchecked low-level calls and malicious boolean checks that could allow privilege escalation and fund drains.

This combination of flaws created a perfect storm: the Vault accepted operations that should have required explicit permission, and due to Balancer’s composable pool design, the effects cascaded across multiple pools once the attacker’s contract gained access.

🧩 Root Cause

The vulnerability originated in how Balancer validated user operations.
validateUserBalanceOp() and manageUserBalance() relied on sender-supplied data rather than verifying whether the caller (msg.sender) had the authority to perform internal balance operations.

This oversight allowed attackers to inject unauthorized WITHDRAW_INTERNAL and DEPOSIT_INTERNAL calls. When coupled with reentrancy entry points, this opened the door to unauthorized fund movements across the Vault system.

Unlike older looping-style reentrancy bugs, this was a context injection attack: exploiting initialization contexts where permission checks were bypassed — a pattern our system is uniquely designed to catch.

🧠 What DD.xyz Detected (Before the Hack)

Our detectors identified the following major red flags on October 22, 2025:

• Reentrancy Vulnerability: in manageUserBalance, swap, and batchSwap functions.
• Malicious Boolean Checks: particularly around internal balance flags (fromInternalBalance, toInternalBalance).
• Unchecked External Calls: to user-supplied contracts and recipients.
• Authorization Risks: improper use of _transferInternalBalance and _withdrawFromInternalBalance.

If these alerts had been acted on, Balancer could have patched the contract before the attack occurred.

⚙️ Why This Matters

This exploit underscores a growing truth: contract security is not static.
The combination of composability, dynamic internal balances, and protocol upgrades means risk evolves daily and no one-off audit can keep up.

At DD.xyz, we continuously monitor source code and on-chain behavior to detect these classes of vulnerabilities before they become exploits. Our static and dynamic analysis engines combine semantic code reasoning with runtime heuristics, making it possible to catch authorization and reentrancy misconfigurations early, during development, not post-mortem.

💡 The Lesson

This wasn’t a black swan.
It was detectable, explainable, and preventable.

Security isn’t about luck: it’s about decisioning.

If Balancer had integrated DD.xyz’s continuous risk engine, this incident could have been avoided. Automated (real-time, regular, frequent) auditing is the future. It is the only solution for the scale of smart contracts being deployed. At the very least, the industry should be combining automation with manual audits to increase the overall probability of safer systems.

To learn how Webacy DD's detection engine can help your protocol or infrastructure partner avoid these kinds of risks, visit dd.xyz or contact us.