AstraSec @AstraSecAI

🚨 @summerfinance_'s LVUSDC vault was drained of ~$6M through a nested vault share-price manipulation attack. Attack flow: LVUSDC → SiloManagedVaultArk → donated overvalued vgUSDC → bUSDC-155 The attacker exploited prolonged 100%+ utilization in bUSDC-155, inflating its share price from ~0.001 to ~0.55 USDC through massive accrued but uncollectable interest. This inflated value was inherited by vgUSDC → SiloManagedVaultArk → LVUSDC, allowing the attacker to redeem LVUSDC at the inflated price and drain real assets. 📌 Root cause: Naive balance-based accounting + unvalidated downstream share pricing. High utilization + poor price validation = dangerous combination in nested vaults. tx: etherscan.io/tx/0x0db528c44… #DeFi #Hack #SummerFinance

Summer.fi ☀ @summerfinance_

7 days ago

We are aware of the reported exploit a little earlier today and are investigating the root cause. The protocol guardians are currently pausing all Vaults across the Lazy Summer Protocol. We will provide more updates as we have them.

15 3 45 13K 4

📒Lessons Learned from @edeldotfinance exploit: Root cause: Price manipulation of ERC-4626 wrapped xStocks. Attacker leveraged two accounts with alternating borrow/supply on wGOOGLx, then used redeem + donation to massively inflate the wGOOGLx:GOOGLx exchange rate. This allowed a supply-only account to borrow large amounts of other assets. 📡Key takeaway for lending protocols: Avoid using share/LP tokens as collateral — their prices are too vulnerable to leveraged manipulation.

Edel Finance @edeldotfinance

2 weeks ago

An Update from the Edel Team Earlier today, Edel identified and contained an exploit affecting Edel Lending. The exploit involved manipulation of the wrapped xStocks exchange rate between wGOOGLx and GOOGLx, causing wGOOGLx collateral to be valued at approximately 78x its

37 16 137 36K 21

@BranaRakic @origin_trail thanks for the info and sorry about that, glad to know it's safe.

🚨@ThetanutsFi Legacy Index Vault was exploited for ~$105.5K USDC. Attacker flashloaned most TN-IDX-USDC-PUT tokens, claimed them, and drained nearly all underlying assets — leaving just 3 wei in totalSupply. They then used multiple crafted mints to generate large amounts of new IDX-USDC-PUT tokens (without depositing any assets), exploiting the mint math (underlying_amount * shares / totalSupply) due to precision loss at near-zero totalSupply. 💡Reminder: Allowing flash-loans on share/LP tokens carries very high risk. - attacker: etherscan.io/address/0x3049… - tx: etherscan.io/tx/0xbba9f138f……

keyboard_arrow_left Previous keyboard_arrow_right Next

Thetanuts Finance @ThetanutsFi

4 weeks ago

Our preliminary investigation indicates that this is once again, a deprecated vault that we have migrated from years ago. It has no relation to any of our current contracts or products. We will release a post-mortem once we get more details.

0 2 19 8K 1

@SasuRobert The SpaceVM design looks quite innovative with its automatic full transaction revert on sub-call failures. We need more people to provide constructive opinions on smart contract security. 🖥️

@larry0x Good suggestion! But we think the current design keeps more flexibility — it lets devs handle rainy-day cases when staticcall fails. Developers must clearly understand and properly handle its return values (success + returnData).

🚨@gnosispay Gnosis Pay Incident: Root Cause Disclosure While the attack was still ongoing, the team refrained from publishing the root cause. Now that the incident has been fully contained, we believe it is the right time to disclose the root cause. 💡Root Cause A logic flaw in SignatureChecker::_isValidContractSignature() within the Zodiac Delay Module. During EIP-1271 signature validation, the function performed a staticcall to the signer contract but only checked the returned data — it did not verify whether the call was successful. The attacker exploited this by forcing the staticcall to revert, while embedding the EIP1271_MAGIC_VALUE (0x1626ba7e) in the revert data. The flawed checker mistakenly matched the revert payload and treated the failed call as valid authorization. This bypass allowed the attacker to: - Queue arbitrary malicious transactions into victim Gnosis Safe wallets (without real permission) - Wait for the mandatory cooldown period to expire - Execute them via executeNextTx() and drain funds

Gnosis Pay 💳 @gnosispay

a month ago

An update on the Gnosis Pay incident. As of now, the issue is fully contained. We expect to begin enabling operations in batches on Wednesday evening (GMT+2), with the goal of restoring normal card usage progressively after that. 🧵

26 61 369 79K 28

🚨 [Transit Finance Incident Reflection] A deprecated 2022 smart contract on #TRON was exploited, draining ~$1.88M DAI. Even though marked “deprecated”, it remained fully callable. This raises a hard question for every Web3 builder: - Why didn’t the deprecated contract truly die? ⏰Proper deprecation isn’t optional — it must be designed from day one. Correct ways to deprecate: - Reset critical state variables - Use toggle switches(Pausable/Deprecation Flag) to disable core functions - For upgradeable contracts: point proxy to a dead (revert-only) implementation - Renounce all admin privileges 💡Security isn’t “deploy and forget.” Build for a safe, graceful exit. #SmartContractSecurity #DeFi #Web3Security #Solidity

