NGP Token Hack Analysis

NGP Token Hack Analysis

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