Reproduced Exploit
ParaSpace: uint8 asset index truncates past 255 assets, colliding slots
Chain
Other
Category
untagged
Date
Jan 1970
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 25724-h-08-nftfloororacles-asset-and-feeder-structures-can-be-corr. Standalone Foundry PoC and full write-up: 25724-h-08-nftfloororacles-asset-and-feeder-structures-can-be-corr_exp in the
evm-hack-registrymirror.
Vulnerability classes: vuln/locked-funds · vuln/reward-accounting · vuln/price
Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable function is reproduced verbatim (marked
@>) with faithful minimal doubles; local deploy, no fork.
Root cause#
assetFeederMap[_asset].index = uint8(assets.length - 1) (L176) truncates once more than 256 assets exist: asset #257 gets index uint8(256)==0, colliding with asset #1. On removal, uint8 assetIndex = assetFeederMap[_asset].index reads that collided 0, so delete assets[0] zeroes asset #1's slot while it stays registered — a corrupted oracle registry.
{
assetFeederMap[_asset].registered = true;
assets.push(_asset);
assetFeederMap[_asset].index = uint8(assets.length - 1); // @> truncates: asset #257 gets index uint8(256)==0, colliding with asset #1
emit AssetAdded(_asset);
}
Why it's exploitable here#
After 257 distinct assets are registered, uint8 index truncation makes asset #257's stored index (uint8(256)==0) collide with asset #1's index 0; calling removeAsset(asset#257) then executes delete assets[0], zeroing the EXISTING asset #1's array slot while asset #1 stays registered in assetFeederMap — an internally inconsistent, corrupted oracle registry (mispricing / loss of admin control / DoS).
Attack path#
Marked-line walkthrough (Playground)#
The EVM Playground pins each step to the exact executed source line in 0x8ea53755a6…:
- L45 — Setup: role revocation helper: Setup:
_roles[role][account] = falseis access-control plumbing used while wiring up the oracle's admin and feeder roles. - L129 — Guard: asset must not exist: Setup:
onlyWhenAssetNotExistedlimits registration to new assets, but checks the map — not the truncated array index — so it misses collisions. - L140 — Guard: feeder must not exist: Setup: registration also requires the feeder be new — routine wiring that runs for each of the 257 assets being added.
- L149 — Enter removeAsset:
removeAssetis the sink: it reads the asset's storedindexand runsdelete assets[index], where a collided index corrupts the registry. - L176 — uint8 cast truncates the index: Root cause: casting
assets.length - 1touint8wraps past 255, so asset #257 stores index 0, colliding with asset #1's slot. - L177 — Emit AssetAdded event: The asset logs as added while its map entry holds a truncated index that silently aliases an earlier asset's array slot.
- L204 — Same truncation for feeders: The identical
uint8(feeders.length - 1)cast corrupts the feeder registry the same way once more than 256 feeders exist.
PoC#
Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test + negative control):
cd 25724-h-08-nftfloororacles-asset-and-feeder-structures-can-be-corr_exp
forge test -vvv
The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: After 257 distinct assets are registered, uint8 index truncation makes asset #257's stored index (uint8(256)==0) collide with asset #1's index 0; calling removeAsset(asset#257) then executes delete assets[0], zeroing the EXISTING asset #1's array slot while asset #1 stays registered in assetFeederMap — an internally inconsistent, corrupted oracle registry (mispricing / loss of admin control / DoS).. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 25724-h-08-nftfloororacles-asset-and-feeder-structures-can-be-corr_exp (evm-hack-registry mirror).
- AuditVault finding: 25724-h-08-nftfloororacles-asset-and-feeder-structures-can-be-corr.
- Upstream DeFiHackLabs PoC directory: src/test.
Alerts & third-party analyses
- DeFiHackLabs incident explorer: search "ParaSpace: uint8 asset index truncates past 255 assets, colliding slots".
- 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.