DeFi Lending Protocols: Attack Vectors and How to Secure Them

Lending Pools

Lenders deposit assets into a lending pool and receive a token representing their share, which grows as interest accrues. Borrowers draw from the same pool. Interest rates follow utilization: the larger the share of a pool that is lent out, the higher the rate, which draws in more deposits and discourages further borrowing.

Collateral and Borrowing Limits

Borrowing is overcollateralized. A borrower deposits one asset and borrows another worth less than the deposit. Each collateral asset has a loan-to-value (LTV) ratio that sets how much can be borrowed against it: with an LTV of 75%, $1,000 of collateral supports up to $750 of debt. Riskier or less liquid assets get lower ratios, and some cannot be used as collateral at all.

Liquidations

If collateral loses value or debt grows, a position can cross its liquidation threshold, which sits slightly above the LTV. At that point, anyone can repay part of the debt and receive the borrower's collateral at a discount. That discount is what pays liquidators, and in return they keep the pool solvent by closing risky positions before the debt exceeds the collateral.

Price Oracles

None of this works without prices. The protocol needs to know what collateral and debt are worth at every moment, and it gets those numbers from price oracles. Every borrowing limit and every liquidation is calculated from the oracle price, which makes the oracle one of the most sensitive parts of the system.

Seen from an attacker's side, the design has one underlying weakness. The protocol trusts its own records, its price feeds, and the value of the collateral it accepts. If any of those can be made wrong, even for a single transaction, the protocol will lend real assets against a false number. Each of the vectors below is a different way of doing that.

Oracle Manipulation

Oracles play a vital role by acting as bridges between the blockchain and the external world, importing data that is necessary for various smart contract functions. But they are also a common point of vulnerability. Attackers can manipulate oracles by feeding them erroneous data. This might be done by either directly compromising the oracle’s data sources or by exerting market pressure in places the oracle derives its data from. This false data can lead to wrongful liquidations, inaccurate interest rate calculations, or other unintended financial outcomes, putting user funds at significant risk.

Liquidity Attacks

By artificially manipulating the liquidity in these pools, attackers can influence loan value and liquidation thresholds. This might be achieved by sudden withdrawals, depositing malicious tokens, or exploiting pool creation mechanisms. Such manipulations can significantly destabilize a protocol and cause losses for lenders or borrowers.

Reentrancy and Callbacks

Some contracts notify you when something happens, such as when tokens arrive in your account. That notification is called a callback, and it hands control back to you while the other contract is still partway through its work. Reentrancy happens when the recipient calls back in before the first contract finishes.

The risk is that the protocol ends up acting on its own records before it has finished updating them. A borrower can be treated as owing nothing while already holding borrowed funds, and collateral can be valued using a figure that is only briefly wrong. In both cases, the protocol lends against numbers that do not reflect reality, and repeating it drains the pool.

Governance Attacks

Most lending protocols are not run by a company but by their token holders, who vote on how the protocol operates. Governance sets the terms the protocol enforces for everyone who uses it. Voting power is normally proportional to tokens held, and those tokens can be bought or borrowed, so control over a protocol is something that can be acquired rather than earned.

The risk is that control reaches someone whose interest is in extracting value rather than running the protocol well. Since governance decides the rules, whoever holds it can rewrite those rules in their own favour, and the protocol will then operate exactly as instructed.

Peg Failures

Stablecoins maintain their value by being pegged to stable assets, commonly the US dollar. However, if external market pressures, governance failures, or collateralization issues cause a stablecoin to lose its peg, it can result in significant cascading effects. Lending protocols relying on that stablecoin might see drastic imbalances in loan-to-value ratios, triggering a wave of unintended liquidations. This could also erode trust in the protocol, leading to rapid withdrawals and potential solvency issues.

The same applies to any token a protocol prices as equivalent to another asset, including liquid staking and restaking tokens that are expected to track ETH. If the backing behind such a token fails, the protocol may still value it at the old rate, and anyone holding the token can borrow against value that no longer exists.

A note on flash loans: several of the attacks above only work at scale, since moving a price, shifting the balance of a pool, or gathering voting power all call for large amounts of capital. Flash loans remove that barrier. They allow anyone to borrow a very large sum with no collateral, provided it is repaid within the same transaction, which means the capital these attacks need can be rented for the length of a single transaction. A flash loan is not a vulnerability in itself, but it decides who is able to exploit one.

Comprehensive Auditing

Before launching any protocol into the wild, it’s crucial to subject its code to rigorous scrutiny. Conducting multiple in-depth audits from reputable firms ensures that various perspectives evaluate the code for vulnerabilities. Post-launch audits are equally important, given that live environments might expose issues that theoretical checks missed.

Treat each smart contract audit as a review of the code in scope at one point in time. The Curve pool that dForce used as a price source was outside its audit's scope, and that dependency is where the exploit came in. Re-audit after every upgrade, new market, or new integration, and include the external contracts the protocol relies on for prices.

Testing

Maintain a test suite that runs on every change. Include tests that throw unexpected values at the contracts to find cases no one thought to check, and rules that must always hold true, such as a position never being able to borrow beyond its collateral limit. Run the full suite again after every upgrade.

Decentralized and Secure Oracle Systems

Given the vulnerabilities tied to oracles, diversifying data sources is vital. Decentralized oracles, which aggregate data from multiple sources, reduce the risk of manipulation. By ensuring no single point of failure, protocols can trust the data they operate on more confidently.

