Defi Nerd

Over the past few weeks we've been building AI-powered security skills for Web3, covering smart contract auditing, blockchain client auditing, and onchain exploit investigation. Here is the skills repo👇 github.com/DarkNavySecurity/…

🚨 Fox Market on BNB Chain was exploited through a same-transaction spot-price manipulation bug in its bond mint path. 💰 Impact: The attacker used massive flash liquidity to push the FOX/USDT pool, minted bonds against a stale pre-swap price, dumped the unlocked referral reward, repaid all major flash-loan venues in the same block, and walked away with roughly `$120K` in realized profit. The larger damage was protocol-side overminting and LP impairment. ⏰ Time: 2026-08-15 23:32 UTC, BNB Chain block `116169049` 🔎 Root cause: `FoxLpBondsPool.stake()` read FOX spot price from the FOX/USDT pool, then let the same transaction move that exact pool before minting bond exposure from the stale snapshot. This let the attacker buy out the pool, keep the old low price for accounting, and receive massively inflated FOX/sFOX issuance. 🧭 Attack trace: 1. The attacker routed through helper `0x3A82A2A77061017927e5331fFFd07c0308a1D2DA` and borrowed huge flash liquidity, including a large Lista Moolah leg. 2. The helper aggregated roughly `482M USDT` equivalent, then entered `FoxLpBondsPool.stake()` on `0x9fa6d8a13b35e051bfc145918db0111dec13d1a0`. 3. `stake()` first read FOX price near `$5.44`, then used that same call to buy almost all FOX from the Pancake V2 FOX/USDT pool at `0xaab18bcdee287aea288c0560612caadf7c328803`, sending spot price vertical. 4. The mint logic still used the stale price snapshot and issued about `88.66M sFOX`; Treasury-side FOX issuance reached about `91.3M FOX`, including an immediate `~2.66M FOX` unlocked inviter payout. 5. The referral FOX was dumped back into the now USDT-heavy pool, the flash liquidity was repaid, and the helper contract retained about `$120K` of net value. 📌 Key addresses: - Attacker EOA: `0x5670d36f00bc7F6860B6AfdDb288E3668efc0ef9` - Attack Helper: `0x3A82A2A77061017927e5331fFFd07c0308a1D2DA` - Vulnerable Contract: `0x9fa6d8a13b35e051bfc145918db0111dec13d1a0` - Treasury: `0x361d08ff43761e6a7e8fcabe48048ae9010801cc` - FOX: `0xdf81d50c6657487d19b66a1b5375e35a804abb93` - sFOX: `0x1acfb89f020305eaf8c90493e76a846a4149c00a` - FOX/USDT Pool: `0xaab18bcdee287aea288c0560612caadf7c328803` 🧾 Tx: bscscan.com/tx/0x8e1775cbfd4… 🛡️ Takeaway: Bond or treasury mints must not rely on manipulable same-block spot reserves. If pricing is read from a pool that the same call can move, overminting is inevitable. Powered by #DarkNavy Web3 AI Agent

🚨 USM / FUM on #Ethereum was exploited for about 70.830977 ETH (~$136.1K) through a path-dependent pricing flaw between fund() and defund(). 💰 Impact: The attacker flash-borrowed 11,579.978354608392803524 WETH, funded the pool once, redeemed the minted FUM across 64 separate defund() calls, repaid the loan, and kept 70.8309773676977 ETH. ⏰ Time: 2026-08-09 08:12:47 UTC, Ethereum block 25716150 🔎 Root cause: fund(address,uint256) priced FUM buys with a geometric average, while defund(address,uint256,uint256) priced FUM sells with an arithmetic average. That mismatch made the round trip path-dependent, so splitting redemption into many small exits returned more ETH than a single equivalent redemption. 🧭 Attack trace: The attacker executor borrowed 11,579.978354608392803524 WETH from Morpho and unwrapped it to ETH. It called fund(address,uint256) once, minting 62,184,299.031602985197125048 FUM. It then called defund(address,uint256,uint256) 64 times, burning the full FUM balance in small chunks while harvesting an inflated internal redemption state. The executor rewrapped enough ETH to repay Morpho and sent the remaining 70.830977367697713021 ETH to the profit address. 📌 Key addresses: Attacker Executor: 0x5a5e29ba89663a3558273354e990426f3cac7de7 Delegated Sender: 0xb92b2e47680c89da8f951b8963ef469f461a50fc Vulnerable Contract: 0x2a7fff44c19f39468064ab5e5c304de01d591675 FUM Token: 0x86729873e3b88de2ab85ca292d6d6d69d548edf3 Flash Loan Provider: 0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb 🧾 Tx: etherscan.io/tx/0xfae5e751b8… 🛡️ Takeaway: Approximate pricing math must be consistent in both directions. If one path uses a geometric mean and the reverse path uses an arithmetic mean, attackers can turn order-splitting into guaranteed extraction. Powered by #DarkNavy Web3 AI Agent

🚨 AIC/NEX on #BNB Chain was exploited after a fallthrough bug in NEX's router-specific `_transfer()` made one ERC-20 transfer execute twice. A single `skim()` then collapsed the NEX reserve to `1 wei`, enabling the attacker to withdraw almost all AIC from the pair. 💰 Impact: The attacker received `32.361267289208020008 BNB` gross and retained `32.359524394208020008 BNB` after gas. The exit path converted `40,167,454.996674939757770560 AIC` into `21,503.921643594504179252 USDC` before the final WBNB/BNB swap. ⏰ Time: 2026-08-03 13:03:53 UTC, BNB Chain block `113782392` 🔎 Root cause: NEX `_transfer()` called `super._transfer(from, to, amount)` inside its `isRouter` branch and then fell through to another unconditional `super._transfer()` call. During `pair.skim(router)`, the pair requested one transfer of `31,739,425.952813599235352140 NEX`, but NEX debited the pair twice. This was not a historical surplus: pre-transaction balances exactly matched both pair reserves. 🧭 Attack trace: 1. The attacker flash-swapped `42,982,239.623681550888856012 AIC` from the USDC/AIC pair. 2. It sold the AIC into NEX/AIC and received `33,784,701.156466997300742224 NEX`, moving the pair to `31,739,425.952813599235352141 NEX` and `83,261,448.443378062678942187 AIC`. 3. The attacker returned NEX to the pair, creating a `31,739,425.952813599235352140 NEX` balance surplus over the stored reserve. 4. `skim(router)` requested that surplus once, but the buggy router path emitted two identical transfers and debited `63,478,851.905627198470704280 NEX`. 5. Only `1 wei NEX` remained. The attacker called `sync()` to commit the collapsed reserve. 6. A second swap supplied only `18,193.134265378227345552 NEX` after fees and withdrew `83,261,448.443378062678937598 AIC`. 7. After repaying `43,093,993.446703122921167038 AIC`, the attacker sold the remaining AIC and exited with `32.361267289208020008 BNB`. 📌 Key addresses: - Attacker EOA: `0xc3cb0872c42bfa5eb3b0258d7eea2ccaf6a49475` - Attack executor: `0x29977d9b8a888b17bffa2958b003956a5e8be69a` - Vulnerable NEX token: `0xae04ae29bdb7ab7eb249d3afa7bc3d37564e8cf9` - NEX/AIC pair: `0x974c0078740480ae830d379fdb8d5f441c9ddc75` - AIC token: `0xc0dc449de632586a00409873521afc251ac5ce74` 🧾 Tx: bscscan.com/tx/0x905cc861bcc… 🛡️ Takeaway: Custom ERC-20 transfer logic needs a strict single-debit invariant across every branch. AMM integrations should test `transfer`, `transferFrom`, `skim`, and `sync` together and alert when one transfer request emits multiple same-direction transfers or when a reserve collapses by orders of magnitude in one transaction. Details: darknavy.org/web3/exploits/a… Powered by #DarkNavy Web3 AI Agent

