TL;DR

DeFi “money legos” make integrations one of the biggest attack surfaces in Web3, not just a convenience layer.
bZx, Mango Markets and Euler Finance all failed at the integration level: prices, markets and hooks behaved “as designed” but combined into exploitable systems.
The recurring mistake is treating local safety (per contract or module) as global safety, with no one owning the invariants that span protocols.
Composability needs its own threat-model, runtime checks and incident playbooks, just like your core contracts.

1. “Money legos” and the blind spot in most threat models

Composability is the thing everyone fell in love with in DeFi. You can deposit into a lending protocol, borrow against that position, route trades across multiple DEXes, stake LP tokens elsewhere, and have it all execute atomically. Each protocol exposes a clean interface; other protocols plug in and build on top.

The mental picture is a table covered in lego bricks. Each brick is robust; the fun is in stacking them. The security reality is different. Once real value flows through the stack, the stability of the structure depends less on the quality of individual bricks and more on the joints between them. Any time you say “we use this DEX as a price feed,” “we trust this oracle network,” or “we rely on this bridge for finality,” you are importing another system’s entire threat surface into yours.

Most teams still treat those joints as glue, not as first-class security objects. Their audits focus on their own contracts; the rest is hand-waved as “battle-tested.” Attackers don’t care where your audit boundary ends. They reason in terms of the whole composed system: where prices come from, how they propagate, how leverage is computed, and where they can turn a brief distortion into permanent profit.

Three incidents bZx in 2020, Mango Markets in 2022 and Euler Finance in 2023 show this pattern clearly. None of them relied on broken cryptography. All of them exploited assumptions that only exist at the integration level.

2. bZx: when “just use Uniswap” became a price oracle

In early 2020, lending and margin protocol bZx (via Fulcrum) was hit by a flash-loan-powered attack that netted attackers on the order of hundreds of thousands of dollars in profit in a single transaction; later analyses put one of the early exploits around $630k.

bZx’s core idea was straightforward: margin trading and lending built on top of existing on-chain liquidity. For price discovery, it leaned on Uniswap. To value collateral and compute liquidations, the protocol pulled a spot price from a Uniswap pool and treated that as “the price.”

From inside bZx, this looked reasonable. Uniswap was widely used, open and transparent. But Uniswap is not an oracle; it is a constant-product AMM whose price can be moved cheaply if you bring enough capital. Flash loans made that capital trivial to borrow for a few blocks.

The attacker’s playbook was simple and brutal: borrow a large amount via flash loan, swing the Uniswap pool price, interact with bZx while that distorted price was in effect, then unwind the manipulation and repay the loan in the same transaction. Uniswap did exactly what it was designed to do. bZx did exactly what its code said. The vulnerability lived in the assumption that “Uniswap spot price ≈ robust oracle.”

This is the first composability lesson in its purest form: a “battle-tested” integration point was given more trust than its design justified. The risk didn’t live in a missing require inside bZx, it lived in the unspoken belief that external liquidity could double as a secure oracle.

3. Mango Markets: self-referential loops between markets, oracles and collateral

In October 2022, Solana-based Mango Markets lost roughly $116–118 million when an attacker manipulated the price of its governance token MNGO and used that inflated value as collateral to drain the protocol.

Mango combined several components:

spot and perpetual futures markets for MNGO,
an oracle that consumed prices from those and other venues,
a lending engine that treated MNGO as acceptable collateral.

Each component made sense in isolation. Markets reflected supply and demand, the oracle observed those markets, and the risk engine used the oracle to mark collateral to market. The exploit came from how tightly those pieces were coupled around a thinly traded asset that the attacker could control.

By building a large MNGO position and then aggressively buying MNGO on the venues the oracle watched, the attacker pushed the reported price sharply upward. The oracle, doing its job, dutifully reported the new high price. Mango’s risk engine suddenly believed the attacker’s MNGO collateral was worth an enormous amount and allowed huge borrowing of USDC and other assets against it. When the attacker stopped supporting the price, MNGO collapsed, the oracle followed it down, and Mango was left with massive bad debt and empty pools.

Again, no single contract looks “egregiously broken” if you only read it in isolation. The markets cleared; the oracle reported what it saw; the lending logic followed its rules. The global invariant that actually matters. “no borrower should be able to control both the price and the collateral for a huge position” had never been formalized or enforced. Research into oracle manipulation later estimated that in 2022 alone, DeFi protocols lost over $400 million in 41 separate oracle-manipulation attacks, underscoring how common this pattern has become.

This is composability as an attack surface again: not one broken brick, but a self-referential loop the attacker could dominate.

4. Euler Finance: internal composability amplifying a small gap

Euler Finance, a permissionless lending protocol on Ethereum, was designed from the ground up for capital efficiency and composability. It introduced eTokens and dTokens to represent deposits and debts, configurable risk parameters and powerful hooks that allowed integrations and advanced behaviours like donating to reserves. In March 2023, it was exploited via a flash-loan-driven sequence that drained roughly $197–199 million across USDC, DAI, WBTC and stETH.

The root issue was a missing health-factor check in a specific code path. On paper, that sounds like a classic logic bug. In practice, that bug only became a nine-figure incident because Euler’s composable design let sophisticated users chain features together in complex ways.

The attacker borrowed a large amount using flash loans, deposited and borrowed assets across multiple Euler markets, and then used the donateToReserve and liquidation mechanisms in a carefully chosen sequence to manipulate how the protocol accounted for debt and collateral. Because the missing check did not re-validate collateralization in that particular path, the attacker could push positions into unhealthy territory and still extract value.

What turned this into a composability failure is how Euler’s own abstractions magnified the effect. The same internal tokens and hooks that made it easy for integrators and advanced users to build strategies also gave the attacker many opportunities to “rewire” flows inside the protocol. The vulnerable pattern lived in the interaction of features, not in a single obvious “if/else.”

