Overview:

On January 25, 2026, Aperture Finance (@ApertureFinance) was exploited across multiple chains Ethereum, Arbitrum, and Base resulting in total losses exceeding $3.67 million USD. The root cause in incident was an arbitrary-call vulnerability caused by insufficient input validation, which allowed attackers to abuse existing ERC20 and NFT approvals and drain assets using transferFrom().

The protocol is closed source making the analysis a bit difficult. After decompiling the bytecode and reviewing on-chain execution traces, it became evident that user-controlled parameters were passed into low-level calls without proper constraints. This enabled attackers to redirect execution to token contracts and invoke malicious calls in the context of the victim contracts.

These vulnerabilities fall under OWASP SC Top 10: Arbitrary External Call / Input Validation Failures, a class of issues that becomes especially dangerous when contracts hold broad token approvals.

Smart Contract Hack Overview:

• Attack Transaction: 0x8f28a
• Victim Contract:0xD83d9
• Attacker Addresses: 0xe3e73
• OWASP SC Top 10: SC06:2025 Unchecked External Calls

Decoding the Smart Contract Vulnerability:

• At the bytecode level the internal swap function 0x1d33() constructs and performs a low-level external call using parameters derived from user input: target (address used in call), calldata (call data / function selector), expectedOutput (value compared against a balance delta later)
• The contract did not sufficiently constrain target or calldata to known, safe DEX/router contracts or to an expected function selector. Consequently, an attacker could set target to any contract (including an ERC-20 token contract) and craft calldata that invoked that token’s transferFrom(victim, attacker, amount) (or equivalent). Because the low-level call executes from the victim contract’s context, the token transfer honoured any approvals the victim held, enabling theft.

Two additional enabling factors made the exploit feasible:

• The contract relied on an attacker-controlled expectedOutput to validate the swap result (balance delta comparison), making that check meaningless when the attacker crafted both the call and the expected result.
• The project’s closed-source nature required decompilation to find these specifics, but did not change the attack surface: any low-level call + approvals = risk unless constrained.

Transaction walkthrough

Caller (attacker contract 0x5c92...) calls 0x67b34120() on victim.

Victim executes WETH.deposit() - WETH balance on victim increases by 100 wei.

Victim invokes 0x1d33() with the attacker-provided tuple (target, calldata, expectedOutput).

0x1d33() makes a low-level call(target, calldata).

target is a token contract; calldata maps to transferFrom(victim, attacker, amount).

transferFrom runs in the victim context and moves tokens using prior approval.

0x1d33() checks balanceAfter - balanceBefore == expectedOutput. The attacker-controlled expectedOutput makes this check trivially pass.

Victim continues and calls NonfungiblePositionManager.mint(); attacker receives minted position while approved assets are siphoned.

Mitigation and Best Practices:

• Any function that performs call(target, calldata) must enforce target ∈ {approved routers/DEXes} and restrict calldata to a known set of function selectors + ABI formats. If a swap needs flexibility, route everything through trusted adapters/wrappers rather than accepting raw user-controlled target/data.
• Never validate execution success using user-supplied output deltas; instead compute outcomes from trusted sources (router return values, audited adapters, or balance-change accounting bound to exact input/output tokens). Add hard checks on tokenIn/tokenOut, minimum amounts, and revert on any unexpected token movement.
• Avoid holding broad ERC20 approvals (especially type(uint256).max) inside operational contracts; use per-swap scoped approvals and reset allowances immediately after use. For user flows, prefer Permit2 / EIP-2612 permits, and add explicit restrictions preventing calls that can trigger transferFrom() on arbitrary tokens or siphon assets via pre-existing approvals.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

Aperture Finance Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On December 8, 2025, the DMi token (DMI/WBNB pair) on BSC Chain suffered a AMM reserve-manipulation exploit, resulting in an estimated theft of ~138.68 WBNB (~$124.4K USD) in a single atomic attack transaction.

The vulnerability originated from a critical logic flaw in the DMi token’s transfer() implementation, which redirected /burned the entire transferred amount whenever the recipient was the PancakeSwap pair. This behaviour violated the invariant assumptions of the AMM and caused token balance desynchronization between the pair’s actual on-chain balances and its internal reserves used for swap pricing..

This attack is a canonical case of SC03:2025 Logic Errors under OWASP Smart Contract Top 10; specifically, breaking AMM reserve invariants via erroneous ERC20 transfer semantics.

Smart Contract Hack Overview:

• Attack Transaction:0x2330a
• Victim Contract: 0xfbE04 (proxy), 0xd88c7 (DMi)
• Attacker Addresses:0x47f7B , 0x6DC0D
• Attack Contract:0xdD065
• OWASP SC Top 10: SC03:2025 Logic Errors

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit lies in the transfer-handling logic of the DMi token, specifically within the transfer() function. This function contains a critical branch that treats transfers to the PancakeSwap liquidity pair differently from all other transfers.
• Instead of delivering the transferred tokens to the pair contract; as required by the AMM design, the function diverts the entire amount to an external fee/ burn address (outfee_add). This behavior fundamentally violates the ERC-20 contract expectations under which AMMs operate.
• In a PancakeSwap-style AMM, whenever a user inputs tokens into a swap, the pair contract must actually receive those tokens so its on-chain token balance and its internal reserves remain synchronized. These reserves are the basis of the AMM pricing formula (x * y = k), and every swap relies on the assumption that the pair’s balances accurately reflect the tokens transferred to it.
• However, the DMi implementation breaks this assumption outright. Whenever a caller attempts to send DMi tokens to the pair, the contract silently executes:

if (_isPancakePair(to)) {
    _transfer(owner, outfee_add, amount);
} else {
    _transfer(owner, to, amount);
}

• So, rather than sending tokens to the pair, the contract diverts 100% of the tokens to a fee/burn address (outfee_add) whenever the receiver is the liquidity pool.
• This means the pair contract receives zero tokens, even though the AMM logic believes it should have received amount. As a result, the pair’s true ERC-20 balance diverges immediately from its reserve variables ( reserve0, reserve1), leaving the AMM in a corrupted, desynchronized state.
• This violation alone is enough to break the AMM’s pricing model, but the situation becomes significantly worse because transferFrom() does not apply the same redirect behavior:

_transfer(from, to, amount); // always transfers directly to 'to'