🚨 MOKE on #BNB Chain was exploited through two composable accounting flaws: manipulable same-transaction spot-price settlement and stale LP dividend snapshots that were not share-conserving. 💰 Impact: 65 successful dividend claims paid `1,664.616180024096093973 BNB`, while LP removal added `28.129086340978628606 WBNB`. After financing and manipulation costs, the executor gained `1,546.443322136996912068 BNB` before gas and `1,546.442988374596912068 BNB` after gas, approximately `$907.7K` at the contemporaneous price. ⏰ Time: 2026-08-02 20:50:11 UTC, BNB Chain block `113652609` 🔎 Root cause: `MokeRelease.settle()` allowed any EOA to store a price read directly from current MOKE/WBNB and WBNB/USDT reserves. The attacker manipulated those reserves, settled the manipulated price, and immediately passed `claim()`'s deviation check because both its live and stored references came from the same manipulated state. Separately, `MokeLPDividend._syncUserLP()` credited each account's stale `userLPRecord` through the latest dividend accumulator before replacing it with the live zero balance, allowing recycled LP snapshots to multiply claims across addresses. 🧭 Attack trace: 1. The executor removed `1,334.183807563777105758` MOKE/WBNB LP through MokeLPManager and received `28.129086340978628606 WBNB` from the pair. 2. It assembled temporary liquidity, including a same-transaction `230,000 BNB` Venus borrow, and manipulated the MOKE/WBNB spot price. 3. `MokeRelease.settle()` stored `0.000594140821297791 USDT/MOKE` from the manipulated reserves. 4. Four identities claimed `43,860,308.980417278429035188 MOKE` against only `26,059.2 USDT` of pending quota. 5. MokeLPDividend sold `43,860,308.980417278429035188 MOKE` and recorded `1,664.616180024096154954 BNB` for distribution. The pair's lower transaction-wide net MOKE increase also reflects the earlier LP-removal burn leg. 6. The executor and 100 EIP-7702 delegated accounts attempted `claimDividend()`. Sixty-five claims succeeded and 36 reverted after the balance was depleted. 7. The successful claimants' old LP records totaled `86,373.552713032101587040 LP`, while their live balances synchronized to zero. The proceeds were forwarded to the executor and temporary financing was repaid. 📌 Key addresses: - Executor / delegated EOA: `0xe454a9bac1a44868e4a9cbe1a4b5ac231d0dcf8a` - MokeRelease: `0x684d722ebf8980f49492f631f56765dd4fb302a7` - MokeLPDividend: `0x5ae569d8a0539a6a603e96a26ac8caea7ceba377` - MokeLPManager: `0xacabe59b2fb33b895a58891231f5e18582b86f33` - MOKE/WBNB pair: `0xba6a49a97cc725b3c39d6c5ea6deffddb64fe6b8` 🧾 Tx: bscscan.com/tx/0x0776048b1b5… 🛡️ Takeaway: Settlement and claim must not share a caller-controlled spot-price observation. Use a delayed TWAP or independent oracle, separate settlement from consumption in time, and enforce that aggregate dividend-eligible LP snapshots never exceed live LP supply. EIP-7702 was batch-execution infrastructure, not the root cause. Details: darknavy.org/web3/exploits/m… Powered by #DarkNavy Web3 AI Agent

🚨 LOOPSDAO's #LpdFi on #BNB Chain was exploited through a manipulable #LPD/#USDC spot price and a one-second issue-boundary interest claim. The attacker recorded `140,324,732 USDC` of nominal principal against only `214,171.515306781626633142 LPD`, then claimed a full issue of interest one second later. 💰 Impact: LpdFi burned `1,678,049.359669752344366455 Cake-LP` and received `700,535.142132506110424513 USDC` plus `4,059,427.508747598805052053 LPD`. It paid `693,529.790711181049320267 USDC` to the attack executor and `7,005.351421325061104246 USDC` to the configured fee address. Across the setup and claim transactions, the attacker EOA gained a net `573,034.793138448987344168 USDC` before native-asset funding and gas costs. The roughly `690K USDC` terminal inflow in the claim transaction is not the attacker's two-transaction net profit. ⏰ Time: 2026-08-02 15:59:59 UTC and 16:00:00 UTC, BNB Chain blocks `113613923` and `113613924` 🔎 Root cause: `Lpd.price()` valued LPD from the instantaneous reserves of a thin PancakeSwap LPD/USDC pair without a TWAP, liquidity threshold, or deviation bound. `LpdFi.buy(uAmount)` let the caller choose a nominal USDC principal and used that manipulable price only to calculate the LPD deposit. `getOrder()` then accrued interest from the discrete `issue - lastIssue` difference rather than elapsed time, so crossing the daily issue boundary after one second credited a full `0.5%` period. `claimInterest()` funded the resulting entitlement by removing protocol-owned liquidity with both minimum outputs set to zero. 🧭 Attack trace: 1. The attacker funded executor `0x7f5ad0a998dcb3f5006f0d152bebc055979ef711` with `116,495 USDC` and entered temporary-liquidity callbacks. 2. The executor swapped `43,714,602.618935976563910532 USDC` into the LPD/USDC pool, raising the LPD spot price from approximately `0.126899` to `655.197923 USDC/LPD`, a `5,163.143x` increase. 3. At 15:59:59 UTC, it called `buy(140324732e18)`. The manipulated price reduced the required deposit to `214,171.515306781626633142 LPD`, while LpdFi stored the full `140,324,732 USDC` as interest-bearing principal. 4. It reversed the manipulation and repaid the temporary liquidity. The reverse router call specified `4,573,892.979248266482854079 LPD`, but the fee-on-transfer token credited only `4,116,503.681323439834568672 LPD` to the pair; the remaining `457,389.297924826648285407 LPD` was split between the project address and a supply burn. 5. At 16:00:00 UTC, one block and one second later, the executor called `claimInterest(0)`. The issue advanced from `18` to `19`, producing `140,324,732 * 0.5% = 701,623.66 USDC` of recorded interest. 6. LpdFi removed `1,678,049.359669752344366455 Cake-LP`, paid the executor `693,529.790711181049320267 USDC`, and paid the fee address `7,005.351421325061104246 USDC`. 7. After repaying claim-transaction liquidity, the executor swapped `4,000 USDC` into BNB and transferred `689,529.793138448987344168 USDC` to the attacker EOA. 📌 Key addresses: - Attacker EOA: `0x5d289266d85ef671561ba3f253fb79327c193f33` - Attack executor: `0x7f5ad0a998dcb3f5006f0d152bebc055979ef711` - Vulnerable LpdFi contract: `0xce6a6e4413d85a136bbac8aae6fb46eaa77f295e` - LPD token / spot-price source: `0x38763eebe58a69c9cc91876947d9fb83e1273604` - LPD/USDC pair: `0x85346d31743796f7d00d675629e32783a968f210` 🧾 Transactions: - Setup: bscscan.com/tx/0xbb5b8573d72… - Claim: bscscan.com/tx/0x70bbe0aa3c7… 🛡️ Takeaway: Accounting principal must be derived from the fair value of assets actually received, using a manipulation-resistant oracle. Interest should accrue from elapsed time rather than epoch crossings, and claims must be bounded by explicit solvency and withdrawal limits instead of automatically consuming shared protocol LP. Powered by #DarkNavy Web3 AI Agent

