Alert Notic
Attack Tx:
bscscan.com/tx/0x6d060e0c46f…
Victim contract:
0x763FaE69d2b7882Ed6470BBcABA3A0B368c8f1D9
Attacker: 0x6bfdd4a4e895d5437b3073a3bc22a3ff6d3227fb
Chain: BNB Smart Chain
Loss: ~ $245k
Preliminary Root Cause Analysis:
The core issue appears to be related to the `getUserLPAmount` function producing incorrect LP share calculations under extreme conditions
Key observations from preliminary analysis:
1. The protocol relies on internal reserve tracking that is not strongly validated against real-time pool balances and lacks protection mechanisms to defend against flash loan manipulation.
2. Under flash-loan-induced extreme liquidity states, the return value of `getUserLPAmount` becomes significantly distorted.
3. The function with selector `0x3cc9` (likely involved in reserve synchronization, LP burning, redemption, or reward distribution logic) does not appear to include deviation checks, threshold guards, or rollback conditions when reserve and actual pool states diverge substantially.
4. The combination of:
- Calling `processLPReward`
- Toggling internal state (selector `0x0f2de53f`)
- Performing a very large buy of LED tokens directly to the dead address
triggers abnormal behavior, including unexpected `LPRewardDistributed` events and abnormal increases in pool WBNB balance.
5. The attacker exploits this inconsistency by first massively buying LED to the burn address (causing price impact + abnormal reward/pool inflation), then immediately selling the acquired LED back, extracting profit from the distorted pool state.
Yesterday, we received a theft incident request.
We traced the on-chain flows, identified the root cause, and conducted remote incident response on the victim’s computer.
Attacker address:
0xd1a5ddddac356fb4c57d7de55740366684ef1a59
The attacker stole funds from 10 victim wallets across 10 transactions, totaling $41k.
Funds were stolen as USDC on Base, then bridged to Solana, and ultimately flowed to ChangeNOW.
Root cause: downloading a malicious file.
Malware sample hashes:
hash1: 0be8e24e4faf7055cb0d458332d2e7f92660b49b7faa182fdee661670f96783d
hash2: 0df30d75b43433200fa3b5a6ab7e4eea8f9a755c5cd4cdfe019c3be837b7121f
Sample download link:
limewire.com/d/4ANfQ#EgO3wGQ…
Based on historical samples, this appears to be large-scale malware targeting Web3 practitioners, often bundled with third-party software.
If you ever experience a theft incident and need assistance, feel free to contact https://t[.]me/S7iter.
Of course, we sincerely hope you never have to face situations like this.
We’ve detected an ongoing attack targeting a Chess Bank–related contract on Ethereum.
Victim contract: 0x609e0f0cb16e53878ba5e959a22fc7fcd81b124a
Attacker: 0xf936716c361ae0e4ca88db2f2783a590dd3d6fac
Attacker contract: 0x866032125e9e828df7181388f18ef64544caee45
This appears to be caused by a rounding error vulnerability, and we expect similar attacks to increase in frequency going forward.
There was also a completely different historic attack on Cheese Bank in 2020 — where an attacker used flash loans and price oracle manipulation to drain ~$3.3M from the protocol. Full analysis: https[:]//peckshield.medium.com/cheese-bank-incident-root-cause-analysis-d076bf87a1e7
A few days ago, our team discovered a critical vulnerability in a project’s governance contract and attempted responsible disclosure. The report was removed, our researcher was removed from the group, and shortly afterward the team withdrew approximately 3M in liquidity. No further communication has been received.
As a security firm, we believe that responsible handling of vulnerabilities and transparent communication are essential for the long-term health of the Web3 ecosystem. We hope the team will address the issue appropriately and uphold the security standards the community relies on.










