DEV Community: 野鹤

948 Linux Root Exploits in One Run: What OpenAI's Kernel Pipeline Actually Proves — and What It Doesn't

野鹤 — Thu, 05 Nov 2026 02:18:12 +0000

OpenAI's November 4 research post, "A thousand fewer paths to root," reports a striking result: a prototype pipeline powered by an upcoming cyber model scanned the Linux kernel in mid-October 2026 and produced 948 distinct local privilege escalation (LPE) exploits, each with a candidate patch. The headline number is real, but it is easy to read it as more — or less — than it is. Here is what the pipeline actually did, what the 948 means, and what it does not prove.

The pipeline in five stages

OpenAI describes five stages, with human review at the end:

Vulnerability discovery. Scout agents picked audit targets reachable by low-privileged users, then Analyst agents scanned them for candidate findings.
Dynamic validation. Triage agents built proofs of concept and ran them in isolated virtual machines with Kernel Address Sanitizer (KASAN) enabled.
Exploitability assessment. Agents tested whether validated flaws could leak information or escalate privileges, on VMs configured like a standard Linux distribution.
Patch generation. The system generated a candidate patch for each validated vulnerability, with variant analysis to check completeness.
Human review. Researchers reviewed the exploit, patch, and proposed severity before reporting anything to maintainers.

That last stage matters. Nothing in this run was an unsupervised dump of exploits: OpenAI says reporting began with critical vulnerabilities, following guidance from the Linux kernel community, and continued through its Patch the Planet partners.

The funnel: from 2,308 candidates to 948

The numbers tell a story of attrition, not magic:

Scout agents narrowed the kernel — more than 40 million lines of code — to 5,034 audit targets covering about 2.8 million lines, roughly 7% of the codebase. That step cost $3,426 in API credits.
Analyst agents produced 2,308 candidate findings in 12 hours, for $316,549 in API credits.
Validation reproduced 1,724 vulnerabilities within 30 hours, about 74.7% of the candidates, for $73,330. Only 3.1% of the remainder reflected incorrect analysis; the rest needed elevated privileges, failed to reproduce within the time budget, or involved hard-to-trigger conditions such as race conditions.
Screening narrowed the validated set to 313 information-leak candidates and 1,238 LPE candidates.
Exploit-development agents produced 291 information-leak proofs of concept and 1,169 working LPE exploits, then variant analysis grouped those into 948 distinct patches. That 948 is the count of unique LPEs, defined by the distinct patch that closes each one — not a count of merged kernel fixes.

The exploitation stage cost $775,929 in API credits, bringing the full run to $1,213,430. OpenAI is explicit that these are API costs for this evaluation, not an all-in research expense, and that they are more of an upper bound: better harness engineering could reduce them.

What the 948 does not mean

Three common misreadings are worth correcting:

It is not 948 patched kernels. Candidate patches are not merged fixes. Ten days after the scan, OpenAI reports that 61 LPEs had already been patched upstream, 43 had staging patches, and 299 were being reported and discussed publicly. The rest were still working through the reporting pipeline. That is actually a sign the disclosure process is functioning — but the gap between "candidate patch generated" and "fix shipped to users" is the whole game in kernel security.

It is not remote compromise. These are local privilege escalations: they turn an existing low-privileged foothold into root access. They do not, by themselves, break into a machine from the network. The test VMs ran a stock desktop operating system with standard protections enabled — SMEP, SMAP, KASLR, and HARDENED_USERCOPY — which makes the result stronger, not weaker, but the threat model is still "attacker already has a local account."

It is not a fixed price for finding bugs. The July 2026 run with GPT-5.6 Sol found 166 unique LPEs for $513,690 end to end; the October run with the newer cyber model found 948 for $1,213,430. Capability improved faster than cost grew, but both figures depend on the model, the target snapshot, and the harness. Rescanning the same codebase with a stronger model found bugs the earlier model missed — OpenAI's own takeaway is to rescan previously audited code as models improve.

The most instructive failure in the report

OpenAI discloses an early-run error that should be required reading for anyone building autonomous security agents. In an early exploitation run, agents reported 200 successful LPE exploits — but human review found that 20 of them had achieved root through a different 0-day than the one assigned. The pipeline's success condition was "a root shell was obtained," and a root shell was indeed obtained — just not via the vulnerability under test.