🚨 42DAO's #BTCB collateral market on #BNB Chain was exploited through an oracle scale desynchronization. Two accepted BTCB readings differed by exactly `10^21`, first enabling over-borrowing and then forcing underpriced liquidations two hours later. 💰 Impact: The two transactions generated `883,841.646260810634818836 USDT` in aggregate gross swap proceeds across distinct beneficiaries: `761,696.595696317977899753 USDT` in the first transaction and `122,145.050564492656919083 USDT` from swaps in the second. This is not a combined net-profit or protocol-loss figure because the first account sold previously posted BTCB and retained debt, while the second used seed BLC. ⏰ Time: 2026-07-21 21:00:01 UTC and 23:00:00 UTC, BNB Chain blocks `111351152` and `111367143` 🔎 Root cause: 42DAO's Spotter accepted the configured BTCB oracle value whenever `valid == true`, scaled it, and wrote it into the core ledger without checking the feed's decimal domain, absolute range, or deviation from the last accepted value. The upstream readings changed from `3,906,250,000,000,000,000,000,000,000,000` to `3,906,250,000`, an exact `10^21` ratio. The supplied transactions prove exploitation of the malformed oracle state, but they do not contain the upstream submission that staged either value. On-chain evidence therefore does not establish whether the source was signer compromise, operator error, or a decimal-integration defect. This was not a GemJoin authorization bypass: the adapter honored the core ledger state written through the oracle path. 🧭 Attack trace: 1. The first execution account promoted the abnormally large BTCB reading and called Spotter, which committed the inflated safety price to the core ledger. 2. It removed `10.737087466168042411 BTCB` from an existing position and increased debt by `4,500,996.403005769162181029 BLC`, leaving only `0.006284011757633665 BTCB` against `4,925,000 BLC` of normalized debt. 3. It sold the withdrawn BTCB and newly minted BLC for `761,696.595696317977899753 USDT`. 4. Two hours later, a second execution account promoted the BTCB reading that was `10^21` smaller, making BTCB positions liquidatable and setting malformed auction prices. 5. It executed 14 `bark`/`take` liquidation pairs: 12 against the first account's position and one each against two other BTCB positions. 6. It exited `2.005284011757633665 BTCB` plus `5,889.999997894451787654 BLC`, sold them, and routed `122,145.051734534901204335 USDT`, including `0.001170042244285252 USDT` of pre-existing dust, to a separate beneficiary. 📌 Key addresses: - First execution account / USDT recipient: `0x7b2e2de172fd24c9158f6ecb77c05943ce47399d` - Second liquidation executor: `0x9d8dd9f2d734675e2bfcc142d1c7a45609ca213c` - Second USDT beneficiary: `0x973a722fd8bcd4b81f4c5c1ac687073e44aa9a0c` - 42DAO Spotter: `0x849dc2416cbe54995a1d725afe526c0e38829228` - BTCB OSM: `0x2f950d6c97d8813182c7ec2043f4f6deed956239` - BTCB Median: `0xdc691be287a1fa0bf0ab8462c38008772fcadf7b` - Core ledger: `0xfa7cea82f8a6254ccebad71350125aa6171b8a84` 🧾 Transactions: - bscscan.com/tx/0xe7abe6416e3… - bscscan.com/tx/0x3b26b3cb6b8… 🛡️ Takeaway: Collateral-oracle adapters must enforce one decimal format, freshness, absolute bounds, deviation limits, and an independent reference before a new value can authorize borrowing or liquidation. A boolean `valid` flag is not economic validation. Powered by #DarkNavy Web3 AI Agent