• This asymmetry enabled the attacker to craft precise sequences where certain token inflows to the pair are delivered normally (via transferFrom()), while others are silently removed from the pair's expected balance (via transfer()).
• By combining these two inconsistent behaviors inside a single atomic transaction, the attacker intentionally created moments where the AMM believed the pair possesses a large quantity of DMi tokens, while in reality those tokens were never deposited or have been burned or redirected.

Attack Sequence:

The attacker first obtained a flash loan of ~102.7 WBNB from the Moolah lending contract.

They forwarded the borrowed WBNB into their exploit proxy contract to begin the manipulation.

The contract then performed a sequence of DMi transfers and swaps against the DMi/WBNB PancakePair.

Whenever the attacker used transfer(), the DMi token redirected all tokens away from the pair, preventing the pair from receiving the expected swap input.

When using transferFrom(), tokens were delivered normally to the pair, creating an intentional imbalance between the pair’s actual token balance and its internal reserves.

This alternating pattern caused the AMM to enter a state of reserve desynchronization, as reflected by Swap events showing tiny amount0In but massive amount1Out.

Sync events soon showed the pair’s DMi reserve collapsing to extremely low values (e.g., reserve1 = 502), confirming the manipulated reserve state.

With the AMM’s reserves distorted, the attacker triggered a final swap that overpaid WBNB, far beyond what should occur in a valid trade.

The attacker’s proxy contract received the inflated WBNB output, repaid the flash loan, and sent the remaining 138.68 WBNB as profit to the attacker’s wallet.

Mitigation and Best Practices:

• Ensure transfer() and transferFrom() both route through a single internal function that computes fees and performs token movements identically. Asymmetric behaviors create exploitable ordering conditions inside a single transaction.
• Transfer hooks such as _transfer_before() must never modify balances, trigger value transfers, or update external state. Restrict them to pure accounting and move all externalized reward distribution to explicit claim functions to avoid reentrancy and side-effect desync.
• Transfers to liquidity pools must always deposit the tokens into the pair contract. If fees are required, deduct only a portion and forward the remainder to the pair. Redirecting or burning the full amount instantly breaks AMM reserve invariants.
• Any conditional path that changes how tokens reach a recipient; especially AMM pairs, should be explicitly validated, audited, and bounded. Default behaviors must revert when unsafe or undefined, rather than silently redirecting or consuming tokens.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

DMi Token Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On October 4, 2025, Abracadabra Money (@MIM_Spell), a decentralized lending platform on Ethereum that issues USD-pegged MIM (Magic Internet Money) loans, suffered a critical solvency bypass exploit via the cook() multi-action entrypoint., resulting in an estimated loss of ~$1.7 million USD. This protocol has been attacked for the third time in past 2 years; with heavy losses every time ($13.5M in January 2024, $6.5M in March 2024, and now ~$1.7M in October 2025).

The vulnerability was located in the cook() function of the PrivilegedCauldronV4 and PrivilegedCheckpointCauldronV4 contracts, where an uninitialized “else” branch unintentionally reset internal status flags, disabling collateral checks during borrow operations.

This flaw allowed the attacker to borrow MIM without any collateral, performing the attack across six Cauldron instances and draining approximately 1,724,494 MIM, which was later swapped into ~395 ETH in profits.

Smart Contract Hack Overview:

• Attack Transaction: 0x842aa
• Victim Contracts (Cauldron instances): 0x46f54, 0x28942, 0xce450, 0x40d95, 0x6bcd9, 0xC6D3b
• Attacker Address: 0x1AaaDe
• Attack Contract:0xB8e0A (Self-Destructed)
• OWASP SC Top 10: SC03:2025 Logic Errors

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit lies in the cook() function, which is the core batching mechanism in Abracadabra’s CauldronV4 contracts. This function is designed to let users chain multiple operations such as deposits, borrows, and repayments into a single atomic transaction.

• The cook() function processes an array of encoded actions, executing them sequentially in a loop. Each action (represented by an integer code (e.g., ACTION_BORROW = 5) and associated encoded parameters (datas[])) modifies a temporary execution context called CookStatus, which tracks key control flags such as whether a solvency check must be performed at the end. To track transient control flags during this batch, the function uses a local struct:

struct CookStatus {
    bool needsSolvencyCheck;// Indicates if solvency must be verified at the end
    bool hasAccrued;         // Tracks whether interest has been accrued
}

• Each action can modify CookStatus. For instance:

if (action == ACTION_BORROW) {
    (value1, value2) = _borrow(to, _num(amount, value1, value2));
    status.needsSolvencyCheck = true;
}

• This ensures that any borrow or collateral removal triggers a final solvency validation.

• So, here the vulnerability arises from _additionalCookAction(), designed to allow extended, undefined or custom actions like (action = 0):

 function _additionalCookAction(
    uint8 action,
    CookStatus memory,
    uint256 value,
    bytes memory data,
    uint256 value1,
    uint256 value2
) internal virtual returns (bytes memory, uint8, CookStatus memory) {}

• For any unknown action IDs (action = 0), cook() delegates execution to _additionalCookAction(). In the V4 implementation, _additionalCookAction() returns a default-initialized CookStatus, effectively resetting needsSolvencyCheck to false. This means any prior borrow or collateral removal flag is silently cleared, allowing the final solvency check in cook() to be bypassed:

status = returnStatus; // returnStatus has needsSolvencyCheck = false
...

if (status.needsSolvencyCheck) {
    (, uint256 _exchangeRate) = updateExchangeRate();
    require(_isSolvent(msg.sender, _exchangeRate), "Cauldron: user insolvent");
}

• As a result, the attacker borrowed ~1.7M MIM without sufficient collateral, exploiting the fact that the batching mechanism’s transient control flags were improperly preserved across custom actions.
• The attacker got away with about 1,724,494 MIM- roughly $1.7 million USD at the time of the incident. Those MIM were successively swapped to ETH, yielding approximately 395 ETH in net proceeds before the attacker self-destructed the exploit contract.
• Abracadabra Team acknowledged the incident via their official X account: https://x.com/MIM_Spell/status/1975130787486831018

• The Abracadabra Team also stated that during the incident, no user funds were lost, and the effect has now been already full mitigated.

Attack Sequence:

The attacker funded their exploit contract using Tornado Cash to obfuscate the source of funds.

Then, they called the cook() function on multiple CauldronV4 contracts, passing actions = [5, 0] to trigger the exploit.

The ACTION_BORROW (5) executed a borrow operation, which set the needsSolvencyCheck flag to true.