🚨 Alert: @Aurellion_Labs on Arbitrum was exploited, losing approximately $455k USDC. Root Cause: Uninitialized Diamond Protocol The protocol set the owner in the constructor but never called initialize(). The attacker called initialize() on the SafeOwnable Facet to claim ownership, then used diamondCut() to inject a malicious facet with pullERC20 & sweepERC20 functions, draining approved USDC from multiple victims. Tx: arbiscan.io/tx/0x19cbafae5…

1/ 🚨 DeepBook was drained of $239,700 on May 9 using just ~$2,500 in capital—a massive 100x return. No reentrancy, no oracle attack, no access control bypass. Just two order-placement paths with mismatched price validation. pool::place_limit_order — no price check pool_proxy::place_limit_order — price ∈ [Pyth ± tolerance] Margin uses proxy. Regular accounts use raw. Same orderbook. Same attacker. 🧵 2/ Attacker uses TWO BalanceManagers, both their own: • BM 0xe63374a58f2a63fe8554f0e9210332848654bd1130931c0719b1e9ba0a4fa30a (regular) • MM 0xe63374a58f2a63fe8554f0e9210332848654bd1130931c0719b1e9ba0a4fa30a (margin — borrows USDC) Per PTB, BM places a "trap" at the tolerance band edges: SELL @ $1.0878 + BUY @ $1.0759 (Pyth mid $1.0819, tolerance ±0.55%) 1.1% spread, both legs pass proxy. 3/ But this only works if the band is empty of legitimate orders. Phase A (asymmetric scan): attacker uses throwaway BMs as takers to sweep ~218K SUI / $235K of legitimate liquidity. Net cost: ~$1K in spread. Now only BM's trap sits in the band. 4/ Phase B (wash loop): MM market-orders into BM's trap. • MM BUY → only ASK in band = BM's $1.0878 → MM pays high • MM SELL → only BID in band = BM's $1.0759 → MM gets low Each round trip: $0.0119/SUI leaks MM's borrowed pool → BM. Run 35×, 70 + 70 fills at exact band edges. 5/ After PTB: MM insolvent → $283K bad debt to suppliers. BM keeps ~$96K + 8K SUI. Flashloan repaid same-PTB. Just 4 successful attack txs over 50 mins. Bridged 78 ETH + 0.7 BTC to a single EVM address. 6/ 🛡️ The AstraSec Takeaway:Vulnerabilities don't always hide in complex math—they hide in architectural inconsistencies. When proxy logic and raw pool logic don't enforce the same invariants, attackers will bridge the gap.

DeepBook Protocol on Sui @DeepBookonSui

2 months ago

At ~3:18 AM UTC today, an undercollateralization vulnerability accrued $239,700 in bad debt in the USDC margin pool. Margin Trading has been temporarily paused. The Deepbook Insurance Fund has injected the amount of lost funds back into the affected pools. Deposits and

42 45 370 64K 31

🚨 echooo.xyz exploited -- $229K lost Root cause: The Forwarder contract blindly forwards req.from as the msg.sender to the SwapRouter. An attacker can set req.from to any victim who previously approved the protocol, then drain their funds via spendFromUser. tx: etherscan.io/tx/0x57709a498… ⚠️ Revoke approvals to this address IMMEDIATELY: 0x2990A16D2C37163f26F86d7af219064Ba5CD5605

keyboard_arrow_left Previous keyboard_arrow_right Next

@aave just took a major step forward in the @KelpDao rsETH bridge exploit recovery. Aave has successfully executed controlled liquidations of the attacker’s positions on both Ethereum and Arbitrum. This was achieved by temporarily setting the rsETH oracle to a FixedPriceAdapter returning a fixed price of 1, enabling low-cost liquidation of the positions. Total: 89,567 rsETH have been recovered and are now safely held in the multi-sig wallet: 0x53cb4BB8F61fa45405dC75F476FaDAd801e653D9

In line with the technical plan outlined below, the attacker's rsETH positions on Aave have been liquidated on Ethereum and Arbitrum. The liquidated collateral now sits with the Recovery Guardian as specified in the AIP. No other users were affected, and Umbrella was also untouched. This was a critical step in the recovery roadmap, with next steps to follow.

Aave @aave

3 months ago

x.com/i/article/2048…

74 91 631 345K 133

. @trustedvolumes suffered an exploit leading to a loss of approximately $5.87M. The root cause is that TrustedVolumes' RFQ contract had potential input validation vulnerability, which allowed any victim to be designated as order taker, thereby enabling the exploitation of their authorized assets. tx: etherscan.io/tx/0xc5c61b3ac… Revoke your approvals to the following address immediately (via revoke.cash): 0xeEeEEe53033F7227d488ae83a27Bc9A9D5051756