Sabitlenmiş Tweet
BlockSec
2.2K posts
BlockSec
@BlockSecTeam
Smart Contract Audit | Security Monitoring | AML/CFT (KYA/KYT) | Crypto Investigation | @Phalcon_xyz @MetaSleuth @MetaDockTeam 👉TG: https://t.co/owokTLanv5
Katılım Aralık 2020
151 Takip Edilen27.2K Takipçiler
BlockSec retweetledi
🗓 Weekly Web3 Security Roundup | May 11 - May 17
🚨 Spotlight on 3 notable incidents | ~$4.72M lost this week
Full analysis with vulnerability breakdown 👇
blocksec.com/blog/weekly-we…
#Web3Security
English
BlockSec retweetledi
The root cause of the @VerusCoin incident appears to be improper validation of economic backing in the import submission flow [1].
Specifically, the Verus-Ethereum Bridge contract verifies that:
1) the export/notarization proof is valid, and;
2) keccak256(serializedTransfers) matches the export's hashtransfers commitment (i.e., hashReserveTransfers[1][2]).
However, it does NOT sufficiently validate that the source-chain export actually carries enough locked/burned value to support the corresponding payouts on Ethereum.
As a result, the attacker was able to submit a Verus export [3] with essentially no meaningful economic backing, but with a matching serializedTransfers hash, and the bridge still released ~$11.7M in ETH / tBTC / USDC [4].
At a high level, the vulnerable flow is:
1) proveImports(...)
-> validates the proof and checks that hash(serializedTransfers) matches the committed transfer hash;
2) processTransactions(...)
-> proceeds to execute the payouts on Ethereum
What is missing is a robust check that the source-chain export's actual economic backing is sufficient to support the imported transfers before assets are released.
Please note: the deployed code is not open-sourced. Our investigation is based on the attack transactions and code currently available in the official repository, which may not reflect the full deployed implementation or the complete attack surface.
References:
[1] #L138-L172" target="_blank" rel="nofollow noopener">github.com/monkins1010/Ve…
[2] #L319C1-L353C6" target="_blank" rel="nofollow noopener">github.com/monkins1010/Ve…
[3] explorer.verus.io/tx/f899e6984dc…
[4] app.blocksec.com/phalcon/explor…
BlockSec Phalcon@Phalcon_xyz
.@VerusCoin's Verus-Ethereum Bridge smart contract (0x715185) was reportedly attacked hours ago on #Ethereum, with estimated losses of about $11.7M, including ~1,625.4 ETH, ~103.6 tBTC, and ~148K USDC. The stolen assets were transferred to 0x65cb8b and swapped into roughly 5,402.4 ETH (valued at ~$11.4M). On-chain records show that the attacker address, 0x5abb91, was funded via Tornado Cash. The root cause remains under investigation. Attack TX: app.blocksec.com/phalcon/explor…
English
BlockSec retweetledi
.@VerusCoin's Verus-Ethereum Bridge smart contract (0x715185) was reportedly attacked hours ago on #Ethereum, with estimated losses of about $11.7M, including ~1,625.4 ETH, ~103.6 tBTC, and ~148K USDC. The stolen assets were transferred to 0x65cb8b and swapped into roughly 5,402.4 ETH (valued at ~$11.4M).
On-chain records show that the attacker address, 0x5abb91, was funded via Tornado Cash. The root cause remains under investigation.
Attack TX: app.blocksec.com/phalcon/explor…
English
BlockSec retweetledi
🗓 Bi-Weekly Web3 Security Roundup | Apr 27 - May 10
🚨 Spotlight on 11 notable incidents | ~$15.9M lost over the past two weeks
Featuring a vulnerability breakdown and in-depth analysis of selected key cases 👇
blocksec.com/blog/weekly-we…
#Web3Security
English
BlockSec retweetledi
.@TransitFinance was reportedly attacked on #TRON, with estimated losses of about $1.88M. Since the affected contracts are not open-sourced and TRON lacks strong public analysis tooling, our investigation suggests the incident involved abuse of standing unlimited approvals.
Specifically, users had previously granted unlimited USDT allowance to its official approval contract:
TTLaNDdcL5rMfxMS2VL1UCa44ebRCNbqew (TransitApproveGovernanceTron)
The attacker then abused Transit’s own execution chain:
TUfPjKD6PbaWC4gDcA9u1WsJHv6vyUkbc4 (attack executor)
-> TFHc9qsQCiepyyUQynnVVrQwMxZ37Fi15N (TransitProxyV3Tron)
-> TUY2wroSG3hAyjQeWTuaJ8Gn5HJVsb7NPz (TransitMixSwapBridge)
-> TTLaNDdcL5rMfxMS2VL1UCa44ebRCNbqew (TransitApproveGovernanceTron)
-> TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.transferFrom(...) (USDT)
This turned old standing approvals into direct victim-to-attacker USDT transfers. The figure shows one concrete example.
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
BlockSec retweetledi
Alert! The contract 0xeEeEEe53033F7227d488ae83a27Bc9A9D5051756 was exploited resulting in total losses of $5.87M. An attacker-controlled contract (0xD4D5DB5EC65272B26F756712247281515F211E95) was able to invoke the function 0x4112e1c2() to transfer the @trustedvolumes Market Maker's approved assets after registering as the allowed signer.
Attack TX: app.blocksec.com/phalcon/explor…
English
BlockSec retweetledi
.@EkuboProtocol was reportedly exploited on Ethereum hours ago, resulting in a loss of about $1.38 million (17 WBTC). The Ekubo team has urged users to revoke approvals to potentially affected router contracts.
The root cause was insufficient access control in a publicly accessible, closed-source router/wrapper contract (0x8ccb1f), which allowed an attacker to enter the Core lock flow, borrow WBTC via withdraw, and repay the debt using a victim's pre-existing token approval through payCallback -> transferFrom(victim, Core, amount).
Attack TX: app.blocksec.com/phalcon/explor…
Ekubo@EkuboProtocol
There is an active security incident on Ekubo swap router contract on EVM chains only. Liquidity providers are not affected. Starknet is not affected. We are investigating the scope of the issue, but to be safe revoke all outstanding approvals: revoke.cash
English
Add multiple language and better mobile support to our USDT freeze monitor. Have fun!
blocksec.ai/en/usdt-freeze
English
BlockSec retweetledi
Pulled the full event history behind last week's observation.
USDC froze 549 TRON wallets in 10h on Mar 24. USDT froze 521 of them in 9 days (plus 14 it froze earlier).
USDT has unfrozen 90. USDC, 4.
87 sit USDT-unfrozen but USDC-frozen. One just moved ~201K USDT to @binance.
BlockSec Phalcon@Phalcon_xyz
1/3 USDT has been quietly unfreezing addresses that @circle's USDC still has frozen. In multiple cases, funds moved directly to @Binance within hours of removal.
English
BlockSec retweetledi
ALERT! Our system detected a series of unusual transactions involving @wasabi_protocol on #Ethereum and #Base, with total abnormal fund movements of roughly $5.15M.
Preliminary traces suggest that Tornado Cash-funded accounts were later granted ADMIN_ROLE-related privileges and were involved in the relevant WasabiLongPool, WasabiShortPool and WasabiVault flows.
We are sharing the related transactions for visibility and encourage the team to review and clarify the associated fund movements and role changes.
WasabiLongPool & WasabiShortPool:
1) app.blocksec.com/phalcon/explor…
2) app.blocksec.com/phalcon/explor…
WasabiVault:
1) app.blocksec.com/phalcon/explor…
2) app.blocksec.com/phalcon/explor…
English
BlockSec retweetledi
.@AftermathFi on #SUI was reported being attacked several hours ago, with direct losses of about $1.14M. According to the team, only Aftermath Perps was affected, while the exploit was caused by the protocol incorrectly allowing negative builder fees.
Based on our analysis of the on-chain disassembled Move bytecode, the underlying implementation issue was a semantic mismatch: builder fees were expected to be user-approved, non-negative values, but were validated through a signed fixed-point comparison over a u256 interface. In the disassembled calculate_taker_fees path, the critical check was:
// Builder fee is only checked against an upper bound.
// Missing invariant: fee must also be non-negative.
assert!(
ifixed::less_than_eq(
v5.taker_fee,
account::get_integrator_max_taker_fee(
account::get_integrator_config(arg1, v5.integrator_address)
)
),
errors::invalid_integrator_taker_fee()
);
Semantically, both values were expected to represent non-negative fee rates. However, ifixed::less_than_eq() performs a signed comparison. This means that once the attacker set max_taker_fee = 0, they could pass a value such as 2^256 - 10^16, which is interpreted under signed semantics as a negative fee, i.e. -10^16. Since -10^16 <= 0 holds, the check passed.
public fun create_integrator_info(arg0: address, arg1: u256): Option {
let v0 = IntegratorInfo {
integrator_address : arg0,
taker_fee : arg1,
};
option::some(v0)
}
The exploit path was further exposed because create_integrator_info() was publicly callable and did not enforce any permission or fee-bound validation on the supplied taker_fee.
let (v7, v8, v9) = calculate_taker_fees(...);
// v6 = taker PnL
// v7 = normal taker fee
// v8 = builder fee
//
// Intended effect:
// collateral += pnl - taker_fee - builder_fee
//
// If v8 is negative, subtracting it turns it into a positive credit.
position::add_to_collateral_usd(
arg0,
ifixed::sub(v6, ifixed::add(v7, v8)),
arg2
);
As a result, the negative builder fee was not merely accepted; it was transformed into a direct positive collateral credit during taker settlement. The attacker then deallocated that inflated free collateral back into the account balance and withdrew real USDC from the protocol.
Some thoughts:
1) This was not just a fee bypass: the negative builder fee was converted into positive collateral during settlement.
2) The exploit was permissionless: the attacker could self-configure the taker-side cap and inject the negative fee through a public path.
3) The actual loss was realized through the normal deallocate-and-withdraw flow, meaning the inflated collateral became real withdrawable USDC from the vault.
Aftermath Finance (🥚, 🥚)@AftermathFi
Attention Aftermath community - We’ve identified an exploit affecting the protocol. Our team is actively investigating alongside leading security partners. As a precaution, the protocol has been paused and measures are being taken to minimize potential impact to user funds. We’ll continue to share updates as we learn more. Thank you for your patience.
English
BlockSec retweetledi
🗓 Weekly Web3 Security Roundup | Apr 20 - Apr 26
🚨Spotlight on 8 critical incidents | ~$7.04M lost this week
Full analysis with vulnerability breakdown 👇
blocksec.com/blog/weekly-we…
#Web3Security
English
BlockSec retweetledi
ALERT! Our system detected a suspicious transaction targeting an unverified contract (0x143a737bffc6414b61134f513ceed1a64390181a) on Ethereum a few hours ago, with an estimated loss of ~$983K. The root cause was a missing access-control check in the contract’s execute() function, which enabled arbitrary call execution.
By abusing a pre-existing unlimited yvWETH approval from the victim address (0x98289e90d6fc92a8769bc892d006a2baa7705afe), the attacker drained 384.67 yvWETH and later unwound the position for about 429.2 ETH.
Attack TX: app.blocksec.com/phalcon/explor…
🟦 Found by #PhalconSecurity, 🟦 Analyzed via #PhalconExplorer.
English
BlockSec retweetledi
Kevin Lee (@kevinlee_gate), CBO at @Gate - came as a guest today and ended up on stage for the panel on "Regulating a Fragmented World"
Attendance has its privileges 😄
Moderator:
Matthew Jiang (@realMatthewJ), CSO @BlockSecTeam
Speakers:
Chris Barford, Partner, Financial Services Consulting at @EYnews
Julia Charlton, Principal Partner at @Charltonslaw
Joy Lam (@Jl0082021), Founder at Clarient Advisory
Regulatory fragmentation isn't temporary — it's the permanent operating environment. Build for it
English
BlockSec retweetledi
🗓 Weekly Web3 Security Roundup | Apr 13 - Apr 19
🚨Spotlight on 4 critical incidents | ~$310M lost this week
Full analysis with vulnerability breakdown 👇blocksec.com/blog/weekly-we…
#Web3Security
English
BlockSec retweetledi
.@arbitrum Security Council took emergency action to freeze 30,766 ETH held at the Arbitrum One address linked to the @KelpDAO exploit.
The key technical point is how this was executed: it was not a normal transfer signed by the exploiter's key.
Based on the on-chain trace, this appears to have been executed from Ethereum (L1) via governance-level emergency upgrade powers. The Upgrade Executor temporarily upgraded DelayedInbox, invoked a temporary entrypoint to enqueue a delayed L1→L2 message via Bridge.enqueueDelayedMessage(kind=3, ...), and then restored the original implementation.
The critical logic change was that the sender input shifted from the standard msg.sender path to a caller-controlled parameter (then transformed via L1→L2 aliasing), allowing the injected message to carry exploiter-linked sender context. Also, kind=3 maps in Nitro to L1MessageType_L2Message, which allows L2MessageKind_UnsignedUserTx execution on L2, i.e., this path does not require a user signature check.
So the L2 transaction view (“from exploiter to 0x…0DA0”) reflects a chain-level forced state transition, not a standard user-signed transfer.
TX on L1: app.blocksec.com/phalcon/explor…
TX on L2: app.blocksec.com/phalcon/explor…
Arbitrum@arbitrum
The Arbitrum Security Council has taken emergency action to freeze the 30,766 ETH being held in the address on Arbitrum One that is connected to the KelpDAO exploit. The Security Council acted with input from law enforcement as to the exploiter’s identity, and, at all times, weighed its commitment to the security and integrity of the Arbitrum community without impacting any Arbitrum users or applications. After significant technical diligence and deliberation, the Security Council identified and executed a technical approach to move funds to safety without affecting any other chain state or Arbitrum users. As of April 20 11:26pm ET the funds have been successfully transferred to an intermediary frozen wallet. They are no longer accessible to the address that originally held the funds, and can only be moved by further action by Arbitrum governance, which will be coordinated with relevant parties.
English
Hi guys, I've left @BlockSecTeam for a while and I'm excited to share that I'm joining @abf_finance.
I graduated last year and it was my first formal job in crypto, which was a great start to my career.
Here I deepened my knowledge of blockchain through hands-on root cause analysis, and gained a front-row view of the evolving global regulatory landscape, especially in the AML space.
We served top protocols and CEXs, competed with leading institutions like @chainalysis and @trmlabs, and even collaborated with global law enforcements including the @FBI.
I was lucky to be fully trusted and supported by the team at BlockSec even though I was young.
And I'm proud that I brought extensive partnerships and business deals to the company in quite a short time despite the challenges, including many top chains @Plasma @monad @megaeth @StoryProtocol and top protocols on @BNBCHAIN like @lista_dao @flapdotsh @Hertzflow_xyz.
I've built my expertise in marketing and BD here and made lots of great friends along the way.
I have no regrets, only gratitude for this experience.
In the days ahead, I'll share my updates at @abf_finance.
Here I'll leverage my understanding, judgement, and resources in the US crypto market.
Together with @helen_abfinance and the team, we're building toward becoming the tier-1 CEX in the US.
The summer is comming!
English
A sad day... Hopefully the funds can be recovered and this won't leave bad debt that triggers cascading contagion.
BlockSec Phalcon@Phalcon_xyz
.@KelpDAO was reported attacked hours ago, with total losses estimated around $290M. Based on community on-chain analysis (e.g., @banteg), the likely root cause is a compromise of the configured DVN/verifier on the Unichain→Ethereum rsETH bridge route: the route relied on a 1-of-1 check, which may have let a forged/unbacked bridge message pass verification and trigger a drain from the protocol's rsETH Adapter. The exploiter then deposited rsETH into Aave/Compound/Euler and borrowed roughly $236M in assets (WETH, wstETH, WBTC), which is the attacker’s tracked profit so far. @aave has frozen rsETH markets (V3/V4). The incident is still under investigation. The main risk now is contagion: thin rsETH liquidity could turn collateral exposure into bad debt.
English
🤝 BlockSec × @Jumio — Now in one workflow. KYC + KYT, finally stitched together.
> Off-chain identity verification (Jumio)
> On-chain transaction monitoring (BlockSec Phalcon Compliance) @Phalcon_xyz
Built for exchanges, custodians, stablecoin issuers, Web3 projects — ready for FATF, MiCA & beyond. 🚀
#Web3 #KYC #KYT #Compliance #BlockSec
English