AI SPACE (AIS) Exploit — Permissionless `PendingMint` Inflation + Unprotected Vault Drain

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2023-11-AIS_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/AIS_exp.sol.

Vulnerability classes: vuln/access-control/missing-modifier · vuln/arithmetic/overflow

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not compile together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: sources/AISPACE_6844Ef/AISPACE.sol. PoC: test/AIS_exp.sol.

Key info#

TL;DR#

The AIS token bolts a "market reward" mint mechanism onto a standard OZ ERC20. Every transfer that touches a registered AMM pair bumps a global counter PendingMint by 4–8 % of the transferred amount (AISPACE.sol:973-998). A separate, permissionless function harvestMarket() then mints PendingMint − MintPosition brand-new AIS to the MarketAddress vault (:968-972).

Two design flaws make this catastrophic:

1. setSwapPairs(address) lost its onlyOwner modifier — the //onlyOwner is commented out (:949-951). Anyone can register any address as a "pair", giving it the inflationary transfer semantics.
2. PendingMint accrues with no backing. Because it grows on every pair-touching transfer (including zero-net round-trips), an attacker can pump it arbitrarily high by shuttling AIS in and out of the pair via pair.skim() — then harvestMarket() mints that inflation as real AIS.

The vault (MarketAddress = 0xFFAc2Ed…) is itself broken: it exposes a permissionless setAdmin() and an admin-only transferToken(). So the attacker makes themselves admin and walks the freshly-minted AIS out of the vault.

The full attack (one atomic tx, financed by a 3,000,000 USDT PancakeV3 flash loan):

1. Buy 142,406 AIS from the AIS/USDT pair with the flash-loaned 3M USDT.
2. Pump PendingMint — 100 rounds of transfer(pair, 128,165 AIS) + pair.skim(self) round-trips. Each leg bumps PendingMint by 4–8 % with zero net AIS cost (skim returns what was sent).
3. harvestMarket() — mints 1,543,728 AIS to the vault.
4. Steal the mint — vault.setAdmin(self) then vault.transferToken(AIS, self, 90 % = 1,389,357 AIS).
5. setSwapPairs(self) so the attacker's own sell into the pair takes the buy (untaxed) path.
6. Dump ~1.53M AIS into the pair → receive 3,062,186 USDT.
7. Repay 3,001,500 USDT (3M + 0.05 % fee). Net +60,686.88 USDT.

Background — what AISPACE does#

AISPACE (source) is an OZ-5 ERC20 (with ERC20Burnable, ERC20Pausable, Ownable) plus a custom "market reward" layer:

• Registered pairs — Pairs[addr] marks AMM pairs. Set via setSwapPairs().
• Custom transfer routing — transfer/transferFrom delegate to _transferAIS, which branches on whether the counterparty is a pair (a "buy" vs a "sell"). Both branches accrue PendingMint and PendingBrun.
• PendingMint / MintPosition — a global accumulator of "rewards owed"; harvestMarket() mints the delta to MarketAddress.
• PendingBrun — a per-account pending-burn ledger; crucially, the overridden balanceOf subtracts PendingBrun[account] (:1008-1010).

Total supply at the fork block was ~1.0e9 AIS (minted to the vault holder in the constructor, :939). The AIS/USDT pair held only 3,271 AIS and 3,068,743 USDT of effective reserve liquidity — the prize.

The vulnerable code#

1. setSwapPairs is permissionless (access control commented out)#

function setSwapPairs(address _address) public { //onlyOwner {
    Pairs[_address] = true;
}

AISPACE.sol:949-951 — the onlyOwner guard is commented out. Anyone can flag any address as a pair, switching its transfer accounting into the inflationary branch.

2. The pair-touching transfer paths inflate PendingMint for free#

function _transferAIS(address from, address to, uint256 value) private returns (bool) {
    if (Pairs[from]){                                   // a "buy" (tokens leaving the pair)
        _transfer(from, to, value);
        PendingBrun[to]  = value*5/100;
        PendingMint     += value*4/100;                 // ⚠️ +4% accrual, unbacked
        IMarketVault(MarketAddress).addMarketValue(value*4/100);
        return true;
    }
    if (Pairs[to]){                                     // a "sell" (tokens entering the pair)
        require(balanceOf(from) > value*111/100, "insufficient funds for burn!");
        _transfer(from, to, value);
        PendingBrun[from] = value*10/100;
        PendingMint      += value*8/100;                // ⚠️ +8% accrual, unbacked
        IMarketVault(MarketAddress).addMarketValue(value*8/100);
        return true;
    } else { ... }
}

AISPACE.sol:973-998. PendingMint rises every time AIS moves to/from a pair, regardless of whether any net value changed hands.

3. harvestMarket mints the accrued inflation, permissionlessly#

function harvestMarket() public {
    require(PendingMint>MintPosition, "No Pending available");
    _mint(MarketAddress, PendingMint-MintPosition);     // ⚠️ mints unbacked AIS to the vault
    MintPosition = PendingMint;
}

AISPACE.sol:968-972 — no access control, no rate limit.

4. The balanceOf override + skim make the pump cost-free#

function balanceOf(address account) public override view virtual returns (uint256) {
    return ERC20.balanceOf(account) - PendingBrun[account];
}

AISPACE.sol:1008-1010. The attacker shuttles AIS through pair.skim() (which pays out realBalance − reserve) so the AIS round-trips back at no net cost, while each leg keeps bumping PendingMint.

5. The vault's setAdmin is also permissionless#

The MarketAddress vault (0xFFAc2Ed…, unverified) exposes setAdmin(address) with no access control and an admin-gated transferToken(token, to, amount). In the trace (output.txt:5916-5928) the attacker calls setAdmin(self) then transferToken(AIS, self, 1,389,357 AIS) — straight out of the vault.