And, the ACTION_0 then called the empty _additionalCookAction() function, which reset the needsSolvencyCheck flag to false.

As a result, the final solvency check in cook() was skipped, allowing the attacker to bypass collateral verification.

Thus, the attacker successfully kept the borrowed MIM without providing any collateral.

They repeated this sequence across six different CauldronV4 contracts to maximize the stolen amount.

Then, attacker then swapped the stolen MIM through a series of conversions: MIM → DAI → USDC → WETH → ETH.

Finally, the exploit contract self-destructed, transferring approximately 395 ETH in profit to the attacker’s wallet.

Mitigation and Best Practices:

• Avoid relying on transient state across actions. Never assume that a local struct or flag will persist safely through multiple actions. Always design control flags to be immutable or explicitly validated at critical checkpoints.
• When extension hooks return status structs, merge boolean flags (e.g., needsSolvencyCheck ||= returnStatus.needsSolvencyCheck) instead of doing status = returnStatus. This prevents later/unknown actions from clearing security-critical flags.
• Replace silent fall-throughs with an explicit revert("Unknown cook action") for unsupported action codes, or make the default hook explicitly revert() unless intentionally overridden. Never allow a no-op default that can reset state.
• Any custom or undefined actions (like ACTION_CUSTOM) should either be disabled or strictly validated to prevent unintended side effects, especially in multi-action batch functions.
• Use fuzzing, symbolic execution, and formal verification tools to test all possible action sequences, ensuring no combination can bypass security-critical checks.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

Abracadabra Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On September 18, 2025, the NGP token (@newgoldprotocol) deployed on BNB Chain (BSC) suffered a price oracle manipulation attack (OWASP SCWE-028), resulting in an estimated loss of ~$2M USD.

Note: SolidityScan AI Scanner was able to detect all of these NGP Token vulnerabilities that cost them ~2M USD in losses!

The vulnerability stemmed from broken transfer fee logic combined with insecure reliance on a single DEX pair reserve as a price oracle. Specifically, the token contract’s getPrice() function derived token price directly from the PancakeSwap NGP/USDT reserves without safeguards, while the _update() function’s sell-fee logic deducted tokens from the pool before user transfers, allowing the attacker to artificially distort pool reserves.

By chaining these flaws with flash loans, the attacker was able to bypass buy limits, manipulate the pool’s spot price, and drain the liquidity pool.

Smart Contract Hack Overview:

• Victim Contract: 0xd2F26
• Attack Transaction: 0xc2066
• Attacker Address: 0x0305d
• OWASP SC Top 10: SC02:2025 — Oracle Price Manipulation
• OWASP SCWE: SCWE-028: Price Oracle Manipulation

Decoding the Smart Contract Vulnerability:

• The root cause of this vulnerability lies in a combination of three interdependent design mistakes: relying on a spot AMM reserve as an on-chain price oracle, implementing fee logic that mutates the AMM pair’s token balance & calls sync() before the seller’s tokens are actually transferred, and whitelisting the DEAD address which allows bypassing of buy/cooldown protections.
• Each alone is dangerous; together they enable a single-transaction (flash-loan powered) price-manipulation that defeats the contract’s intended limits and extracts liquidity.

• The NGP contract’s getPrice() (its just a convenience wrapper; internally the price comes from: getTokenPrice() ) function calculates the token price using a simple ratio of USDT reserves to NGP reserves in the AMM pool. Using this ratio:

price = (usdtReserve * 1e18) / tokenReserve;

• This approach constitutes the first major flaw in the contract’s price oracle logic. By relying solely on the instantaneous reserve balances of the NGP-USDT pair, the contract exposes itself to manipulation, since any sudden, temporary change in the pool’s reserves can drastically skew the reported token price.
• This spot price is then used to enforce maximum purchase limits through the maxBuyAmountInUsdt check in the _update() function:

require(((value * getPrice()) / 1e18) <= maxBuyAmountInUsdt, "Exceeds max buy amount");

• Because the contract relies exclusively on the instantaneous reserves of a single liquidity pool, the price can be easily manipulated within a single transaction. The attacker could temporarily increase or decrease the token or USDT balances in the pool using a flash loan, causing getPrice() to report an artificially low or high price. This allowed the attacker to bypass the intended buy limits, acquiring far more NGP than the contract’s safeguards would normally permit.

• Compounding this, the contract contains a critical vulnerability in its fee deduction and pool syncing logic. When NGP tokens are sold, the contract deducts several fees- market, burn, treasury, and reward; before the seller’s tokens are fully transferred to the pool. The relevant code is in the _update() function:

super._update(mainPair, treasuryAddress, treasuryAmount);
super._update(mainPair, rewardPoolAddress, rewardAmount);
IUniswapV2Pair(mainPair).sync(); // reserves updated before seller transfer
value = value - totalFee;
super._update(from, to, value);

• By mutating the AMM pair’s reserves and calling sync() before the seller’s transfer, the contract artificially inflates the token price. In normal circumstances, this might have been intended to reflect fee deductions, but in combination with manipulated pool reserves, it allowed the malicious actor to sell NGP at a drastically inflated price.
• During the exploit, a flash loan of approximately $211 million was used to reduce the NGP reserves to extremely low levels, such that selling 1.36 million NGP caused the pool reserves to drop from 477,000 to just 0.035 tokens. This broke the AMM curve (k=xy) and enabled the attacker to drain the pool almost entirely.

• Another critical enabler of the attack was the whitelist logic, which included the DEAD address. Whitelisted addresses bypass key restrictions, including maxBuyAmountInUsdt and the per-account buy cooldown. The attacker initially swapped tokens to the DEAD address to bypass these protections, allowing accumulation of large amounts of NGP across multiple accounts without triggering safeguards. This step was essential to execute the subsequent sell-side manipulation effectively.
• Ultimately, the attacker combined these vulnerabilities in a single atomic transaction: manipulating the price via flash loan, bypassing buy limits through the whitelist, and exploiting premature fee and sync logic to sell at an inflated price. After draining the pool, the attacker converted the stolen funds to ETH; resulting in an estimated loss of ~$2M USD on New Gold Protocol’s side.

Attack Sequence:

The attacker took large flash loans of USDT from multiple DeFi platforms (Morpho, Venus) in a single transaction.

Then, they manipulated the NGP-USDT pool via getPrice(), which relies on instantaneous reserves.