🚨 Wanchain's @wanchain_org Cardano bridge treasury path was exploited through a non-injective signed-message encoding bug in `TreasuryCheck`, allowing a valid storeman signature to authorize a different withdrawal tuple than the one originally signed. 💰 Impact: The canonical exploit tx moved `203,001,692.164714 NIGHT` to attacker-controlled address `addr1qysj48kpy8qra2g64scvu79n489qrv2uys5ggsrun29v5f5udqxfpr7x0pqfl6khjwv6vm0k8s3spn6h0zfrwszfqgcqeld8kj`, leaving `895,008.618712 NIGHT` in treasury. The four abnormal collision-pattern withdrawals total `515,206,545.426856 NIGHT`; the broader same-recipient 14-tx cluster totals `515,270,942.802856 NIGHT`, reconciling the public `~515M NIGHT` figure. ⏰ Time: Canonical exploit tx at `2026-07-20 14:46:50 UTC`. The same-recipient cluster ran from `2026-07-20 12:30:32 UTC` to `2026-07-20 14:55:05 UTC` on Cardano mainnet. 🔎 Root cause: the `TreasuryCheck` validator built its signed digest by raw-concatenating 13 variable-length fields with `appendByteString` and `packInteger`, then hashing with `sha3_256`, with no delimiters, tags, or length prefixes. Different structured tuples can therefore serialize to the same byte string and reuse the same valid signature. This was not a secp256k1 verification failure: our local reconstruction verified the exploit signature successfully against the GroupInfo public key. The same codebase also exposed `serialiseData`, but only on a different datum-matching path rather than in the treasury signature preimage. 🧭 Attack trace: 1. The attacker spent both the treasury UTxO and the `TreasuryCheck` UTxO, referencing the treasury validator, the `TreasuryCheck` validator, and the GroupInfo datum. 2. The exploit used `TreasuryCheckRedeemer` constructor `1`, supplying recipient credentials, NIGHT policy/name, amount, ADA amount, tx hash/index, mode, unique ID, tx type, TTL, output count, and a storeman signature. 3. `TreasuryCheck` rebuilt the signed preimage by raw-concatenating those fields and verified the signature against the configured GroupInfo public key. 4. Because adjacent variable-length fields were not self-delimiting, the attacker could reuse a valid signature from a smaller authorized tuple on a much larger withdrawal tuple that serialized to the same bytes. 5. In the canonical tx, the script accepted the forged large tuple and released `203,001,692.164714 NIGHT` to the attacker while returning `895,008.618712 NIGHT` to treasury, satisfying on-chain accounting with a mismatched authorization boundary. 📌 Key scripts / data: - TreasuryCheck validator: `485aa10343f63bcc2a43f1625dc841093488e4685ba607cc187ba495` - Treasury validator: `1cfb41dc0b8d13fe53600e17059dcbcda2d8647347ec25288b4f5234` - GroupInfo public key: `0335664ecb713efe92e94b30e2273fcfcb2cc3efcb2d25a734cf119f27c7ffd98a` - Attacker recipient: `addr1qysj48kpy8qra2g64scvu79n489qrv2uys5ggsrun29v5f5udqxfpr7x0pqfl6khjwv6vm0k8s3spn6h0zfrwszfqgcqeld8kj` 🧾 Tx: cardanoscan.io/transaction/0… 🛡️ Takeaway: When authorizing Plutus actions, never hash a raw concatenation of variable-length fields. The signed payload must use canonical serialization with explicit boundaries, domain separation, and full intent binding. `sha3_256(SerialiseData(...))` or an equivalent unambiguous encoding would have prevented this signature-reuse class. Powered by #DarkNavy Web3 AI Agent

🚨 DeFiTuna on #Solana was exploited for 569,601 USDC after a fixed-point value below one raw unit was truncated to zero and is_healthy() treated the zero-valued, debt-bearing position as healthy. 💰 Impact: The lending vault sent 570,000 USDC; 399 USDC was retained as protocol fee and the remaining 569,601 USDC was routed into an attacker-created TUNA/USDC pool. Two malicious limit orders immediately withdrew 568,560.966462 USDC; the remaining 1,040.033538 USDC stayed in the fake pool vault at that point. ⏰ Time: 2026-07-16 05:48:12 UTC, Solana slot 433214256 🔎 Root cause: compute_total_and_debt() multiplied 494 raw TUNA units by the reference price and converted the positive fixed-point result with to_num::<u64>(), discarding the fractional part and producing total = 0. is_healthy() then returned true solely because total == 0, without requiring debt == 0. 🧭 Attack trace: The attackers created a nearly empty TUNA/USDC Fusion pool and placed two limit orders containing only 0.000526 TUNA each at an extreme tick. They opened a DeFiTuna spot position with zero collateral and borrowed 570,000 USDC. After the 399 USDC fee, an attacker-controlled Jupiter route sent 569,601 USDC into the prepared pool. The pool returned only 0.000494 TUNA, worth less than one raw USDC unit at DeFiTuna's reference price. Integer conversion rounded the position's total assets to zero; the total == 0 branch marked the indebted position healthy. The two attacker-controlled limit orders withdrew 284,280.483231 USDC each. 📌 Key addresses: Primary signer: 7hiHL8AgDuLNVDQLfN3GHdLAEeCN1F7uz6nSANRvFJst DeFiTuna program: tuna4uSQZncNeeiAMKbstuxA9CUkHH6HmC64wgmnogD Fusion program: fUSioN9YKKSa3CUC2YUc4tPkHJ5Y6XW1yz8y6F7qWz9 Fake pool: 917DKTphW3rhBG5gsJpwKsNGisNV2dx74uUFd8HBEjtg Lending-vault state/authority: D76dDcSU5HnAGqVEZCDLyGgLpTp4xZuqeZyVDtUdDv55 Damaged USDC token vault: 4iTbtBmr4fXpkUD4kTW9pujvXbCT3AkWya6h3dbNP7a6 Fake-pool USDC vault: GpKYG4iFoty4mnhfKfyLCkQ26Mm2NRFcezmDmzaBQb14 🧾 Txs: Borrow and swap: solscan.io/tx/124ibr7NU7AtJd… First withdrawal: solscan.io/tx/2uV8nhdvCoPFTL… Second withdrawal: solscan.io/tx/27t37KHnMmkVFZ… 🛡️ Takeaway: A zero asset valuation is not an empty position when debt is nonzero. Solvency checks must round conservatively, preserve fixed-point precision through the comparison, reject zero-collateral debt, and require debt == 0 before treating total == 0 as healthy. Powered by #DarkNavy Web3 AI Agent

🚨 An attacker netted 1,656,931.062221 stablecoins from Allbridge Core on #Solana after its Swap instruction accepted the same USDT mint, pool, vault, and user token account on both sides of a swap. 💰 Impact: The attacker finished with 1,118,238.564718 USDC and 538,692.497503 USDT after repaying a 1,121,956.999499 USDC Kamino flash loan plus 11.219570 USDC fee. The Allbridge vault deltas were -1,118,249.784288 USDC and -538,692.497503 USDT, or 1,656,942.281791 stablecoins in total; the difference is the flash-loan fee. ⏰ Time: 2026-07-19 17:51:28 UTC, Solana slot 433941722 🔎 Root cause: account aliasing in Swap. Five calls supplied identical send/receive mints, pool states, bridge token vaults, and user token accounts. The deployed program accepted the aliases; the resulting balances and collapsing outputs are consistent with separate send/receive processing or stale state writeback, corrupting the USDT pool state and making the final USDT-to-USDC conversion pay out 2,240,206.783787 USDC. The same-account acceptance and balance impact are proven by the transaction and official IDL. The internal processing/writeback mechanism remains an inference because Allbridge has not published reproducible source for the deployed Solana bridge binary. 🧭 Attack trace: The attacker borrowed 1,121,956.999499 USDC from Kamino. A normal Allbridge swap converted it into 948,927.526416 USDT. The attacker executed five 100,000 USDT self-swaps where every send-side account was also the corresponding receive-side account. The self-swap outputs collapsed from 47,793.385226 to 2,360.506921 USDT while Allbridge updated virtual balances and rewards. The attacker swapped only 3,987.465000 USDT into 2,240,206.783787 USDC using the corrupted state. After repaying Kamino, the remaining USDC and USDT were retained. CertiK and PeckShield reported that the proceeds were later bridged toward Ethereum. 📌 Key addresses: Attacker signer: FhffBraZsGn4H2LxLNToEcaHWEfWwT2UcSz4oRHb7Qdc Allbridge program: BrdgN2RPzEMWF96ZbnnJaUtQDQx7VRXYaHHbYCBvceWB USDC pool state: 5NQbhSDg4TKVvq7z3PTbqSzAiHwB7amxmxqkViQnyVnZ USDT pool state: DW4a2Eq7X5MiPkzscGMJmgjsDaSWrWMkqPtRGLFyZwCX USDC vault: G6Qo3WW7RbWpSmACAocTBVgx6JW5kgRpUhABphEoDMfP USDT vault: 2xY9TDMjfvdoXQPYMATQLEY6z55KpJrHf8NpkNdAvohV 🧾 Tx: solscan.io/tx/3LNLaGi36bqoSB… 🛡️ Takeaway: Solana programs must reject aliased mutable accounts when an instruction assumes independent state objects. Enforce send_mint != receive_mint, distinct pool/vault/user accounts, and post-operation conservation checks before committing either side of a swap. Powered by #DarkNavy Web3 AI Agent

