TENDRIL sell-hook exploit drains about $555,000 in USDT

An exploit in TENDRIL’s sell hook produced an estimated net loss of about $555,000 on November 5, 2026, ExVul and ScaleBit said, after an attacker withdrew nearly all the USDT from the token’s PancakeSwap V2 pool on BNB Chain.

ExVul and ScaleBit issued public alerts on November 5, 2026. Their disclosures included the vulnerable token contract, the affected pair address and relevant transaction data, giving other researchers a traceable record of the incident.

The attacker targeted the TENDRIL/USDT liquidity pool on PancakeSwap V2. Security researchers traced calls including PoolControl.sellToken, paired with a controlled burn operation that manipulated the pool’s reserves before external transfers had finished executing.

How did the sell hook drain the pool?

The vulnerable transaction sequence gave the attacker control over the balance inputs used to price the sale. The disclosures indicate that the contract allowed reserve figures to change while the transaction remained in progress.

The attack unfolded in four observable steps:

• The sale entered PoolControl.sellToken and reached a controlled burn operation.
• The burn altered the reserve figures relied upon by PancakeSwap’s automated market maker.
• The changed ratio made TENDRIL appear more valuable relative to USDT than the underlying balances justified.
• The attacker then withdrew nearly the entire pool’s USDT balance.

This sequence resembled changing the denominator in a price calculation before the underlying transaction settled. Automated market makers price assets against the ratio of tokens held in each pool, so a manipulated reserve count can make one side appear cheaper to withdraw.

The contract therefore overrode the protection that AMM pricing ordinarily provides liquidity providers. Rather than the pricing formula misreading unchanged balances, the attacker changed the balances themselves and exploited the resulting false ratio.

On-chain data also shows the attacker sent 30,000 USDT to a hardcoded beneficiary address during the exploit. The supplied disclosures do not name the beneficiary or identify the attacker, so the transfer establishes a destination without providing legal attribution.

Why do the loss estimates differ?

The report’s headline estimate places the net loss at about $555,000, while other research findings cite roughly $550,000 in USDT drained in total. Monitoring service TenArmorAlert initially reported losses of approximately $309,000.

Those figures do not necessarily measure an identical quantity. The report identifies a pool’s total drained balance, the attacker’s proceeds after costs and victims’ net loss as separate accounting bases that can produce different totals from the same transactions.

The available material does not assign every estimate to one precise methodology. Users comparing the figures should therefore distinguish gross amounts removed from the pool, attacker profit and the loss calculated for token holders.

CertiK now tracks the TENDRIL drain through its Web3 security dashboard, which records losses, attack vectors and chain-level risk across quarters. The incident joins the dashboard’s running tally for the second half of 2026.

What does the exploit change for holders and liquidity providers?

For TENDRIL holders, the immediate constraint is exit liquidity. With nearly all USDT withdrawn, very little remains on the pool’s USDT side to absorb sales. Without restored USDT depth, a contract change alone would not restore meaningful selling capacity.

For liquidity providers, a well-audited exchange cannot protect a pool from a token that rewrites its own reserves. An audit can establish how the exchange operates, but it cannot make reserve-changing token logic safe when that logic enters the pricing process.

The affected pool consequently faces concentrated risk on the TENDRIL side of the pair. The operational problem extends beyond the reported dollar loss: market participants have little pool liquidity available for orderly exits.

What must builders change before comparable tokens return?

The wider BNB Chain pattern is familiar. Developers add tax, burn or reflection logic to standard token templates to create distinctive tokenomics, and each modification introduces code paths that interact with an AMM in ways the original template did not anticipate.

Sell hooks and burn functions that touch pool balances must enforce strict ordering. State changes should occur only after external transfers complete, preventing the pool from pricing or settling a trade against reserve figures altered during execution.

TENDRIL appears to have failed precisely that sequencing check. The exploit turned on transaction ordering, a class of issue that independent audits are designed to identify before deployment.

TENDRIL had little visibility before the incident, but the attack illustrates a broader operational risk for customized assets. Liquidity providers cannot treat an audited AMM as protection against flawed logic inside the token contract it prices.

No remediation deadline or enforcement timetable accompanied the disclosures. The next market-structure checkpoint is restored USDT depth: without it, the remaining pool cannot absorb material TENDRIL sells, while builders must correct reserve-update ordering before comparable tokens can carry meaningful liquidity.