Prefer prices that cannot be moved within a single transaction, such as time-weighted averages or aggregated feeds, over the spot price of one pool. UwU Lend read an instantaneous Curve price with no smoothing, and an attacker moved it with flash-loaned capital. Set bounds on how far a price can move between updates, and treat a sudden large move as a reason to pause rather than to lend.

Collateral Listing and Risk Parameters

Every asset a protocol accepts as collateral brings its own risks with it. Before listing one, check how deep its market is, how its price is sourced, and what its value depends on. A thinly traded token can be pushed far above its real value with little capital: Tectonic accepted TONIC at a 20% collateral ratio while it traded about $305,000 a week, and lost roughly $75 million when its price was driven up around 100 times. Wrapped, staked, and bridged tokens add another layer, because their value rests on contracts the lending protocol does not control. Aave's rsETH losses came from a bridge exploit at Kelp DAO, not from Aave's own code.

Practical limits help: supply and borrow caps sized to each asset's real liquidity, lower ratios for volatile or thinly traded assets, isolated markets for new or risky collateral, and a seed deposit for every new market so it is never empty and open to donation attacks like the one against Sonne Finance.

Rate Limiting and Delay Mechanisms

Some safeguards work by slowing things down. Caps on how much of an asset can be deposited or borrowed within a set period limit how quickly a protocol can be drained. After the Kelp DAO exploit, Aave's founder suggested that pooled lending protocols would benefit from a rate limit on the supply of collateral assets. Time delays on governance decisions and parameter changes give users and security teams a window to review a change before it takes effect, which is the main defence against governance attacks.

Delays do not stop attacks that complete inside a single transaction, so they complement oracle and collateral controls rather than replace them. They also make plans public in advance: Sonne Finance queued the launch of its new market behind a timelock, and the attacker used the queued transactions to open and exploit the market before Sonne's protections were in place.

Key Management and Admin Controls

Not every loss comes from a bug. In October 2024, attackers compromised the devices of three Radiant Capital multisig signers, which was enough to meet its 3-of-11 threshold, took control of its lending pool contracts, and drained about $50 million. Use a high signing threshold for admin keys, dedicated signing hardware, independent verification of what each transaction does before it is signed, and a timelock on upgrades so that a compromised key cannot change the protocol instantly.

Monitoring and Incident Response

Most exploits are visible on-chain as they unfold. Watch for unusual borrowing, sudden changes in collateral values, positions that should have been liquidated but were not, and unexpected calls to admin functions. Have a plan ready beforehand: the ability to pause affected markets, a named group who can authorise it, and a way to reach users quickly.

Insurance and Coverage

Even with the best safeguards, there’s always some residual risk. Integrating with established DeFi insurance protocols or creating dedicated internal insurance pools can provide a safety net. This ensures that users are compensated and retained, even in the unfortunate event of a security breach.

Size coverage against realistic losses. After the Kelp DAO exploit, Aave's Umbrella fund held about $50 million against roughly $196 million in bad debt.

Bug Bounty Platform

Harnessing the collective intelligence of the global ethical hacking community can be invaluable. By setting up bug bounty programs, protocols can encourage continuous and crowdsourced vulnerability assessments. Ethical hackers, in their pursuit of bounties, can expose weaknesses that might be overlooked even by comprehensive audits, ensuring that protocols remain robust and secure over time.

How do DeFi lending protocols work?

Lenders deposit assets into shared pools and earn interest set by how much of each pool is borrowed. Borrowers post collateral worth more than their loan, and if its value falls past a set threshold, the position is liquidated so the pool stays solvent. Smart contracts run all of this automatically, using price oracles to value collateral and debt.

What is the biggest security risk for DeFi lending protocols?

Mispriced collateral. Whether through oracle manipulation, a thinly traded token pumped for a few minutes, or a wrapped token that lost its backing, most large lending losses come from a protocol lending real assets against collateral worth less than it believes. Compromised admin keys are the other major risk, since they bypass the code entirely.

How can lending protocols safely accept wrapped and staked tokens as collateral?

Treat each one as a dependency, not just an asset. Price it from its actual redemption value or market price rather than assuming it equals the underlying asset, cap how much can be supplied, use conservative ratios, and keep the ability to freeze the market quickly. The Kelp DAO incident shows why: Aave treated rsETH as ETH-correlated collateral, and when Kelp's bridge was exploited, unbacked rsETH was used to borrow real ETH.

How do lending protocols verify the backing of tokenized assets used as collateral?

Through the token's own on-chain accounting where possible, proof-of-reserve feeds for assets backed off-chain or on other chains, and monitoring that compares the supply on each chain with the reserves behind it. Verification is only as reliable as the source it reads from, so protocols should also limit their exposure to any single tokenized asset in case that source fails.

What are isolated lending markets?

Markets where each collateral and borrow pair has its own pool and risk settings, so a problem with one asset cannot drain lenders in other markets. They let a protocol list newer or riskier collateral without putting the whole protocol at stake, at the cost of splitting liquidity across many smaller markets.

Is an audited lending protocol safe?

An audit lowers risk but does not remove it. It reviews the code in scope at one point in time, while many exploits come from outside that scope: price sources, integrations, new markets, or keys. Hacken's Q1 2026 report found six audited protocols among the quarter's victims, one with 18 prior audits. Audits work best combined with testing, monitoring, and a bug bounty program that keeps the code under review after launch.