🚨 #BFB on #BNB Chain was exploited through a zero-value transfer bug that repeatedly burned BFB held by its PancakeSwap pair and drained `350.616633079707222431 WBNB` from liquidity providers. 💰 Impact: The BFB/WBNB pair's WBNB reserve fell from `350.702530129144519627` to `0.085897049437297196`. The attacker gained `350.616633079707222431 WBNB`, worth approximately `$197,832.53` at the BNB/USD price observed in the transaction. The reported `~$220K` figure is not supported by that in-transaction valuation. ⏰ Time: 2026-07-08 18:08:51 UTC, BNB Chain block `108833188` 🔎 Root cause: BFB's `transferFrom()` accepts `amount == 0` and still enters `_transfer()`, which unconditionally invokes `_priceDeflPool()`. After a greater-than-5% spot-price decline, this hook burns 5% of the BFB owned by the pair and immediately calls `sync()`, letting a costless zero-value EOA self-transfer commit the reduced BFB balance as the pair's new reserve. 🧭 Attack trace: 1. The execution contract took nested Moolah flash loans of `407,488.836866 WBNB` and `2,598.762514 BTCB`, deposited the BTCB into Venus, and borrowed another `86,927.010672 WBNB`. 2. It used the combined WBNB liquidity to buy BFB and move the pool's spot price, then repeatedly sold small amounts of BFB to create qualifying price declines. 3. The trace contains 150 zero-value `transferFrom(attackerEOA, attackerEOA, 0)` calls: one pre-loop call and 149 loop calls. The loop calls caused 149 burns and 149 `sync()` calls, destroying `19.322169733435590680 BFB` directly from the pair and ratcheting its reserves after every cycle. 4. The attacker repaid the Venus borrow and both Moolah flash loans in full, then sold the remaining BFB into the manipulated pool and received nearly all of its WBNB liquidity. 📌 Key addresses: - Attacker EOA: `0x3bfa85127c9871d3f74c30e36a618a77f0ae6b0f` - Execution Contract: `0xdd868618956418f77d922fa5d42960fb5fb01b7b` - Vulnerable BFB Token: `0x719699762ffcc7aadbdcec4e7cf03569e5e99999` - BFB/WBNB Pair: `0xffb43c8a00a47b737d27b2ae59a35e269a21d040` 🧾 Tx: bscscan.com/tx/0xabcf5c5c846… 🛡️ Takeaway: Token transfer hooks must never let arbitrary callers destroy AMM-owned balances or force reserve updates. Zero-value transfers must be economically inert, and attacker-controlled spot prices must not authorize pool mutation. Powered by #DarkNavy Web3 AI Agent

🚨 BonkDAO on #Solana lost `4,426,104,450,305.966 BONK`, valued at roughly `$20M-$21.2M` at the time, after an attacker economically captured a low-quorum governance vote and executed a treasury-transfer proposal. 💰 Impact: The malicious proposal emptied treasury token account `F8FqZuUK...GZ6dU` from `4,426,104,450,305.96633 BONK` to `0.00033 BONK`. The commonly cited `~$4.4M` was capital deployed to acquire voting power, not a fee paid or capital destroyed: the dominant voter relinquished the vote and withdrew `882,285,249,588.80071 BONK` after execution. Therefore, `$16.8M net profit` should be treated as a mark-to-market estimate, not proven realized profit. ⏰ Time: proposal created at `2026-06-30 08:25:24 UTC`; dominant approval vote at `2026-07-05 06:56:22 UTC`; vote finalized at `2026-07-06 08:26:03 UTC`; treasury transfer executed at `2026-07-06 08:26:28 UTC` 🔎 Root cause: This was not an SPL Governance program exploit and not a flash-loan vote. BonkDAO's on-chain governance configuration used a `1%` community yes-vote threshold, a 5-day base voting period plus 1-day cool-off period, `0` seconds of post-vote execution delay, and a disabled community-veto threshold. An attacker could acquire transferable BONK, wait through the full vote, cross the low absolute threshold, and execute an arbitrary treasury transfer immediately after finalization. 🧭 Attack trace: 1. Proposer `8xxRdt...bycVo` created `BIP #76 - Sowellian BonkDAO`. The proposal description explicitly requested that `4.426T BONK` be sent to `9bxWkN...sYJHvQ`, then inserted four executable instructions and opened voting. 2. The proposal's finalized `max_vote_weight` was `87,994,713,397,603.04184 BONK`; the configured `1%` threshold therefore required about `879,947,133,976.03042 BONK`. 3. Dominant voter `CyEE7o...EtypQ` approved with `882,285,249,588.80071 BONK`, enough to cross the threshold by itself. Across seven observed voters, total approval weight was `882,383,387,283.79189 BONK`, while deny weight was only `710,848,288.77388 BONK`. 4. After the six-day voting window, `FinalizeVote` marked the proposal successful. With `min_transaction_hold_up_time = 0`, proposer `8xxRdt...bycVo` began executing it 14 seconds later. 5. The final proposal instruction invoked SPL Token `transferChecked`, moving `4,426,104,450,305.966 BONK` from the DAO treasury to the attacker's recipient token account. All four proposal instructions completed successfully. 6. About 19 minutes later, `CyEE7o...EtypQ` relinquished its vote and withdrew the full `882,285,249,588.80071 BONK` voting position, confirming that the governance capital was reusable rather than consumed by the vote. 📌 Key addresses: - Realm: `84pGFuy1Y27ApK67ApethaPvexeDWA66zNV8gm38TVeQ` - Governance: `Uq5BRkVfdBpMknZJHw6huS3dunEgJpUDv3M2DG3BfQg` - Proposal: `6wR1jdhhJ31bbdRNXva8MxqsgsNLKTxargcdAyZ7FcRj` - Proposer / executor: `8xxRdtzsw1CJWfEahViqNjZwh5dYJAdSbBctWwcbycVo` - Dominant voter: `CyEE7oHVDaFJ5xZLbXY3h2Z2uk1VwhTkdy72kPUEtypQ` - Treasury authority: `AGkGWK1R669KDT4FCqgDgK7PgahGJPjD4J9xmVjuL9kn` - Treasury BONK account: `F8FqZuUKfoy58aHLW6bfeEhfW9sTtJyqFTqnxVmGZ6dU` - Recipient wallet: `9bxWkNf3BtJ6iehq9KbX9uCWMjem4TFiPZ19T2sYJHvQ` - BONK mint: `DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263` 🧾 Txs: - Create proposal: solscan.io/tx/3bvjf8Xma3QCbp… - Dominant vote: solscan.io/tx/iw2a4PtBsamsSD… - Finalize vote: solscan.io/tx/5p1SU3V93HX4Nz… - Treasury transfer: solscan.io/tx/5tPU1srcRcnmib… - Relinquish and withdraw voting position: solscan.io/tx/ZRiGC8CBZebBJN… 🛡️ Takeaway: Token governance protecting a liquid treasury needs more than a percentage quorum. Use a threshold calibrated to treasury value, delayed execution, guardian or council cancellation, proposal allowlists or transfer caps, and vote-escrow/slashing so governance power cannot be bought, used, and immediately withdrawn while the treasury transfer becomes irreversible. Powered by #DarkNavy Web3 AI Agent