Using the whitelisted DEAD address, they bypassed _checkAndUpdateBuyCount(), _checkTransferCooldown(), and maxBuyAmountInUsdt in _update().

Then, they bought a large amount of NGP at artificially low prices.

Selling these tokens triggered pre-transfer fee deductions and IUniswapV2Pair.sync(), inflating the token price.

Then, the attacker extracted a disproportionate amount of USDT/BUSD liquidity.

Flash loans were repaid, leaving attacker with ~$2M profit.

Detection by SolidityScan:

• SolidityScan was able to detect the all 3 vulnerable hotspots in New Gold Protocol’s NGP Token Contract (BSC) that led to a ~$2M USD exploit .
• Scanning the contract early on with SolidityScan would have flagged this critical vulnerability. This single scan could have saved New Gold Protocol over 2 Million USD!

Try it yourself at: https://solidityscan.com !

Sign up and scan the Victim Contract : NGP Token Contract (BSC) on Mainnet. A detailed vulnerability report will be ready in just few seconds!

Don’t wait for a hack postmortem to learn from — catch critical bugs before they go live.

• Integrate SolidityScan into your development CI/CD pipeline and secure every deploy!

Mitigation and Best Practices:

• Avoid relying on instantaneous spot prices from a single AMM pair. Use time-weighted average price (TWAP) or multi-source oracle feeds to prevent intra-block manipulation and flash loan attacks.
• Deduct fees only after the token transfer is complete. Prematurely mutating pool balances or calling sync() before transfer completion can distort AMM pricing and enable exploitative selling.
• Carefully manage whitelisted addresses. Avoid including addresses like DEAD or any that could be used to bypass buy limits, cooldowns, or fee logic. Limit whitelist modifications to highly trusted admin actions with multi-signature approval.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

NGP Token Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On July 28, 2025, SuperRare’s (@SuperRare) RareStakingV1 contract was exploited for approximately $730,000 USD (~11.9M RARE tokens). The vulnerability stemmed from a broken access control check in the updateMerkleRoot() function, allowing any unauthorized users to submit malicious Merkle roots. This enabled an attacker to calculate a malicious Merkle root, submit it via a frontrunner transaction, and fraudulently claim the tokens. This vulnerability falls under OWASP SC01: Access Control Vulnerabilities.

The stolen funds, valued at ~$730,000, remain in the attacker’s contract and have not yet been swapped yet. Notably, the $RARE token itself was unaffected, with the exploit limited to the staking contract’s reward pool.

Smart Contract Hack Overview:

• Victim Contract: 0xfFB51 (RareStakingV1)
• Attack Transaction: 0xd8137 (executed by a frontrunner)
• Attacker Addresses: 0x5B9B4
• OWASP SC Top 10: SC01:2025 Access Control Vulnerabilities
• OWASP SCWE: SCWE-016 , SCWE-013

Decoding the Smart Contract Vulnerability:

• The root cause of the vulnerability in the SuperRare RareStakingV1 contract lies in a critical logic flaw in access control within the updateMerkleRoot function.
• The updateMerkleRoot function was designed to allow the contract owner or a predefined authorized address to update the currentClaimRoot — a critical state variable that defines the Merkle root used for verifying token claims in the staking system. This update is intended to facilitate legitimate changes to the Merkle tree structure while ensuring that only trusted parties can modify it and thereby protecting the integrity of the staking rewards pool.
• However, the wrong implementation of this function led to a significant loss of funds!

• The function, intended to restrict Merkle root updates to the contract owner or a specific authorized address, contained a misconfigured require statement:

require((msg.sender != owner() || msg.sender != address(0xc2F394a45e994bc81EfF678bDE9172e10f7c8ddc)), "Not authorized to update merkle root");

• This logic uses != (not equal) with an || (OR) operator, which incorrectly allows any address to pass the check. Specifically, the condition evaluates to true for any msg.sender that is not the owner or not the authorized address—conditions that are always met by any address, since an address cannot simultaneously be both the owner and the authorized address.
• This effectively removes all access control, enabling unauthorized users to update the Merkle root. This logic is inverted and flawed!
• The attacker abused this logic flaw by calculating a malicious Merkle root, such as0x93f3c, and utilized claim() function to withdraw approximately ~11.9M $RARE Tokens worth ~$730,000 USD.

Attack Sequence:

Detection by SolidityScan:

• SolidityScan was able to detect the exact vulnerable line in SuperRare’s RareStakingV1 (Ethereum) contract that led to a ~$730K USD exploit .
• Scanning the contract early on with SolidityScan would have flagged this critical vulnerability. This single scan could have saved SuperRare over 730K USD!

• Try it yourself at: https://solidityscan.com ! Sign up and scan the Victim Contract (RareStakingV1) on Ethereum (Mainnet). A detailed vulnerability report will be ready in just few seconds!

• Don’t wait for a hack postmortem to learn from — catch critical bugs before they go live.
• Integrate SolidityScan into your development CI/CD pipeline and secure every deploy!

Mitigation and Best Practices:

• Ensure that only authorized parties (e.g., the contract owner or a predefined trusted address) can update the currentClaimRoot by implementing a strict require check.
• Use a robust access control mechanism, such as OpenZeppelin’s AccessControl, to manage permissions for sensitive functions like updateMerkleRoot.
• Avoid relying solely on msg.sender for access control; incorporate multi-factor validation or role-based checks to prevent unintended access.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

SuperRare Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On July 15, 2025, Arcadia Finance (@ArcadiaFi)— a liquidity and asset management protocol — was exploited for nearly $3.5 million on Base. The attacker leveraged a critical trust assumption flaw in the RebalancerSpot contract. Specifically, a swapData parameter allowed arbitrary external calls to unvalidated router addresses.

By registering their own malicious smart contract as both the router and a whitelisted ArcadiaAccount, the attacker spoofed privileged execution contexts and hijacked control flow. This allowed unauthorized withdrawals from other user accounts via manipulated rebalance flows.

The root issue lies in the assumption that the router address passed via swapData would not be a contract with elevated permissions — which was not enforced in code. Once triggered, the attacker repaid debts of a target account to meet health checks, used the Rebalancer to invoke a custom malicious call, and drained LP tokens from the victim’s position.

This vulnerability is an example of OWASP SC06:2025 Unchecked External Calls.

Smart Contract Hack Overview:

On Base:

• Victim Contract: 0xC7292 (RebalancerSpot)
• Attack Transactions: 0x06ce7, 0x0b9be, 0x72398
• Attacker Addresses: 0x0fa54
• OWASP SC Top 10: SC06:2025 Unchecked External Calls
• OWASP SCWE-042: Insecure Use of External Calls

Decoding the Smart Contract Vulnerability:

• The root cause of the Arcadia Finance exploit lies in the lack of validation in the SwapLogic._swapViaRouter() function. This allowed an attacker to inject a malicious router via the router.call(data) mechanism, leveraging the trusted context of the Rebalancer contract (msg.sender) to perform unauthorized actions on victim accounts.
• The exploit path traverses multiple contracts: RebalancerSpot.sol, Rebalancer.sol, and SwapLogic.sol.

• In the Rebalancer.sol contract, the rebalance() function is externally callable and enables anyone to initiate a rebalance operation if they are registered as the initiator. The attacker first registers as a valid initiator and then calls rebalance() with carefully crafted swapData. This data encodes a malicious router address and a payload (data) that performs unauthorized operations.

• During the rebalance process, the Rebalancer contract calls flashAction() on the user-supplied ArcadiaAccount, designating itself (address(this)) as the callback. This causes the ArcadiaAccount to invoke the executeAction() function on the Rebalancer, completing the flash execution flow.

• Inside Rebalancer.executeAction(), the swap logic is delegated to SwapLogic._swap(), which further calls _swapViaRouter(). Here lies the critical flaw.
• The _swapViaRouter() function performs two key actions:
  1. Approves the exact amountIn of the input token to the attacker-controlled router via safeApproveWithRetry().
  2. Executes an arbitrary low-level call to the router via:

(bool success, bytes memory result) = router.call(data);

