Vultisig — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Vultisig, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Vultisig reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Vultisig
- Access control findings disclosed against Vultisig
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Vultisig: Adversary can prevent the launch of any ILO pool with enough raised capital at any moment by providing single-sided liquidity
Vultisig's ILO mechanism can be permanently stalled by an attacker before any launch: a 1-wei flash swap drives the underlying Uniswap V3 pool price to its minimum, after which minting a narrow single-sided liquidity position with 1 wei of the raise token locks the deviation in place because the callback would need to pay SALE_TOKEN that nobody yet holds. Since iloManager.launch reverts (UV3P) whenever the pool price diverges from the recorded initialPoolPriceX96, even a fully-funded sale is blocked at the last moment. The cheap attack inflicts a direct protocol-wide denial of service and burns gas for the many users who funded the sale, while also damaging the token's reputation for any future offering.
Vultisig: Transfer of `ILOPool` NFT token to different account allows for users to bypass the pool's `maxCapPerUser` invariant
Vultisig's ILOPool contract enforces sale rules, including a maximum contribution cap per investor (maxCapPerUser), by checking the buyer's ERC721 NFT balance — specifically treating balanceOf(recipient)==0 as "first purchase." Because the check keys off token balance rather than a persistent per-account tracking flag, an investor can transfer their ILOPool NFT to a second address they control and then buy again, exceeding maxCapPerUser while still satisfying the balance-based gate. This lets a single actor accumulate more than the intended allocation while also reverting subsequent buys by honest investors (the pool hits its hard cap with "HC" error), distorting the fair-launch allocation. The finding includes a passing Foundry test demonstrating the bypass and suggests replacing the balance check with an explicit internal tracking mechanism that aggregates each investor's total raised amount across all positions.
Vultisig: Most users won't be able to claim their share of Uniswap fees
Vultisig's ILOPool claim() collects the maximum possible token amount from the shared Uniswap V3 position using type(uint128).max, which sweeps the aggregated fee balance owed to every in-flight user in the same pool instead of only the caller's share. The first user to claim therefore drains all accrued fees, sends a portion out as platform and performance fees, and leaves later claimants unable to collect since the contract no longer holds their tokens, causing their claim to revert on a SafeTransfer. Over time, unclaimed fees can accumulate to exceed what a locked-out user is owed, meaning they can also lose access to their principal vesting entirely. The finding includes a Foundry PoC using flash loans to generate fees, and a fix that computes and collects only the calling position's principal plus its own accrued fee-growth share.
Vultisig: Vultisig whitelisting can be bypassed by anyone
Vultisig's token-sale launch gates purchases behind a Whitelist contract, but its membership check conflates a per-user whitelist flag with `_allowedWhitelistIndex`, a maximum-index capacity limit. Because the limit must be configured before the sale can operate, the conflation collapses the sentinel once the owner sets any index value, and the check no longer enforces whitelisted status. Any non-whitelisted account can then pass `checkWhitelist` and buy tokens during the whitelist phase, and the 3 ETH per-account cap can be sidestepped by purchasing through many fresh accounts. This inflates demand and price at the expense of legitimate whitelisted participants.