OpenAI’s 45× Linux bounty scenario uses a target that differs from Google’s rules

OpenAI’s roughly 45-fold hypothetical Linux bounty return depends on exploits developed against a modified target, not the environment Google requires for payment. Superpower Daily’s five-document audit reproduces that calculation and two desktop reward scenarios. But matching the figures against program rules exposes a gap between assigning exploits a hypothetical price and establishing a payable reward.

The comparison follows OpenAI’s November 4 disclosure of an autonomous Linux vulnerability research pipeline. Its mid-October desktop campaign reportedly produced 948 local privilege escalation exploits—attacks that let an existing low-privilege user gain root, the system’s highest level of control. OpenAI applied historical competition prices to those results and estimated hypothetical rewards worth approximately 16 to 55 times its API expenditure. A separate campaign used an adapted version of Google’s kernelCTF environment.

Our audit asks which comparisons survive matching the target, eligibility rules and spending denominator. We reviewed five primary documents: OpenAI’s disclosure, Google’s kernelCTF rules, Pwn2Own Berlin’s rules, and TyphoonPWN’s reward schedule and FAQ. The evidence cutoff was November 5, 2026, at 03:31:42 UTC. This was a public-document comparison, not an experiment: we executed no exploits and did not independently validate OpenAI’s results. The finding is narrower than a verdict on AI security research: the arithmetic works, but payment eligibility remains conditional.

The missing condition in the 45× scenario

OpenAI reports 21 privilege escalation exploits from its adapted-kernelCTF campaign, which cost roughly $32,936 in API credits. Google’s listed reward is $71,337 per eligible exploit. Multiplying that reward by 21 produces $1,498,077; dividing by the reported expenditure gives approximately 45.48 times the API cost. OpenAI explicitly conditions its estimate on the vulnerabilities being accepted. That qualification is essential, not a minor footnote to the result.

The target comparison does not match. OpenAI used the latest Linux kernel without SLAB_VIRTUAL, a security hardening feature. Google’s official target is Linux 7.2-rc5 with SLAB_VIRTUAL enabled, alongside other hardening measures and a reduced attack surface. An exploit working in OpenAI’s environment therefore does not, by itself, demonstrate success on the reward-bearing target. Conversely, the mismatch does not prove that an exploit could never qualify or be adapted; it limits the conclusion the published campaign supports.

Even a target match would not settle payment. Google requires the underlying bug to trigger on the latest LTS 6.12 kernel, a separately maintained version. Exploits must succeed in at least 70% of 20 runs, with each run finishing within five minutes. Researchers must also win a competitive submission slot; only one submission per researcher is eligible in each slot. Novelty, duplicate-finding rules and mandatory publication create additional gates between a working attack and a completed award.

Desktop prices came from contests already held

The desktop scenarios face a different constraint: timing. Pwn2Own Berlin ran May 14–16, 2026; TyphoonPWN ran May 28. Both preceded OpenAI’s October campaign. OpenAI describes their awards as historical bounty amounts, which makes them usable as price benchmarks—not submission opportunities for that completed campaign. The distinction preserves the comparison’s informational value without implying those contests offered a route to cashing in the later results.

Pwn2Own’s $20,000 Linux award concerned fully patched Red Hat Enterprise Linux for Workstations 10.1, rather than any desktop Linux installation. Its rules allow one registration per target and award the listed prize to the first successful contestant, subject to any additional-winner option. Those restrictions prevent treating 948 findings as 948 standard full-price wins. Matching a broad threat model—starting as an ordinary user and gaining elevated control—is not enough to establish compatibility with that particular target or contest structure.

TyphoonPWN advertises up to $70,000 for Linux privilege escalation. That ceiling is not a flat payment for every vulnerability. The first three successful contestants receive 100%, 50% and 25% of the target prize; the category then closes unless organizers extend it. Its FAQ also requires fully patched specified distributions, regular-user exploitation, and vulnerabilities that are unknown, unpublished and not previously reported to the vendor. Those terms make multiplying every result by the maximum award a valuation exercise, not a rule-matched revenue calculation.

The spending denominator changes the answer

OpenAI reports $1,213,430 in desktop campaign API credits and 948 unique privilege escalation results. Dividing the first by the second gives $1,279.99 per unique result, rather than the published $1,279. That small discrepancy does not materially change the reward multiples. The more consequential distinction is between the whole campaign and the narrower cost of developing successful exploits.

The approximately $359 successful-exploit development average measures something different. OpenAI’s 1,169 exploit outputs became 948 results after removing duplicates based on the patches that fixed them. Unsuccessful attempts also consumed credits. Reproduced vulnerabilities are another count again: the desktop campaign reported 1,724. Choosing among these denominators changes what the spending figure describes. A successful-development average cannot stand in for the cost of the entire discovery, validation and exploitation campaign.

Nor can the reward scenarios simply be added together. Google excludes previously disclosed or mainline-patched bugs and generally disallows vulnerabilities reported elsewhere except to security@kernel.org. TyphoonPWN requires previously unreported vulnerabilities. A disclosure or submission that satisfies one route can therefore foreclose another. These are conditional alternatives, not automatically cumulative proceeds from the same set of flaws.

The next evidence needs to connect findings to awards

There is counterweight to an overly skeptical reading. OpenAI says its desktop machines ran a stock operating system, not a weakened target, and explicitly calls the desktop valuations hypothetical. Our document audit does not refute its reported exploit results. It also cannot establish comprehensive research costs, collected payouts or net profitability. No finding-level ledger connects every counted result to the required target, submission-time novelty, reliability and winning-slot eligibility. Intervening page changes between the cutoff and snapshot retrieval also cannot be excluded.

Evidence that would move the comparison forward

• Official-target results: whether the adapted-kernelCTF exploits work with SLAB_VIRTUAL enabled and meet Google’s reliability and LTS-trigger requirements.
• Finding-level eligibility: which vulnerabilities satisfy novelty, duplicate and submission-slot rules, rather than merely carrying an advertised reward price.
• Payment and fuller costs: accepted awards and expenses beyond API credits, needed to move from a hypothetical reward multiple to a defensible profitability calculation.