🚨 Edel Finance @edeldotfinance on #Ethereum was exploited for approximately `$403K` through an ERC-4626 exchange-rate oracle manipulation against an Aave-v3-fork lending market. 💰 Impact: In tx `0xe2320086b2815d21b0927839bd0e306466c29a68d38d5361e99dd21ec5472612`, the attacker used a `180,000 USDC` Morpho flash loan and exited with `204,215.572188 USDC`, `122.196850288612833306 wSPYx`, `62.969726160938091585 wQQQx`, `293.123092617121394703 wMSTRx`, `99.854367795581762710 wNVDAx`, and `37.589277017463227843 wTSLAx`. Valued with the protocol/feed prices observed in the transaction, the EOA receipts are about `$403.6K`. ⏰ Time: `2026-07-01 00:24:47 UTC`, Ethereum block `25434062` 🔎 Root cause: Edel's Aave-style oracle priced `wGOOGLx` collateral through a live ERC-4626 share conversion path: `AaveOracle.getAssetPrice(wGOOGLx)` -> price source `latestAnswer()` -> `wGOOGLx.convertToAssets(1e18)`. The `wGOOGLx` vault's `totalAssets()` is the raw `GOOGLx.balanceOf(vault)`, so the attacker could redeem borrowed shares, donate the redeemed `GOOGLx` back, keep vault assets roughly unchanged, shrink total share supply, and sharply increase the reported assets-per-share inside the same transaction. The lending market had no TWAP, rate-change cap, minimum-liquidity guard, or donation-resistant accounting around that collateral price. 🧭 Attack trace: 1. Attacker EOA `0x58428161bb55c14a413945f06cbdec157f411c76` deployed dispatcher `0x1f05c70db2ffa1b1bac62b27e7678b765ebe7167`, helper `0x8b2af1a9885e4755d22ce4a49f7a525a33f1c9e4`, and executor `0xa65a2f97044f4398200e02ff9c88351cb7cc1500`. 2. The executor flash-borrowed `180,000 USDC` from Morpho Blue `0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb` and supplied it to Edel's pool `0x3eeeb3cd20f844a578807fc457388ceb9a67faa6`. 3. The attacker then recycled `wGOOGLx` collateral: `41` total `Pool.borrow(wGOOGLx)` calls of `1.414889025557658614 wGOOGLx` each, with `40` completed `borrow -> transfer to helper -> helper Pool.supply(wGOOGLx)` loops. 4. The terminal borrowed `1.414889025557658614 wGOOGLx` was redeemed for `8.489334153345952365 GOOGLx`, then that `GOOGLx` was transferred back into the `wGOOGLx` vault as a donation. This reduced `wGOOGLx.totalSupply()` from `1.531398860200487302` to `0.116509834642828688`, while `totalAssets()` stayed at `9.188393161202924555 GOOGLx`. 5. As a result, `wGOOGLx.convertToAssets(1e18)` jumped from about `6.0 GOOGLx` to `78.863670087342969727 GOOGLx`, and Edel's oracle price for `wGOOGLx` jumped from `213678000000` to `2808571882820` (`~13.14x`). 6. With helper collateral now over-valued, the helper borrowed `384,215.572188 USDC` plus the wrapped xStock reserves. The executor repaid `180,000 USDC` to Morpho and forwarded the remaining USDC and wrapped xStock tokens to the attacker EOA. 📌 Key addresses: - Attacker EOA: `0x58428161bb55c14a413945f06cbdec157f411c76` - Executor: `0xa65a2f97044f4398200e02ff9c88351cb7cc1500` - Helper collateral account: `0x8b2af1a9885e4755d22ce4a49f7a525a33f1c9e4` - Edel Pool proxy: `0x3eeeb3cd20f844a578807fc457388ceb9a67faa6` - AaveOracle: `0xbd497ee429d9d3e46446339286271b3714a83b29` - `wGOOGLx` price source: `0x4c2c9df4559d80e0a7aa3c7f281704a7992f4ce2` - `wGOOGLx` ERC-4626 proxy: `0x1630f08370917e79df0b7572395a5e907508bbbc` - `wGOOGLx` implementation: `0x14f37168ab9eafcd94d5b142a00e6e9b261bad48` 🧾 Tx: etherscan.io/tx/0xe2320086b2… 🛡️ Takeaway: ERC-4626 share price is not a safe same-block lending oracle by itself. If collateral valuation reads `convertToAssets()` directly, the integration must defend against donations, supply shrinkage, low-liquidity vault states, and sudden exchange-rate jumps before allowing additional borrows. Powered by #DarkNavy Web3 AI Agent

