AstraSec

153 posts

AstraSec banner
AstraSec

AstraSec

@AstraSecAI

Blockchain security auditing, trusted by Magpie, 1inch, Paraswap, Kodiak, ... (https://t.co/74XaWrdj3c)

Web3 Katılım Aralık 2023
1.5K Takip Edilen594 Takipçiler
AstraSec
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
AstraSec tweet media
Summer.fi ☀@summerfinance_

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.

English
0
4
17
3.2K
AstraSec
AstraSec@AstraSecAI·
📒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.
AstraSec tweet media
Edel Finance@edeldotfinance

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 correct value. The attacker used that inflated collateral value to borrow from the protocol, creating approximately $403k in protocol bad debt. Immediately after detection, the Edel team paused all V1 contracts. Edel V1 remains paused, and users should not interact with the V1 deployment while protocol activity is suspended. The team has preserved the relevant protocol records and is using them to determine affected balances for restoration. No depositor will bear any loss from this incident. The Edel team will absorb the bad debt and restore affected depositor balances 1:1. Edel V2 is being deployed with a redesigned oracle architecture intended to prevent this class of exchange-rate manipulation. Once deployment and balance restoration are complete, restored balances will be available directly in the Edel application. We will share timing as soon as it is finalized. We have traced the attacker’s transactions and are coordinating with exchanges, ecosystem partners, and other relevant stakeholders. In parallel, we have extended a formal whitehat settlement offer to the responsible party, providing a defined window to return the remaining funds in exchange for an authorized security bounty. A full technical post-mortem will follow with the exploit path, root cause, and the changes introduced in Edel V2. This incident also reinforces the importance of EIP-01, which will introduce governance over protocol risk parameters, supported collateral, and future market configuration while preserving the team’s ability to respond immediately to security-critical events. Our immediate priorities are containment, user restoration, and transparent follow-up. We will continue updating users until affected balances have been restored in full. The Edel Team

English
0
0
4
278
Brana Rakic
Brana Rakic@BranaRakic·
@AstraSecAI @origin_trail CTO at @origin_trail Core developers here This is not a hack, but part of DKG v10 update rollout, landing today. The transactions have been executed by the Core development team x.com/BranaRakic/sta…
Brana Rakic@BranaRakic

The @origin_trail DKG V10 release is underway and lands on mainnet today! Deployment of smart contracts was completed. All $TRAC token movements from staking and publishing accounts are part of ongoing transition to V10 network. The system is now in final verification. Stay tuned for launch!

English
2
5
41
575
AstraSec
AstraSec@AstraSecAI·
🚨@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…
AstraSec tweet mediaAstraSec tweet media
Thetanuts Finance@ThetanutsFi

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.

English
1
7
35
5.2K
AstraSec
AstraSec@AstraSecAI·
@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. 🖥️
English
0
0
1
31
Robert Sasu | dev/acc
Robert Sasu | dev/acc@SasuRobert·
it is good to watch these and learn from what is happening in case of executions and what are the patterns in which all kind of developers and auditors fall into. Like literally. gnosis is a highly sophisticated project, with a lot of audits, super good devs and even them make mistakes. But these types of mistakes can be avoided completely via much safer and better VM and OPCODES. in case of SpaceVM on MultiversX, in case of failure of an opcode, which is a crypto verification for example, the whole contract fails by design. in safe mode when SC A calls SC B and SC B fails, SC A fails as well, reverting everything on the whole chain. we figured this is the safest way to ensure people doing as little mistakes as possible. if a transfer of funds failed, everything fails, it a multi transfer fails, everything fails. like 99% of the contract in default mode want this, if something fails full revert. when this is coded into the VM, devs can enjoy building their apps. And it is coded in VM and in the smart contract framework as well.
AstraSec@AstraSecAI

🚨@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

English
1
3
22
1.6K
AstraSec
AstraSec@AstraSecAI·
@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).
English
0
0
0
27
Larry Engineer 🍡
Larry Engineer 🍡@larry0x·
Solidity needs to have a lint that enforces all error values be checked. Similar to Rust's #[must_use]
AstraSec@AstraSecAI

🚨@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

English
4
0
11
897
AstraSec
AstraSec@AstraSecAI·
🚨@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
AstraSec tweet media
Gnosis Pay 💳@gnosispay

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. 🧵

English
2
1
27
6.6K
AstraSec
AstraSec@AstraSecAI·
🚨 [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
English
0
0
2
131
Transit
Transit@TransitFinance·
📣 Transit Announcement Regarding a recent incident related to historical legacy risks, we would like to share the following update: 1️⃣ Cause of the Incident The issue was related to an early-version smart contract previously deployed on TRON. Although this legacy contract had been deprecated since 2022, historical vulnerabilities within it were recently exploited, affecting a limited number of users. 2️⃣ Actions Taken Upon discovery, our team immediately carried out investigation, isolation, and mitigation measures, followed by additional review and remediation on May 12, 2026. Users do not need to take any action. The current smart contract version remains unaffected and has been operating securely for over four years, with ongoing security audits, testing, and monitoring in place. We will continue strengthening the management of legacy contracts and potential on-chain risks to further improve overall security. 3️⃣ Compensation Affected users will receive full compensation, with further details to be announced through our official channels. 4️⃣ Security Reminder • Please remain cautious of unsolicited messages or accounts claiming to represent Transit Finance. • Never share your private key or seed phrase with anyone. Transit Team
English
47
5
10
16K
AstraSec
AstraSec@AstraSecAI·
🚨 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…
AstraSec tweet media
English
0
0
1
287
Aurellion
Aurellion@Aurellion_Labs·
Today Aurellion was exploited for $456,000. We will be covering the funds extracted from this exploit. A detailed breakdown of the incident will be shared shortly. For now, all protocols operations are momentarily paused.
English
3
2
7
2.3K
AstraSec
AstraSec@AstraSecAI·
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.
AstraSec tweet media
DeepBook Protocol on Sui@DeepBookonSui

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 withdrawals have now resumed.

English
0
0
2
564
AstraSec
AstraSec@AstraSecAI·
🚨 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
AstraSec tweet mediaAstraSec tweet media
English
0
0
4
355
AstraSec
AstraSec@AstraSecAI·
@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
AstraSec tweet media
English
1
0
5
1K
AstraSec retweetledi
Aave
Aave@aave·
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

x.com/i/article/2048…

English
174
167
883
152.8K
AstraSec
AstraSec@AstraSecAI·
. @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
AstraSec tweet media
English
0
1
6
258