• Because this low-level call is performed from within the Rebalancer contract, the called contract (i.e., the malicious router) sees msg.sender == Rebalancer.
• In Arcadia’s architecture, ArcadiaAccount contracts maintain a list of authorized AssetManager addresses — typically including the Rebalancer. Therefore, if a contract is called from the Rebalancer’s context, it can inherit those elevated privileges.
• The attacker exploited this by designing a malicious router contract that, when called, triggered sensitive functions on a different ArcadiaAccount (the victim's). Because the Rebalancer was already whitelisted in that victim account, and because the account was in a “healthy” state (no outstanding debt), the call succeeded. The withdrawal executed as if it were from a trusted manager.
• This resulted in the unauthorized draining of liquidity provider (LP) tokens from user accounts. The Rebalancer approved the malicious contract for token transfers, and the malicious contract called sensitive functions with elevated context — effectively bypassing all access control.
• The total loss amounted to approximately $3.5 million across LP positions, all stemming from this unchecked assumption: that the router supplied in swapData would always point to a safe, external DEX (like Uniswap or 1inch).
• The exploiter then swapped the stolen funds for ~840 $ ETH & bridged them from Base to Ethereum. Currently, the stolen fund is parked at:
  https://basescan.org/address/0x0fa54e967a9cc5df2af38babc376c91a29878615 (~3.6M USD)

• Arcadia Team promptly acknowledged the attack and released a statement via X. More details to follow from official sources.
  Read here: https://x.com/ArcadiaFi/status/1944984622183370867

Attack Sequence:

Attacker creates multiple Arcadia Accounts and takes ~$1.5B flashloan from Morpho Blue to fund the exploit.

Then, links Asset Manager to their own Arcadia Account, setting self as initiator. And creates a small LP position to trigger the rebalance flow.

Fully repays the debt of a victim Arcadia Account using the flashloan — bringing it to a “healthy” state.

Calls rebalance() on their own account, injecting malicious swapData.

Inside SwapLogic._swapViaRouter(), the attacker’s malicious contract is called via router.call(data).

That malicious contract executes arbitrary calls to the victim Arcadia Account (e.g., calling sensitive functions). These calls succeed because:
1. The Rebalancer is already whitelisted in the victim account.
2. The account is healthy (no active debt), so failsafes are bypassed.

Victim’s funds are transferred out to the attacker.

And the flashloan is repaid using part of the stolen funds.

Attacker now retains the remaining stolen assets.

Detection by SolidityScan:

• SolidityScan was able to detect the exact vulnerable line in Arcadia Finance’s RebalancerSpot (Base) contract that led to a $3.5M exploit .
• Scanning the contract early on with SolidityScan would have flagged this critical vulnerability. This single scan could have saved Arcadia Finance over $3.5M USD and protected user funds.

• Try it yourself at: https://solidityscan.com ! Sign up and scan the Victim Contract (RebalancerSpot) on Base (Mainnet). A detailed vulnerability report will be ready in just few moments!

• Don’t wait for a hack postmortem to learn from — catch critical bugs before they go live.
• Integrate SolidityScan into your development CI/CD pipeline and secure every deploy!

Mitigation and Best Practices:

• Ensure that only trusted DEX contracts (e.g., Uniswap, 1inch) can be passed as routers in swapData. Maintain an allowlist of approved router addresses.
• Also, do not rely solely on msg.sender for access control in contexts involving delegate calls or external router calls. Add explicit checks on the origin of privileged actions.
• Before executing arbitrary low-level call()s (like in _swapViaRouter()), verify that the target contract cannot execute unintended privileged logic.
• Before performing privileged actions like withdrawals, verify that the action is appropriate for the account’s state (e.g., debt must be active, initiator must be whitelisted, etc.).
• Carefully audit any flow that uses flashloans or allows callbacks — especially if it allows arbitrary calldata injection — since these can introduce hidden reentrancy and privilege escalation vectors.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

Arcadia Finance Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On July 9, 2025, GMX (@GMX_IO) — a decentralized perpetuals trading protocol on Arbitrum — was exploited for over $42 million. The attacker abused a refund-based reentrancy-like vulnerability in the PositionManager.executeDecreaseOrder() function, along with an internal accounting desynchronization in the GLP pricing mechanism.

The root cause includes the implicit assumption in executeDecreaseOrder() that the _account parameter is an Externally Owned Account (EOA), when in fact it can be a malicious smart contract. This vulnerability is an combination of OWASP SC05: Reentrancy Attacks and SC03: Logic Errors.

This allowed the attacker to deploy a malicious contract and spoof GMX’s keeper execution flow to gain reentrant access into core vault logic. By hijacking control flow during ETH refunds and exploiting a stale getAum() (Assets Under Management) calculation, the attacker repeatedly minted GLP at a low price, opened phantom short positions that artificially inflated AUM, and redeemed GLP at a higher price—draining liquidity from GMX’s vault across ETH, USDC, and WBTC.

Smart Contract Hack Overview:

• Victim Contract: 0x489ee (vault), 0x321f6 (GLP Manager),
• Attack Transaction: 0x03182 (Arbitrum)
• Attacker Addresses: 0xDF334, 0x7D3BD
• OWAPS SC Top 10: SC05: Reentrancy Attacks and SC03: Logic Errors.

Decoding the Smart Contract Vulnerability:

• The root cause of the GMX exploit lies in the improper trust assumption in the PositionManager.executeDecreaseOrder() function, which allowed a malicious smart contract to hijack execution flow, and in the flawed AUM (Assets Under Management) accounting logic in the GlpManager.sol during leveraged position handling.
• This vulnerability led to a sophisticated multi-step attack where the attacker was able to artificially inflate the protocol’s AUM, redeem GLP for more assets than deserved, and ultimately extract over $42 million worth of tokens from the GMX vault.

• In the PositionManager.sol contract, the function executeDecreaseOrder() is designed to be called by a privileged keeper bot, and takes the _account as a parameter representing the user whose position is being reduced.

IOrderBook(orderBook).executeDecreaseOrder(_account, _orderIndex, _feeReceiver);

• The vulnerability arises because _account can be any address, including a smart contract, yet GMX implicitly assumes it to be an EOA (Externally Owned Account).
• Within the executeDecreaseOrder(),the function internally calls getDecreaseOrder(), which returns the full position details — including size, index token, and collateral. Then, after updating short data, the system enables leverage and calls into the order book to execute the order. During this process, the _account (attacker’s contract) is refunded ETH for gas costs using a call{value: ...} with no gas limit, which causes the fallback function of the attacker’s contract to execute.
• This gives the attacker a reentrancy window to call other GMX functions while the state is in an inconsistent, pre-settlement phase — specifically, they were able to call increasePosition() and open large short positions on WBTC while enableLeverage = true inside the callback of their malicious contract.

• The second key vulnerability lies in how GlpManager.sol calculates the value of GLP tokens during redemption, using the getAum() function.

function getAum(bool maximise) public view returns (uint256) {
    ...
    uint256 price = maximise ? vault.getMaxPrice(token) : vault.getMinPrice(token);
    ...
    uint256 size = _vault.globalShortSizes(token);

    if (size > 0) {
        (uint256 delta, bool hasProfit) = getGlobalShortDelta(token, price, size);
        if (!hasProfit) {
            aum = aum.add(delta); // Unrealized short losses are added to AUM
        } else {
            shortProfits = shortProfits.add(delta);
        }
    }
    ...
}

• The problem here is timing. When a short position is first opened (via reentrancy), the short size is updated immediately, but the average short price lags behind. During this in-between state, the system wrongly assumes that the position is opened at a much lower price, resulting in unrealized losses being calculated and added to AUM.
• Thus, the AUM — used in GLP redemption via unstakeAndRedeemGlp() to determine how much value each GLP token represents — becomes artificially inflated due to mispriced unrealized losses, even though no real losses exist yet.
• This allowed the attacker to redeem their GLP at an overstated value, exploiting the stale AUM calculation and draining excess assets from the vault.

Attack Sequence:

The attacker deploys a malicious contract compatible with GMX’s OrderBook interface and places a crafted decreaseOrder() using this contract.

GMX’s keeper bot calls executeDecreaseOrder() with the attacker's contract as _account.

As part of order execution, ETH is refunded to _account using call{value:}. This triggers the fallback function in the attacker's contract — creating a reentrancy window

Within the callback, the attacker immediately reenters GMX logic and calls increasePosition()to open a large short on WBTC.

The vault updates globalShortSizes right away, but globalShortAveragePrices still reflects old data. This discrepancy leads the system to believe the short is deeply underwater.

When getAum() is called, the unrealized loss from the perceived underwater short is added to AUM — artificially inflating it.

The AUM becomes artificially inflated, making GLP appear more valuable.

The attacker then calls unstakeAndRedeemGlp() to redeem GLP tokens at the inflated AUM rate — extracting more assets than deserved.

The attacker repeats the process across various vault tokens (e.g., WBTC, ETH, USDC), draining ~$42 million from GMX’s liquidity pool.

• GMX Team confirmed that the exploit is isolated to GMX V1’s GLP pool on Arbitrum. V2 contracts, GMX tokens, and liquidity pools on Avalanche remain unaffected. All GLP trading, minting, and redemption has been paused on both Arbitrum and Avalanche as a precaution. More details can be found in this X thread:

• Team member from GMX (@xdev_10) also confirmed the order keeper bot was not compromised. It executed the order flow as expected. The exploit originated from the malicious smart contract crafted by the attacker, which was used to create and hijack execution during order fulfillment.
• GMX has sent an on-chain message to the exploiter, offering a 10% (nearly 4M USD) white-hat bounty for the return of funds. “If 90% of the stolen assets are returned within 48 hours, GMX commits to no legal action.” The message was embedded in this on-chain transaction.

• GMX Team is working with security partners and lead auditors to conduct a full investigation. A detailed post-mortem will be published after the review is complete. Preliminary analysis can be found here:

Mitigation and Best Practices:

• Never assume an address is an EOA. Always validate inputs like _account to avoid smart contract callbacks. Also avoid using call{value: ...} without gas limits. Prefer pull-based refund mechanisms or deferred withdrawals.
• Atomically update globalShortAveragePrices alongside globalShortSizes to prevent AUM miscalculations during leveraged actions.Use pull-based refunds, reentrancy guards, CEI pattern, and smooth AUM calculations to harden liquidity-sensitive logic.
• Ensure off-chain bots verify all assumptions (e.g., _account type) and consider invariant testing to catch stale-state exploits early.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

GMX v1 Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On June 26, 2025, ResupplyFi (@ResupplyFi) — a decentralized lending protocol — was exploited for approximately $9.56 million. The attacker targeted the ResupplyPair contract which uses the manipulated rate, just hours after its deployment. The root cause was an exchange rate manipulation bug triggered via a classic ERC4626 “first donation” vault attack, resulting in a division-by-large-value scenario that collapsed the exchangeRate to zero.

This manipulated rate was used to compute the borrower’s Loan-to-Value (LTV) in the _isSolvent() check. Since ltv = 0 when exchangeRate = 0, the attacker bypassed the solvency check and borrowed $10 million reUSD using just 1 wei of collateral. This vulnerability falls under OWASP SC03: Logic Errors.

Smart Contract Hack Overview:

• Victim Contract: 0x6e90c
• Attack Transaction: 0xffbbd
• Attacker Addresses: 0x6D9f6, 0x31129
• OWASP SC Top 10: SC03: Logic Errors.

Decoding the Smart Contract Vulnerability:

• The root cause of the vulnerability that enabled the ResupplyFi exploit stemmed from a flawed implementation of the _updateExchangeRate() and _isSolvent() functions within the ResupplyPairCore.sol contract. Specifically, the contract relied on an inverse exchange rate calculation using a price oracle tied to an ERC4626 vault (cvcrvUSD), whose share price (pricePerShare) was used directly to derive the value of collateral.

• In _updateExchangeRate(), the contract retrieves the price using an oracle call to getPrices(address(collateral)), which returns the pricePerShare of the underlying ERC4626 vault. It then inverts this price using 1e36 / price, because debt is denominated in units of collateral.

price = IOracle(_exchangeRateInfo.oracle).getPrices(address(collateral));

_exchangeRate = 1e36 / IOracle(_exchangeRateInfo.oracle).getPrices(address(collateral));

• Because the vault was nearly empty, the attacker exploited the ERC4626 donation logic — they made a small deposit and a large donation to the vault, drastically inflating pricePerShare. As a result, the oracle returned an extremely high price.
• This led to 1e36 / price being evaluated to 0 due to Solidity’s integer division flooring behavior. Critically, the implementation did not include any validation like require(_exchangeRate > 0), so this invalid value was saved to storage as the current exchange rate.

• This incorrect _exchangeRate = 0 value then flowed into the _isSolvent() function, which uses the exchange rate to calculate a borrower's Loan-to-Value (LTV) ratio.
• The _isSolvent() function is responsible for ensuring that users cannot borrow more than they are allowed to, based on the current value of their collateral. It blindly uses the stored _exchangeRate to compute the user's effective LTV ratio. However, if _exchangeRate is zero (as manipulated by the attacker), then the entire numerator of the LTV formula collapses to zero, and _ltv = 0.

_ltv = ((_borrowAmount * _exchangeRate * LTV_PRECISION) / EXCHANGE_PRECISION) / _collateralAmount;

• This causes the function to always return true, regardless of how much the user is attempting to borrow, as long as they have a non-zero amount of collateral (even 1 wei). This behavior completely bypasses the core economic invariant that the borrowed amount must be backed by sufficient collateral.
• As a result, the attacker was able to borrow $10 million worth of reUSD using just 1 wei of collateral. After swapping and redistributing the stolen funds, they successfully escaped with an estimated profit of $9.56 million, split across 2 addresses.

Attack Sequence:

Attacker deposited 1 wei into an empty cvcrvUSD ERC4626 vault, then made a large donation to artificially inflate pricePerShare.

Called borrow() on the newly deployed ResupplyPair, triggering an oracle price fetch and exchangeRate = 1e36 / price.

Due to the inflated price, exchangeRate computed to zero via Solidity floor division.

The _isSolvent() check returned true, since LTV became zero, bypassing collateral validation.

Attacker borrowed 10 million reUSD using just 1 wei of collateral, and walked away with ~$9.56 million split across multiple wallets.

• Within few hours of the exploit, ResupplyFi governance executed a series of emergency transactions (e.g., execTransaction) to zero out borrow limits and reset interest rates, as seen in UpdateRate and SetBorrowLimit events.

• These actions were intended to freeze the protocol's borrowing capability and limit further losses while further investigations are on-going. Read more here: https://x.com/ResupplyFi/status/1938092252431036491

Mitigation and Best Practices:

• Always add sanity checks like require(_exchangeRate > 0) and upper/lower bounds to prevent zero or extreme values from being written to storage due to manipulated oracle inputs or division errors.
• Also, avoid using uninitialized or low-liquidity ERC4626 vaults as collateral or oracles. Consider enforcing a minimum liquidity threshold before a vault can be used for borrowing or price calculations.
• Ensure a minimum borrow threshold relative to the value of collateral. And temporarily cap borrowing limits on newly deployed pairs until they are battle-tested.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

ResupplyFi Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview:

On June 17, 2025, the Ethereum-based liquid staking protocol Meta Pool (@meta_pool) was exploited through a critical vulnerability in its Staking contract, which inherits from OpenZeppelin’s ERC4626Upgradeable standard. The vulnerability stemmed from the failure to override or restrict the publicly exposed mint() function, which allowed attackers to mint 9701 mpETH without providing any ETH. This vulnerability falls under OWASP SC01: Access Control Vulnerabilities and is indicative of SCWE-016.

The attack impacted multiple chains, including Ethereum, Optimism, and Linea, leading to a combined loss of approximately 56.35 ETH (~$142K) across these networks. The exploit was first front-run by an MEV bot called Yoink, and later reproduced manually by a separate attacker using a flash loan.

Meta Pool’s design enables users to stake ETH/WETH and receive a liquid staking token called mpETH, which is redeemable either instantly (via an internal liquidity pool) or with delay (via validator exits). The Staking.sol contract, built atop ERC4626, manages this staking logic — but a misconfigured function left the system open to free minting.

Smart Contract Hack Overview:

• Victim Contract:
  0x3747484567119592ff6841df399cf679955a111a
• Attack Transactions:
  0x57ee…fa69 (primary mint & swap)
  0x691c…f002
  0x4858…a747
  0x4f43…ef9 (MEV-Bot txn)
• Attacker Address:
  0x48f1d0f5831eb6e544f8cbde777b527b87a1be98
• Stolen funds Parked at: 0x45dd4
• OWASP SC Top 10: SC01: Access Control Vulnerabilities
• OWASP SCWE: SCWE-016.

Decoding the Smart Contract Vulnerability:

• The root cause of the vulnerability that led to Meta Pool exploit lies in the unrestricted exposure of a critical inherited function — mint()—from OpenZeppelin’s ERC4626Upgradeable standard, which was not correctly overridden or access-controlled in the Meta Pool staking contract-Staking.sol .
• As a result, attacker was able to mint a large amount of mpETH tokens without providing any ETH, violating the core economic invariant of the system—that each mpETH token must be backed 1:1 with ETH.

• The mint() function in the ERC4626 standard is designed to allow users to request a specific number of shares (in this case, mpETH) and have the contract calculate how much ETH needs to be deposited. Internally, mint() delegates this logic to _deposit(), which handles asset transfers, pool interactions, and share minting.
• However, in Meta Pool’s implementation, mint() was: Left fully exposed to the public, not marked as payable, and lacked any ETH transfer validation or access restrictions.
• This meant that any user could call mint() without sending ETH, and the contract would still proceed with the _deposit() logic, assuming ETH had been received.

• Inside _deposit(), the process is split into two phases:
  1. Swap ETH for mpETH from the internal liquidUnstakePool via _getmpETHFromPool().
  2. Mint new mpETH shares for any remaining unmet portion.
• Crucially, the swap logic in _getmpETHFromPool() is only triggered if both ETH is received and the pool has available mpETH. Since mint() is not payable, and no ETH is held by the contract at that point, the swap fails or is skipped entirely. The fallback logic kicks in and mints the full amount of shares, despite no ETH being provided.
• Recognizing this oversight, the attacker executed the exploit in two stages:

1. First, they used a flash loan to borrow WETH, converted it to ETH, and called the depositETH() function to drain all mpETH from the internal liquidity pool, ensuring that the _getmpETHFromPool() logic would be bypassed in future calls.

2. Then, they directly called the unrestricted mint() function, which minted thousands of mpETH for free due to the missing ETH validation and the empty pool

• Finally, the attacker swapped part of the minted mpETH for ETH, repaid the flash loan, and kept the rest as profit. The attack succeeded entirely within the bounds of the contract’s logic, due to unsafe reliance on inherited behavior and insufficient validation around economic invariants.

Attack Sequence:

Attacker flash-loaned 200 WETH from Balancer; converted 107 WETH to ETH.

Called depositETH() to drain all mpETH from the liquidUnstakePool.

Invoked mint() to mint ~9702 mpETH without providing any ETH.

Swap logic was skipped; fallback minting executed

Swapped some mpETH to ETH, repaid flash loan, and kept ~56.35 ETH profit.

• Upon identifying the exploit, Meta Pool swiftly disabled the mpETH token's transfer functionality by upgrading the contract. This prevented further unauthorized movement of the exploited tokens across chains or into liquidity pools. Read more details here: https://x.com/meta_pool/status/1935119387486519582

• Meta Pool maintained open channels with the community through Discord and hosted a Twitter Space on June 17 to directly address user concerns. They committed to continuous updates and scheduled time during Governance Call 19 to ensure DAO members were informed and engaged in shaping the recovery and future safeguards.

Mitigation and Best Practices:

• Always review and override inherited public/external functions (e.g., mint(), redeem()) from standards like ERC4626, ERC20, or upgradeable contracts.
• Ensure that any function that depends on receiving ETH is marked payable and includes explicit value checks (require(msg.value > 0)) before executing asset logic.
• Avoid exposing the raw interfaces of standards like ERC4626 or ERC20 directly to users.
• Instead, expose custom facade functions (e.g., secureMint(), safeStake()) that include additional safety checks, protocol-specific validations, and allow fine-grained control. Also, deactivate or restrict base standard functions that are not meant to be user-facing in the protocol context.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

Meta Pool Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

On June 19, 2025, a previously dormant DeFi protocol called Bankroll Network (@bankroll_status) — specifically, its BankrollNetworkStack contract—was exploited due to a critical integer underflow vulnerability in its sell() function. This vulnerability existed in contracts deployed on Ethereum Mainnet and Binance Smart Chain (BSC). The attacker exploited this flaw to manipulate dividend accounting and drain funds from users who had previously interacted with or approved the contract. The attack has resulted in an approximate loss of $65,000 so far. This vulnerability is an example of OWASP SC08:2025 — Integer Overflow and Underflow.

Bankroll Network was previously exploited for nearly $235K on September 23rd, 2024. Read more here: https://blog.solidityscan.com/bankroll-network-hack-analysis-e77fd8442dfa

Smart Contract Hack Overview:

• Victim Contract: BSC: 0xAdEfb
• Attack Transactions: Ethereum: 0x8905a , BSC: 0x7226b
• Attacker Addresses: 0x2deA4 , 0x172Dc
• OWASP SC Top 10: SC08:2025 — Integer Overflow and Underflow

Decoding the Smart Contract Vulnerability:

• The root cause of the vulnerability lies in the sell() function of the BankrollNetworkStack contract. Thesell()function is intended to allow users to burn tokens in exchange for ETH-equivalents, update internal dividend trackers, and allocate exit fees. However, its internal logic failed to securely handle accounting updates, especially for signed integers.
• The sell()function directly subtracts a calculated signed integer value from a user’s payout balance without overflow or underflow protection:

payoutsTo_[_customerAddress] -= _updatedPayouts;

• In Solidity 0.6.8, such arithmetic on int256 types does not revert when an underflow occurs. This is unlike Solidity 0.8+, where built-in checks prevent such errors.
• The contract was compiled with Solidity 0.6.8, a version in which integer overflow and underflow do not revert by default. As a result, attacker was able to exploit this legacy behavior to manipulate contract state.
• Users who have interacted with the compromised Bankroll contracts are strongly advised to immediately revoke token approvals to prevent unauthorized withdrawals.
• If you have previously approved any of the following BSC contract addresses, revoke permissions as soon as possible:

0x16d0a151297a0393915239373897bcc955882110

0xAdEfb902CaB716B8043c5231ae9A50b8b4eE7c4e

0x0a15B914388d48d77fE70c8a832cD992dD05e76E

0x313E71df70b106BD8e456cfbAfd3583595EdE490

0xeF6676536a1d98942d149f52708770e11Db47BcE

Mitigation and Best Practices:

• Upgrade all smart contracts to Solidity version 0.8.0 or later, which includes automatic overflow and underflow checks for both uint and int types, eliminating silent arithmetic errors like the one exploited in this attack.
• If using older Solidity versions is unavoidable, implement or import a SafeMathInt library to securely handle arithmetic operations on int256 values, ensuring overflows/underflows revert safely.
• Add explicit state transition validations (e.g., bounds checks on payouts and balances) to ensure logical consistency and prevent arithmetic or accounting manipulation.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord

Bankroll Network Hack Analysis was originally published in SolidityScan on Medium, where people are continuing the conversation by highlighting and responding to this story.