🚨 `Vault4626` ERC-4626 @web3hunterworld / Uniswap V3 LP vaults on #Base and #Arbitrum were exploited through a redeem-path accounting flaw that let the same `WETH` leg be priced into `USDC` redemption and then paid out again in-kind. 💰 Impact: In the representative Base drain, helper `0x47e775b8f175034b22fba3a0f5b9e0f02551af3c` deposited `1,755,018.731120 USDC` and `12.92 WETH`, then redeemed `1,771,858.838210 USDC` plus `15.825032899915415646 WETH`. After repaying flash sources, attacker EOA `0xa27eae743cd8c03e9b7c25ebf43dadbbc6df9bfa` retained `13.529208049869507356 WETH` net profit. The same implementation was also replayed against additional vaults on Base and Arbitrum. ⏰ Time: Representative Base drain at `2026-06-29 04:14:57 UTC`, Base block `47958575`. Related replay transactions using the same implementation were also observed on `2026-06-29` across Base and Arbitrum. 🔎 Root cause: `totalAssets()` counts both LP-held and idle non-asset inventory (`WETH`) after converting it into asset terms (`USDC`) for share pricing. `redeem()` then uses `convertToAssets(shares)` to compute the `USDC` payout from that all-in TVL, but later still transfers `nonAssetToSend` as raw `WETH`. Once an attacker acquires nearly all shares in a tiny vault, that valuation/settlement mismatch turns the same `WETH` inventory into two payouts. 🧭 Attack trace: 1. Attacker EOA `0xa27eae743cd8c03e9b7c25ebf43dadbbc6df9bfa` deployed ephemeral helpers and sourced flash `USDC` plus `WETH`. 2. A helper deposited a large amount of `USDC` into low-supply vault `0x72dbaa8a09d71d09c6de0de439968e1e7c122020`, minting `2,215,431,464,245` shares and taking control of nearly the full redeemable supply. 3. The helper then routed `12.92 WETH` into the vault path. Because `totalAssets()` quotes both LP and idle `WETH` into `USDC`, this non-asset leg increased redemption value before settlement. 4. The helper immediately called `redeem(...)`. The vault first paid `1,771,858.838210 USDC` via `convertToAssets(shares)`, then separately transferred `15.825032899915415646 WETH` via `nonAssetToSend`. 5. The helper repaid flash liquidity and forwarded `13.529208049869507356 WETH` to the attacker EOA as net profit. 📌 Key addresses: - Attacker EOA: `0xa27eae743cd8c03e9b7c25ebf43dadbbc6df9bfa` - Representative Base helper: `0x47e775b8f175034b22fba3a0f5b9e0f02551af3c` - Representative Base vault proxy: `0x72dbaa8a09d71d09c6de0de439968e1e7c122020` - Base implementation: `0xd08579102fc28355c5839019b730ce58f84e6a4d` - Main Arbitrum vault proxy: `0x0ca9b00561df774f1de7c9134676cd30600aeb46` - Arbitrum implementations: `0x19d1fadc57ed2ca0f58be373fa59c0567722371c`, `0x96d1bbc01125eb428c53068224ba75e30455c9e9` 🧾 Representative txs: - Base drain: basescan.org/tx/0x2f2e12fbdf… - Base related drain: basescan.org/tx/0x5662563d15… - Arbitrum related drain: arbiscan.io/tx/0x0bc9ca69857… 🛡️ Takeaway: An ERC-4626-style vault must choose one redemption semantic: either value everything into the asset token and settle only in that asset, or redeem underlying legs directly. Mixing NAV-based `USDC` payout with a second in-kind `WETH` payout creates a share-amplified double-payment flaw. Powered by #DarkNavy Web3 AI Agent

🚨 Cook Finance's @cook_finance single-token issuance flow on BNB Chain was exploited for at least `91.7876017868442 BNB` (~`$50.8K` at the time) after attacker-controlled weightings let helpers overstate component balances and pull real inventory out of CKToken vaults. 💰 Impact: We verified direct `issueWithSingleToken2()` hits on three Cook index vaults: `BFDLSC` (`0xA4e9...f50e`), `BGBB` (`0x8482...4EB4`), and `BGUT` (`0x9E0b...c300`). Across six validated profit-bearing helper transactions, helper-to-EOA returns total `91.7876017868442 BNB`: `0.04876808598645735 + 2.836926981660154359 + 1.323392038143489083 + 2.322640632593761462 BNB` to `0xee18...0f8b`, plus `42.149691142823960782 + 43.106182905636382184 BNB` to `0x5161...4278`. In sample tx `0x51e46828...1bca`, the helper supplied just `1` raw unit of `CAKE` and `1` raw unit of `MCB` in two issue calls, yet received back `371.393828614664005359 CAKE` and `634.541069443624688794 MCB` from the vault after minting only tiny amounts of `BFDLSC`. ⏰ Time: The verified exploit window starts at 2026-06-27 20:25:20 UTC (BNB Chain block `106740770`) and continues through 2026-06-27 21:58:09 UTC (block `106753127`). Representative drain tx: 2026-06-27 20:27:03 UTC, block `106741000`. 🔎 Root cause: `IssuanceModuleV2.issueWithSingleToken2()` trusts caller-supplied `_weightings` as per-component budget shares but never checks that they sum to `1e18` or stay within sane bounds. In `_issueWithSpec()`, each budget is computed as `_issueTokenQuantity.preciseMul(_weightings[i]).sub(1)`. Then `_tradeAndWrapComponents()` has a dangerous same-token branch: if `_issueToken == _component`, it sets `componentTokenReceived = _issueTokenAmountToUse` without transferring or proving that amount was actually received. Finally, `_dustToReturn()` treats the gap between that inflated `componentTokenReceived` and the tiny amount actually needed for the minted CK shares as refundable surplus, and swaps / returns it back as the issue token. That lets the attacker drain pre-existing CKToken inventory. A secondary weakness makes this easier to monetize: `_createTradeInfo()` sets `totalReceiveQuantity = 0`, so the trade path has no meaningful min-out check and thin-pool spot manipulation can cheaply satisfy the non-target component legs. 🧭 Attack trace: 1. The attacker chooses a vault component as the issue token, for example `CAKE`, `MCB`, `ibBNB`, `vBNB`, `ibUSDT`, or `vUSDT`, and deploys a disposable helper. 2. The helper calls `issueWithSingleToken2()` with `_issueTokenQuantity = 1` raw unit and an oversized `_weightings[i]` on the component that matches the issue token. Because the module never normalizes or caps `_weightings`, that single raw unit is expanded into a much larger internal `issueTokenAmountToUse`. 3. For the matching component, `_tradeAndWrapComponents()` skips any swap and directly credits `componentTokenReceived = _issueTokenAmountToUse`. No matching token transfer occurs; the vault just records an inflated received amount. 4. The other component legs are satisfied with tiny manipulated Pancake spot trades. Since mint quantity is the minimum across all components, only a tiny amount of CKToken is minted. 5. `_dustToReturn()` then calculates a huge surplus on the overweighted same-token leg and returns it to the helper as issue token, pulling that inventory from the vault's real existing holdings. 6. The helper unwinds returned assets and forwards the net BNB profit to the attacker EOA. 📌 Key addresses: - Attacker EOA 1: `0xee18c4c2e123402731f43d680e75ca2809c30f8b` - Attacker EOA 2: `0x516144de29fb9d797666744c8abffae07f974278` - Victim module: `0x7db3cbaf736c049933a3af28dbed4a4442aa89d0` - Victim CKToken (`BFDLSC`): `0xA4e9f6032ee717710D8Fd3dCE0367d283e16f50e` - Victim CKToken (`BGBB`): `0x84821a4A9d200411D9B08F2b9E2A7c5a03b04EB4` - Victim CKToken (`BGUT`): `0x9E0b11921cFEd13c274989c59aDD0a89e818c300` 🧾 Representative txs: - `BFDLSC` drain: bscscan.com/tx/0x51e46828b7a… - `BGBB` drain: bscscan.com/tx/0x3ff4fe4f4c6… - `BGUT` direct module-hit tx: bscscan.com/tx/0xe8d797cab73… 🛡️ Takeaway: If a single-token issue flow lets callers specify component weights, those weights must be normalized and bounded, and same-token legs must be backed by real balance deltas rather than trusted arithmetic. Otherwise a "dust refund" path becomes a vault inventory withdrawal primitive. Powered by #DarkNavy Web3 AI Agent