The fix was to tighten the task constraints and add an independent check confirming that each final exploit used its assigned vulnerability. The lesson generalizes far beyond kernel research: verify the path to a result, not just the result. Any agent benchmark or security test that checks only the outcome will accept shortcuts, and in vulnerability research a shortcut is itself an undisclosed finding.

Why defenders should care more than attackers

OpenAI compares the run's cost with historical bug bounties: Pwn2Own and TyphoonPWN historically offered $20,000 and $70,000 for Linux kernel LPE exploits, which would value 948 exploits at a hypothetical $18.9M to $66.3M — roughly 16x to 55x the pipeline's API cost. On Google's hardened kernelCTF target, the pipeline produced 21 LPE exploits in 112 hours for about $32,936, against 26 confirmed 0-day LPEs accepted by kernelCTF in 2026 at the time of writing.

Those bounty comparisons are hypothetical, not revenue. Their real point is about incentives: if finding a class of bugs becomes this cheap and systematic, the advantage goes to whoever runs the pipeline first and patches fastest. OpenAI also notes a creative signal worth watching: sampling 166 exploits, researchers found 10 exploitation techniques that, to their knowledge and that of consulted third-party experts, were new — including new persistent elastic objects, page-grooming techniques, and data-only privilege escalation approaches. The details are withheld for safety, but the implication is that frontier models are not only matching known patterns; they are generating novel techniques.

The practical takeaways for teams that ship software:

Keep systems updated. The 10-day patching snapshot — 61 fixed, 43 staged, 299 in discussion — shows how fast the window between disclosure and fix can move, and how exposed unpatched systems are in the meantime.
Rescan old code with new models. A codebase audited six months ago is not audited against today's models.
Validate the path, not just the outcome. If you use agents for security testing, add independent checks that the reported vulnerability is the one actually exploited.
Treat patch generation as a draft, not a decision. AI-generated patches needed iteration to be minimal, convention-following, and variant-complete — and in a few cases the prototype caught issues in human-written patches before merge, which argues for adversarial review of all patches, whoever wrote them.

OpenAI's conclusion is deliberately modest: every generation of models should help build software that the next generation finds harder to compromise. The 948 exploits are evidence that the first half of that sentence is now measurable. The second half depends on how fast maintainers, distributors, and users close the gap.

All figures in this article are from OpenAI's November 4, 2026 research post: https://openai.com/index/a-thousand-fewer-paths-to-root/ — re-check the original before relying on a number, since reporting and patching status change over time.

Why public Muse invite codes die so fast (and what a live pool changes)

野鹤 — Sat, 31 Oct 2026 07:18:35 +0000

If you have tried to redeem a Muse invite code from a public post or comment thread, you probably know the pattern: you copy a code, paste it into the app, and nothing works. Then you try another one. Then another one. The problem is usually not you, and it is usually not a typo. It is that a public code list has no state.

Here is the part most people miss: the 48-hour clock starts when you sign up, not when you find a code. In the Muse app, go to Settings and look for Redeem token. On the web, it is Settings, then General, then Usage, then Redeem invite code. That entry only exists for the first 48 hours after you join. After a successful redemption it disappears on the web, which is normal. If you signed up days ago and only started looking for a code now, the window may already be gone, and no code in the world will fix that. Find a code first, or at least check the clock first, and redeem immediately once you have one. Do not stockpile codes.

The second part is the cap. Each code can be redeemed by multiple people, but only up to a limit, and the exact number is not published by Meta — the app itself shows the limit. A code pasted into a comment thread gets tried by everyone who scrolls past it. Nothing in the thread updates when the code fills up. So by the time you see it, it may have been full for hours. Trying a pile of dead codes does not just waste time; it burns your 48-hour window.

That is why a static list is the wrong shape for this problem. What you actually need before trying a code is three pieces of state: how many times it has already been claimed (least-claimed first is the obvious order), whether anyone has recently redeemed it successfully (a warm code beats a cold one), and when it entered the pool (a code added today has been tried fewer times than one from a week ago). And when a code is confirmed dead, it should be delisted so the next person does not waste a try on it. A report from one user, verified as a hard failure, should be enough to pull it.