Post-incident, Euler handled communication and negotiation with the attacker in an unusually professional way and ultimately recovered a large portion of the funds. But from a security-design perspective, the lesson is that highly composable internal architectures need the same integration-level threat modeling you would apply to external dependencies.

5. The recurring failure: local safety ≠ global safety

Across bZx, Mango and Euler, the same story keeps repeating.

Locally, everything appears fine. Uniswap executes swaps and sets prices according to its invariant. Mango’s markets and oracle pipelines do what they were configured to do. Euler’s hooks and token abstractions behave as specified. Global safety fails because no one is accountable for the behaviour of the whole composed system under adversarial conditions.

In all three cases, teams treated “battle-tested” components as if they were safe to trust at protocol level. Uniswap was used as a price oracle, not just a venue. Mango’s own markets were allowed to dictate collateral values for huge loans in the same system. Euler’s internal extensions were treated as neutral flexibility, not as potential exploit gadgets.

The data backs up how costly that mindset has been. Chainalysis has estimated that DeFi hacks drove more than $3.1 billion in stolen crypto in 2022 alone, with hundreds of millions attributed specifically to oracle and data-manipulation issues. Academic and industry analyses point out the same pattern: attackers don’t need to break base-layer cryptography when they can cheaply distort inputs that protocols treat as ground truth.

From a design standpoint, the core mistake is simple: teams prove local invariants (“this function never underflows,” “this market keeps reserves in balance”) but leave global invariants (“a single actor can’t cheaply control their own collateral value,” “external prices can’t move our risk engine into absurd regimes”) either implicit or entirely unexamined.

6. Turning composability into a security discipline

If you want the upside of composability, you have to treat integration risk as a first-class part of your security program.

That starts at design time. When you plug into a DEX, an oracle, a bridge or another lending protocol, you need to be explicit about what you believe and why. Are you treating a spot price as a hint or as a source of authority? Under what conditions do you consider that input untrustworthy? How cheaply could an attacker move it for a few blocks with flash loans or thin liquidity?

It continues with how you structure your own features. Hooks, callbacks and internal tokens should be assumed dangerous until proven otherwise. The question is not “can integrators do powerful things with this?” but also “can an attacker chain this with other behaviours to break our global invariants?” Running adversarial design sessions where you pretend to be the attacker with unlimited scripting ability and access to every integration often reveals sequences nobody considered when features were added one by one.

Finally, it shows up in operations. Monitoring should not just ask “is this contract being called a lot?” but “are we seeing patterns of behaviour that match known exploit classes?” Sudden, extreme price swings on a collateral asset, abnormal use of hooks, or one address cycling huge amounts of capital through several markets in a single block are all signals you want surfaced quickly. Combined with clear pause/runbook policies, those signals can be the difference between an incident measured in minutes and a loss measured in nine figures.

How Exploitless approaches composability risk in audits

At Exploitless, our entire focus is smart contract and protocol security audits. When we audit a system, we never look at contracts in isolation; we treat composability and integrations as core parts of the audit scope, not background noise.

Practically, that means we map how your protocol talks to the rest of Web3: which DEXes you rely on for prices, which oracle feeds you consume, which bridges or messaging layers you trust, and how your own tokens, hooks and modules can be composed by other protocols. We then ask a simple but uncomfortable question: what happens if an attacker fully understands and abuses these connections? Incidents like bZx, Mango and Euler become test cases we replay in your design, not just stories in a report.

Our audit reports reflect that approach. We don’t just flag local bugs in a single function; we call out integration assumptions, cross-module invariants and composability risks that could turn “battle-tested” dependencies into your weakest point. For teams building in an ecosystem of “money legos”, the goal of an Exploitless audit is straightforward: to surface the ways integrations can break your safety model before attackers discover them, and to give you clear, prioritised findings you can act on.

If you’re shipping or upgrading a protocol and want your next audit to explicitly stress-test the way you plug into the rest of Web3 not just your internal logic this is exactly the lens we bring at Exploitless.

Learn more at Exploitless

References

bZx / Fulcrum oracle-manipulation & flash-loan exploits Technical breakdown and timeline of the early 2020 bZx attacks and how Uniswap spot pricing was abused as an implicit oracle. (Immunebytes “bZx Protocol Exploit Sep 14, 2020: Detailed Analysis”)
Systemic and composability risk in DeFi Research paper discussing how protocol inter-connections and “money lego” patterns create new systemic risks beyond individual contract bugs. (PMC “Decentralized Finance: On Blockchain- and Smart Contract-Based Financial Markets”)
Mango Markets exploit and bad-debt creation Analysis of the October 2022 Mango oracle-manipulation attack (~$116–118M), showing how self-referential markets, oracles and collateral rules interacted. (Elliptic “Mango Market Exploit: DeFi Loses Nearly $900m to Hackers in Costliest 30 Days on Record”)
Oracle & data-manipulation attacks statistics Overview of oracle manipulation as a growing exploit class, including aggregate loss figures for 2022 and example incidents across DeFi. (Chainalysis “Oracle Manipulation Attacks Are on the Rise”)
Euler Finance flash-loan attack Detailed explanation of the March 2023 Euler exploit (~$197–199M), focusing on capital-efficiency features, hooks, and the missing health-factor check that enabled the attack path. (Chainalysis “The Euler Finance Flash Loan Attack Explained”)
DeFi composability and cross-protocol vulnerabilities Academic/industry discussion of how integrations, shared libraries, and protocol dependencies expand the DeFi attack surface. (arXiv recent work on DeFi security and composability)

Composability as an Attack Surface: How Integrations Break “Battle-Tested” Protocols