Root cause — why it was possible#

The protocol mints "rewards" off an accumulator that anyone can inflate, and nothing ties that accumulator to real economic activity:

1. No access control on setSwapPairs lets an attacker pick which addresses get inflationary transfer semantics — including, at the end, themselves, so they can dump AIS through the untaxed buy path.
2. PendingMint accrues on gross transfer volume, not net value. A wash trade (send AIS to the pair, skim it right back) generates fee-like accrual with zero capital at risk. The skim round-trip is the engine: the attacker's AIS balance is conserved while PendingMint ratchets up.
3. harvestMarket() is permissionless and unbounded — it mints the entire accrued delta of an attacker-controlled number into a single address.
4. The reward sink (MarketAddress vault) has a permissionless setAdmin, so even though the inflation lands in the vault rather than the attacker's wallet, the attacker simply seizes admin and sweeps it.

Each flaw alone is bad; composed, they let an attacker conjure ~1.54M AIS from nothing and sell it into the pool's real USDT reserves.

Preconditions#

• An AIS/USDT AMM pair exists with real USDT liquidity (≈3.07M USDT here).
• setSwapPairs is reachable without ownership (it is — guard commented out).
• harvestMarket is reachable without ownership (it is).
• The MarketAddress vault has a permissionless setAdmin + admin transferToken (it does).
• Working capital to buy AIS and prime the pump — fully flash-loanable: the PoC borrows 3,000,000 USDT from a PancakeV3 pool and repays it in the same tx.

Attack walkthrough (with on-chain numbers from the trace)#

Pair token0 = USDT, token1 = AIS, so reserve0 = USDT, reserve1 = AIS. All figures are taken directly from the Sync/Transfer events and addMarketValue calls in output.txt.

Why the skim loop is free: pair.skim(to) transfers out realBalance − recordedReserve. The attacker sends 128,165.54 AIS to the pair (real balance becomes 3,271.32 + 128,165.54 = 131,436.87, seen at :137), then skim pays exactly 131,436.87 − 3,271.32 = 128,165.54 AIS back to the attacker. Net AIS = 0, but the two AIS transfers (in via Pairs[to], out via Pairs[from]) have already bumped PendingMint by 8% + 4% = 12% of 128,165.54 ≈ 15,380 AIS per cycle. Over 100 cycles plus the initial buy, PendingMint reaches the 1,543,728 AIS that harvestMarket then mints.

Profit accounting (USDT)#

The ~1.54M AIS sold for 3,062,186 USDT was minted from thin air; the 60,686.88 USDT profit is real USDT drained out of the pair's liquidity (and ultimately from AIS holders, whose supply was diluted by the unbacked mint).

Diagrams#

Sequence of the attack#

PendingMint inflation and value flow#

Pair reserve evolution#

Why each magic number#

• 3,000,000 USDT flash loan — sized to buy enough AIS (142,406) so that 90 % of it (128,165) can be used as the per-cycle skim amount. Bigger buy ⇒ bigger per-cycle accrual ⇒ bigger final mint.
• balance * 90 / 100 per skim leg — leaves a 10 % buffer so the Pairs[to] sell guard balanceOf(from) > value*111/100 never reverts (:982) and the attacker never strands AIS in the pair.
• 100 iterations — purely a knob: each cycle adds ~12 % of 128,165 ≈ 15,380 AIS to PendingMint; 100 cycles compound it to the ~1.54M AIS eventually minted.
• balanceOf(vault) * 90 / 100 transferred out — the attacker leaves 10 % in the vault, plausibly to avoid edge-case reverts; 90 % (1,389,357 AIS) is more than enough to drain the pool.

Remediation#

1. Restore access control on setSwapPairs. Re-add onlyOwner (or a managed allow-list). An attacker must never be able to declare arbitrary addresses — least of all themselves — as pairs.
2. Do not accrue mintable rewards on gross transfer volume. PendingMint must reflect real, non-reversible economic activity, not wash-trade round-trips. At minimum, exclude pair↔pair and self-directed transfers, and make accrual depend on net value, not gross amount.
3. Gate harvestMarket() and bound it. Restrict to a trusted keeper/role, cap the per-call and cumulative mint, and reconcile against an off-chain or oracle-verified reward figure.
4. Never override balanceOf to diverge from the real ERC20 ledger. The balanceOf − PendingBrun trick desynchronizes the token's view from AMM reserves and enables the skim round-trip; it is a classic source of pair-accounting exploits.
5. Fix the vault. setAdmin() must have access control; transferToken() must only move tokens the vault is entitled to, under a trusted role.
6. Treat the token + vault as one trust boundary. The vault blindly trusts AIS's addMarketValue accounting and exposes an open admin setter — either side alone breaks the system.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under a single forge build):

_shared/run_poc.sh 2023-11-AIS_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 33,916,687). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block. Public BSC RPCs that prune old state fail with header not found / missing trie node; if blastapi returns a transient history index only covers up to … pipeline-sync error, simply re-run.
• Result: [PASS] testExploit() with USDT profit: 60686.884783691370295991.

Expected tail:

Ran 1 test for test/AIS_exp.sol:AISExploit
[PASS] testExploit() (gas: 7954032)
Logs:
  USDT profit: 60686.884783691370295991

Suite result: ok. 1 passed; 0 failed; 0 skipped

References: Phalcon analysis — https://twitter.com/Phalcon_xyz/status/1729861048004391306 ; SlowMist Hacked — https://hacked.slowmist.io/ (AIS, BSC, ~$61K).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-11-AIS_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: AIS_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "AI SPACE (AIS) Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.