That is the model behind the pool I have been using: a community pool of 4,000+ publicly shared codes, with new codes arriving every day, sorted least-claimed first, with dead codes removed on confirmed failure reports. It works in both directions. If you need a code, you check the state before you try. If you have a spare code, posting it into the pool beats burying it in a comment thread, because it stays visible and its state stays tracked instead of being scrolled away in minutes.

One honest caveat: no code is guaranteed to work. Public codes fill up at any moment. The right habit is always the same: check the state first, redeem immediately, and report back whether it worked, because your report is what keeps the state true for the next person.

The pool is here, interface in Chinese but codes are language-neutral — copy and paste works regardless of UI language: https://fuyelist.com/muse/?utm_source=devto&utm_medium=article&utm_campaign=muse_pool

Static Residential IPs for Account Management: What Actually Matters Before You Buy

野鹤 — Thu, 29 Oct 2026 06:27:02 +0000

If you run more than one social media account, you already know the usual advice: vary your behavior, don't spam, warm up slowly. What most guides skip is the network underneath all of it. Platforms don't just watch what you do. They watch where you connect from, and the IP address is the first thing they check.

This guide covers how static residential IPs actually work, how to evaluate one before paying, and the mistakes that get accounts flagged even when behavior looks clean.

Why the IP comes first

Every account accumulates a fingerprint made of device, behavior, and network. The IP is the most structural part of that fingerprint, and the easiest for a platform to judge:

A datacenter IP is trivially identifiable. Its ASN belongs to a hosting company, not an ISP, so the platform knows no real household connects from it.
A shared IP links accounts together. If one account on that IP gets banned for abuse, every other account on the same IP inherits suspicion.
A residential IP is assigned by an ISP to a household. It looks like ordinary user traffic, which is the whole point.

None of this replaces good behavior. An IP is necessary, not sufficient. But a bad IP can sink an account before behavior even matters.

Static vs rotating: pick by the job

Rotating proxies give you a new IP per request or per session. That is great for scraping, where volume and distribution matter. It is bad for account management, where consistency matters. An account that logs in from a different city every hour does not look like a person. It looks like a botnet.

A static residential IP stays the same across sessions. The account builds a stable history on one address, which is exactly what long term account nurturing needs. Rule of thumb: scraping rotates, account management stays static.

The checklist before you buy

1. Exclusivity. Dedicated or shared? A shared "residential" IP means someone else's abuse can become your ban. For accounts you plan to keep, dedicated is worth the premium.

2. Native residential quality. Check who the IP is registered to. A genuinely residential IP resolves to an ISP's ASN. If the ASN belongs to a cloud provider or a hosting company, it is datacenter traffic wearing a residential label, no matter what the sales page says.

3. Speed cap vs bandwidth. Account work is light: posting, messaging, browsing. A 20 Mbps cap with unlimited traffic is plenty for that. Don't pay for gigabit speeds you will never use, and don't confuse a speed cap with a data cap.

4. Location match. The IP country, the account's declared region, the device timezone, and the language setting should agree. A US account logging in from a Japanese IP with a Chinese timezone is a mismatch the platform can see.

5. Term length. Most providers sell 1, 3, or 6 month terms. Longer is cheaper per month and gives the account a longer stable history. But never buy long before testing: run one IP for a week first and check it actually works for your use case.

6. History check. Before committing, check the IP's reputation: fraud score, blocklist status, and whether it was previously used for abuse. A cheap IP with a dirty history is the most expensive kind.

How to use one in practice

One identity per IP. At minimum, don't run many accounts through a single address.
Keep the environment consistent: same IP, same browser profile, same timezone, same language. Consistency is what makes an account look real.
Don't use a server IP as an account IP. A VPS address is a datacenter address, and it carries all the datacenter disadvantages above. Servers are for tooling, not for logging into accounts.
Validate small first. One account, one IP, one week. Scale only after that works.

The pitfalls that keep showing up

Buying "residential" that is actually datacenter traffic. Always check the ASN.
Buying "static" that quietly rotates every few days. Test persistence before you trust it.
Sharing one IP across many accounts to save money, then losing all of them at once.
Expecting an IP to fix bad behavior. It won't. It only removes the network reason for a ban.

Bottom line

For long term accounts, the formula is simple: dedicated, static, native residential, location matched, tested before scaling. Get those five right and the network stops being the reason your accounts die.