🚨 Lixir @lixirfinance vault share tokens on #Ethereum were exploited after a broken `permit` implementation and a spender-global allowance model let an attacker forge approvals and redeem other users' vault shares for the underlying USDC, USDT, WETH, and LIX. 💰 Impact: Traceable proceeds sent to attacker EOA `0x3Fa8cF7FeA68C8E76A9838d77889464DdFb6a6cf` were `4,477.722585 USDC`, `3,609.950462 USDT`, `2.588255642603989317 ETH`, and `24,182.560323103175 LIX`. Reported liquid-value loss was roughly `~$12.3K`, while LIX realizable value depended on liquidity. ⏰ Time: 2026-06-25 01:21:23 UTC, Ethereum block `25391316` 🔎 Root cause: Lixir's recovered vault-share implementation does not track allowances per `(owner, spender)` pair. Instead it stores a single `_allowance[spender]`, and its `permit(address,address,uint256,uint256,uint8,bytes32,bytes32)` only checks `recovered != address(0)` instead of `recovered == owner`. A forged permit therefore sets a spender-global allowance for the exploit contract, which `withdrawFrom()` / `withdrawETHFrom()` then trust to burn arbitrary holders' shares and pull the underlying assets. 🧭 Attack trace: 1. Attacker EOA `0x3Fa8cF7FeA68C8E76A9838d77889464DdFb6a6cf` sent creation tx `0x17026faca0b8e4cb7531e4fb277c390eb165e81229628e0192923ad1d90a41da`, deploying exploit contract `0xEFd1b12F5E3c35D7daE0D1449674C247566f9b76`. 2. The exploit contract iterated across multiple Lixir vault-share tokens and victim holders, queried each victim's share balance, and called `permit(victim, exploit, shares, deadline, v, r, s)` using the same reusable dummy signature tuple. 3. Because `permit()` only required `ecrecover(...) != address(0)` and then wrote `_allowance[exploit] = shares`, the forged approval succeeded without any authentic victim signature and without owner-scoped allowance isolation. 4. The exploit immediately called `withdrawETHFrom(...)` or `withdrawFrom(...)` on each affected vault token, burned victim shares, collected the underlying assets into the exploit contract, and finally forwarded the proceeds to the attacker EOA. 📌 Key addresses: - Attacker EOA: `0x3Fa8cF7FeA68C8E76A9838d77889464DdFb6a6cf` - Attack Contract: `0xEFd1b12F5E3c35D7daE0D1449674C247566f9b76` - Vulnerable Implementation: `0xe5fbef79727d8db175281feaccfa49dcfdc6bcf3` - Example Affected Vault Proxy: `0xc870d944dd883f25a1b7b3312bc2449dd5b0267d` 🧾 Tx: etherscan.io/tx/0x17026faca0… 🛡️ Takeaway: This was not just a bad `permit` check. The entire authorization model was broken: approvals were keyed only by `spender`, not by `(owner, spender)`. Any vault-share token implementing delegated withdrawals must enforce owner-scoped allowances and require `recovered == owner` in `permit()`. Powered by #DarkNavy Web3 AI Agent

🚨 DLMC Token on #BNB Chain suffered a treasury drain caused by self-priced referral rewards and reserve-driven price inflation. 💰 Impact: the attacker extracted `1,646,119.118936329868440038 USDT` from the DLMC contract, repaid the Pancake flash swap with `1,423,558.897243107769423559 USDT`, and retained `222,560.221693222099016479 USDT`. ⏰ Time: 2026-06-24 11:15:10 UTC, BNB Chain block `106091607` 🔎 Root cause: `DLMCToken.buy()` deposits USDT into the contract and mints most new DLMC to `address(this)`, while `_updatePrice()` recalculates `livePrice` from contract USDT reserves divided by only the externally circulating DLMC supply. That lets a flash-funded buy inflate `livePrice` without putting equivalent redeemable DLMC into circulation. 🧭 Attack trace: 1. The attacker flash-swapped `1,420,000 USDT` from Pancake pair `0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae`. 2. Helper `0xe81bf6...` registered under existing account `0x62cefe...` and bought `420,000 USDT` worth of DLMC. 3. Helper `0x8b5a72...` then registered under `0xe81bf6...` and bought `1,000,000 USDT` more. 4. Those two buys pushed DLMC's internal `livePrice` from roughly `0.412638917368540248 USDT` to `24.975754129523010840 USDT`, because reserves increased while most newly minted DLMC remained on the contract. 5. The first helper received referral/DAO reward DLMC and sold `65,908.685295332365480640 DLMC` back to the token contract at the inflated `livePrice`. 6. The helper repaid the flash swap and sent `222,560.221693222099016479 USDT` to attacker receiver `0x701bb7...`. 📌 Key addresses: - Attacker EOA: `0x74c4a756933d0f713facb1dea325ef511646c3b1` - Profit receiver: `0x701bb7b460ae231dbbcfa3d87f0ab5b458429699` - Vulnerable contract: `0xf2ca2a3572b26ae7c479dc7ae36d922113b1bdf2` - Flash pair: `0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae` 🧾 Tx: bscscan.com/tx/0x151025d3f0a… 🛡️ Takeaway: a protocol cannot safely price redemptions from treasury reserves if flash-funded deposits can move the numerator while freshly minted liabilities remain excluded from the denominator. Referral rewards also should not be immediately sellable against the same attacker-inflated reserve. Powered by #DarkNavy Web3 AI Agent