CVE-2026–4931: How Spearbit’s Cantina Denied a Critical Vulnerability Using Verifiably False…
quality 7/10 · good
0 net
CVE-2026–4931: How Spearbit's Cantina Denied a Critical Vulnerability Using Verifiably False… | by Donnyoregon - Freedium
Milestone: 20GB Reached
We’ve reached 20GB of stored data — thank you for helping us grow!
Patreon
Ko-fi
Liberapay
Close
< Go to the original
CVE-2026–4931: How Spearbit's Cantina Denied a Critical Vulnerability Using Verifiably False…
A forensic disclosure of an integer truncation vulnerability in Marginal V1, its stealth remediation, and the technical misrepresentations…
Donnyoregon
Follow
~6 min read
·
April 6, 2026 (Updated: April 6, 2026)
·
Free: Yes
A forensic disclosure of an integer truncation vulnerability in Marginal V1, its stealth remediation, and the technical misrepresentations used to deny payment.
By Corrin Clark — Independent Security Researcher GitHub: @donnyoregon |
Coordination Notice
This vulnerability was coordinated with CERT/CC (Carnegie Mellon University's federally funded vulnerability research center) under case VU #643748 and officially designated CVE-2026–4931. All on-chain evidence referenced in this article is publicly verifiable on Ethereum Mainnet. This disclosure is made in the public interest following the exhaustion of all private resolution channels.
The Short Version
On January 31, 2026, I reported a critical integer truncation vulnerability in Marginal V1 that allowed complete drainage of protocol liquidity via a permissionless flash loan attack. The protocol paused within 48 hours. The exact fix I recommended was deployed to Mainnet within 72 hours. The mediating bug bounty platform — Cantina, a product of Spearbit Labs Inc. — denied the bounty by claiming the proxy contract was a Gnosis Safe and the remediation transaction was an MEV swap. Both claims are false and verifiable by anyone with an Ethereum node. This article contains that verification.
Background: Who Is Cantina
Cantina is not a generic bug bounty platform. It is owned and operated by Spearbit Labs Inc., one of the highest-profile smart contract security firms in the industry. Spearbit charges premium rates precisely because of its claimed technical rigor. Its president and leadership were directly copied on the correspondence in which the false technical claims documented in this article were made.
This matters because the defense of "triage error" is not available to a firm whose core product is technical accuracy in smart contract analysis. What follows is not a dispute about interpretation. It is a dispute about bytecode facts — the kind Spearbit's own auditors are paid to get right.
The Vulnerability
The adjust() function in MarginalV1Pool (proxy: 0x3A6C55Ce74d940A9B5dDDE1E57eF6e70bC8757A7 ) performs a direct, unchecked cast of a calculated margin value into a uint128 container:
solidity position.margin = uint128(margin0);
In Solidity, explicit casts do not revert on overflow. When margin0 exceeds type(uint128).max , the upper bits are silently discarded via a bitwise AND operation. The deployed bytecode confirms this at program counter 0x069c : 0687 | PUSH20(0xffffffffffffffffffffffffffffffffffffffff)
069c | AND ← uint128 truncation, no overflow check
No GT opcode. No REVERT. The truncation is unconditional and silent.
By supplying a crafted input via a standard flash loan — available permissionlessly through Aave or Uniswap V3 on Mainnet — an attacker triggers the following accounting state:
MetricValueReal debt obligation$100,000,000 USDCProtocol recognized value57,005 weiPrecision loss99.999%
The attacker walks away with the flash loan collateral while the protocol records essentially zero debt. No privileged access required. No user interaction required. Executable in a single transaction.
The reproduction test runs against a Mainnet fork via vm.createSelectFork() . A Mainnet fork mirrors exact deployed bytecode and live contract state. If the vulnerability did not exist in the deployed contract, the test reverts. It does not revert.
bash forge test --match-test test_Raw_Bytecode_Data -vvv
The Remediation
The timeline is on-chain and immutable:
DateEventJan 31, 2026 13:56 UTCFinding #27 submitted with full PoC, bytecode trace, and recommended fixFeb 02, 2026Protocol emergency pause — on-chain activity haltsFeb 04, 2026 23:06:47 UTCPatched implementation deployed — Block 24,386,649Feb 10, 2026Cantina requests remediation evidenceFeb 17, 2026Cantina rejects finding using false technical claims
The proxy uses Storage Slot 6 to track its active implementation. That slot changed as follows:
Before (Vulnerable): 0xfb1bffc9d739b8d520daf37df666da4c687191ea
After (Patched): 0xd8be1b2571b7c43b77ff3ae87bc6f0a23fa224b8
Decompilation of the new implementation confirms the addition of OpenZeppelin's SafeCast library. The following error string is present in the patched bytecode and completely absent from the vulnerable version: ASCII: "SafeCast: value doesn't fit in 1"
HEX: 53616665436173743a2076616c756520646f65736e27742066697420696e2031
Verify it yourself:
bash cast code 0xd8be1b2571b7c43b77ff3ae87bc6f0a23fa224b8 --rpc-url $ETH_RPC_URL | grep -c "53616665436173743a"
The exact source change deployed:
diff + import {SafeCast} from "@openzeppelin/contracts/utils/math/SafeCast.sol";
contract MarginalV1Pool is IMarginalV1Pool, ERC20 {
+ using SafeCast for uint256;
- position.margin = uint128(margin0);
+ position.margin = margin0.toUint128();
- position.margin = uint128(margin1);
+ position.margin = margin1.toUint128();
}
The new implementation is 1,424 bytes smaller than the vulnerable version — consistent with a targeted recompile to introduce a single SafeCast import. The functional change is precisely what my report recommended.
The False Technical Claims
On February 17, 2026, Cantina Competitions Support issued a rejection, explicitly copying Spearbit president Mike Yarmak at [email protected] . The rejection stated:
"The transaction hash you referenced corresponds to an MEV swap transaction, not a remediation or patch deployment."
"The 'vulnerable' implementation address you referenced resolves to a GnosisSafeL2 address, not an active Marginal implementation contract."
"The 'patched' implementation address resolves to the MarginalV1 NFPM (Non-Fungible Position Manager) address, which is a different contract and not evidence of a patch to the reported pool logic."
Every one of these claims is independently disprovable in under sixty seconds. Here is the verification:
Claim: "The vulnerable implementation is a GnosisSafeL2"
bash cast code 0xfb1bffc9d739b8d520daf37df666da4c687191ea --rpc-url $ETH_RPC_URL
The returned bytecode is MarginalV1Pool logic. It contains Marginal-specific function selectors and the vulnerable uint128 cast site. It is not a GnosisSafeL2. GnosisSafeL2 has a completely different bytecode fingerprint and is trivially distinguishable.
Claim: "The patched implementation is an NFPM"
bash cast code 0xd8be1b2571b7c43b77ff3ae87bc6f0a23fa224b8 --rpc-url $ETH_RPC_URL
The returned bytecode contains the SafeCast error string documented above. A Uniswap NFPM does not contain SafeCast overflow strings for uint128 margin operations. It is not an NFPM.
Claim: "The proxy is not an active Marginal implementation contract"
bash cast call 0x3A6C55Ce74d940A9B5dDDE1E57eF6e70bC8757A7 "token0()(address)" --rpc-url $ETH_RPC_URL
cast call 0x3A6C55Ce74d940A9B5dDDE1E57eF6e70bC8757A7 "token1()(address)" --rpc-url $ETH_RPC_URL
The proxy returns token0 and token1 — the MOG/WETH pair. It responds to MarginalV1Pool interface calls. It is an active Marginal pool.
These are not edge cases. These are not ambiguous on-chain states. A junior Solidity developer with an Ethereum RPC can disprove all three claims in under a minute. They were made by a firm that charges enterprise rates for exactly this kind of analysis, in a response copied to company leadership, as the basis for denying a critical vulnerability bounty.
CERT/CC Disclosure
Following the rejection, forensic evidence was submitted to CERT/CC on February 17, 2026, under case VRF#26–02-NQPCX. Following independent technical review, CERT/CC confirmed the vulnerability and assigned CVE-2026–4931 . The advisory is available through the CERT/CC vulnerability database at https://kb.cert.org/vuls/id/643748 .
CERT/CC is a federally funded research center operated by Carnegie Mellon University's Software Engineering Institute. Their confirmation is independent of Cantina's triage process.
What This Means for the Ecosystem
Spearbit's market position rests on a single asset: technical credibility. Protocols pay premium rates for Spearbit audits because the firm's name is supposed to mean something. That same firm's bug bounty platform, when confronted with bytecode evidence of a critical vulnerability and a stealth patch, responded by misidentifying a MarginalV1Pool as a GnosisSafe and an NFT position manager.
This is not a process failure. A process failure is a missed finding, a slow response, a miscommunication. This is a verifiably false technical claim made in writing, copied to company leadership, used to deny a $25,000 bounty for a Critical finding that the protocol had already patched.
Every protocol that has paid for a Spearbit audit should know that the same organization operating Cantina responded to forensic bytecode evidence with claims that any Ethereum node disproves in sixty seconds.
Every independent security researcher considering submitting to a Cantina program should know that demonstrating a fix was deployed is not sufficient for validation if Cantina's triagers describe the patched contract as a different contract entirely.
The blockchain is public. The bytecode is immutable. The storage slots are readable. The emails are documented. The CVE is assigned.
The record stands.
Verification Checklist
Everything in this article is independently verifiable:
Proxy contract: 0x3A6C55Ce74d940A9B5dDDE1E57eF6e70bC8757A7
Vulnerable implementation: 0xfb1bffc9d739b8d520daf37df666da4c687191ea
Patched implementation: 0xd8be1b2571b7c43b77ff3ae87bc6f0a23fa224b8
SafeCast hex: 53616665436173743a2076616c756520646f65736e27742066697420696e2031
Remediation block: 24,386,649 (Feb 04, 2026 23:06:47 UTC)
CERT/CC case: VU #643748 / CVE-2026–4931
Cantina rejection email: February 17, 2026, 1:23 AM, cc: [email protected]
For security inquiries or independent verification assistance, contact @donnyoregon on GitHub.
#cybersecurity #smart-contracts #bug-bounty #web3 #ethereum
Reporting a Problem
Sometimes we have problems displaying some Medium posts.
If you have a problem that some images aren't loading - try using VPN. Probably you have problem with
access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).