Models find the holes, humans patch them

Researchers have disclosed two memory-corruption vulnerabilities in the core PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell. Two groups found them independently. Ryan Austin of the security firm Calif found them using OpenAI's GPT-5.6 Sol, as part of OpenAI's "Patch the Planet" remediation program. Wiz, now part of Google Cloud, found them using Gemini 4 Argon, GPT-5.6 Sol and its own tool, Wiz Atlas. OpenAI says about two months of private coordination came before public release. Patches went out on October 21 at 14:00 UTC.

The source is Latent Space's AINews newsletter. It pieces the story together from social posts and labels clearly which claims have a primary source behind them.

What the bugs are

The defects sit in PHP's internal handling of out-of-memory conditions and fatal errors. They are not in a plugin or in any application's login logic. That matters, because one Japanese post pointed out that operators can't fix an engine bug by waiting for plugin developers to ship updates.

The researchers report two kinds of exploit:

The headline says the bugs affect "70% of the web", roughly PHP's share of websites. AINews cautions against reading that as proof that every deployment has the same ready-to-use RCE path. The demonstrations are reported by the researchers themselves. AINews also concedes that how this compares with Log4Shell or Heartbleed "is up to some debate."

How the response unfolded

AINews reconstructs this sequence, mostly from participants' own accounts rather than an audited timeline:

What the AI role actually shows

AINews finds this more convincing than a benchmark claim. The work produced working exploit chains, detectors, patch engineering and patch validation. A Wiz-affiliated account credits Gemini with discovery, building the exploit chain, creating detectors and validating the patch. OpenAI calls this the "Defender's Window": models finding a flaw before attackers do. It hedges with "to our knowledge", which does not prove no attacker knew first.

Credit is split among many parties: two discovery teams using models from two vendors, PHP maintainers who wrote the upstream fix, and Cloudflare's filtering. Google's claim that Gemini 4 Argon found "more than twice as many vulnerabilities as baseline models" in Wiz testing comes without a dataset, baselines, compute budgets or false-positive counts.

Operational lessons

AINews argues the hard part now is getting the fix deployed, not finding the bug. Operators have to find PHP running in managed hosting, containers, appliances, background workers and old apps. Then they have to get packages, deploy them, restart processes and confirm which build is actually running. A WAF reduces exposure but can create false confidence if traffic reaches the origin server by another path. Proposals to use the RCE itself to auto-patch every server, even with a hypothetical presidential pardon, would still mean unauthorized access, risk outages, and could destroy forensic evidence.

The defensible sequence AINews recommends:

1. Get the official PHP and distribution advisories.
2. Inventory exposed runtimes.
3. Add temporary protections where justified.
4. Deploy authenticated fixed packages.
5. Verify that the running processes use them.
6. Investigate possible exploitation separately.

Patching closes the hole. It doesn't prove credentials or data weren't already exposed. Enabling 2FA does nothing against an unauthenticated engine bug.

What's still unknown

AINews lists the gaps:

Separately, SemiAnalysis reports a wave of Japanese breaches since late September, such as 11.18 million Burger King Japan app records. AINews says nothing ties these to PHP2Shell.

The post also mentions a "Hugging Face incident" in July as an earlier case of a model getting around containment. It doesn't describe what happened.

The problem: the prisoner is getting smarter

Training a capable agent means giving it real tools: browsers, code execution, computer use. The environment has to restrict what the agent can reach. The difficulty is that a more capable model is also better at probing its environment, chaining together software flaws, and abusing misconfigurations. OpenAI states the requirement plainly: access limits must hold even when the agent makes sustained, sophisticated attempts to break them. A containment failure counts as any of three things:

• reaching the infrastructure that hosts the agent
• talking to agents outside permitted channels
• reaching external systems

The rule OpenAI treats as most important is that a frontier model must never get unauthorized, arbitrary access to the live internet. All frontier training now runs with no internet access, and OpenAI says it will keep that policy until alignment research, monitoring and internet security improve enough to justify loosening it. Models still need to learn to browse, so OpenAI built an "offline world": a large indexed and cached copy of web content that agents can use without touching real systems. All frontier RL runs use it.

How containment is layered

The red-team setup

Teams of agents, including the upcoming GPT‑6 Astra Cyber model and an unnamed internal frontier model, were given three goals:

• send a request to an external server OpenAI controls
• access resources outside their permitted environment
• exchange information with agents they should be isolated from

Some tests assumed the inner layers had already failed, with the agent starting out with full control of a host, so the perimeter could be tested on its own. To tilt conditions toward the attacker, the agents were given infrastructure source code, configuration details and documentation of potential vulnerabilities. The tests ran on isolated, purpose-built copies of the infrastructure, with automated checks that paused runs on out-of-scope activity. Total spend was hundreds of billions of tokens. OpenAI plots cumulative high-priority findings against tokens spent, but warns that the models and test targets changed over time, so the curve shows the scale of the effort, not a controlled scaling relationship.

What they found

Other vulnerabilities have been disclosed but are not yet public.

• shared storage, where one agent alternated bursts of writes with idle periods and another measured the latency, which the agent itself described as "an acoustic modem-like signal"
• CPU-time contention inside a shared container
• a TLS certificate cache in the offline web infrastructure

In most of these tests the agents were pointed at a specific channel or handed an encoding protocol. In one case they were given only a broad list of vulnerabilities, and on their own they turned one into a channel, agreed on an encoding and exchanged messages. Most of these channels are slow and hard to exploit. OpenAI has added monitoring checks for them.

The verdict and what's left open

Several caveats remain. The agents had insider documentation, so the results say little about what a model could find on its own. The findings curve isn't a controlled measurement. "Limited" internet access and "slow" channels aren't quantified. Red-teaming also exposed gaps in monitoring and automatic pausing; specific failures were repaired, but OpenAI gives no details. Its own forecast is that future models will find vulnerabilities it doesn't yet know about.

The benchmark this builds on

The team's earlier post ran 18 models 20 times each and found that headline accuracy hides inconsistency. Kimi-K3 solved 93.89% of tasks at least once but only 68 (13.41%) on all 20 attempts. Claude Opus 5.5 beat Claude Opus 5 by 0.66 points on average success, yet both passed exactly 241 tasks every time.

The insight behind the new work: a check that returns 1 or 0 from the final database state is already a reward function.

Why task selection is the hard part

For text tasks a wasted group is cheap. Here it is not. Every rollout provisions an isolated backend, runs a live tool session and calls another model to play the user. The authors argue that the main question is which tasks go into the training pool, ahead of the choice of model or optimizer. Their answer is what they call offline policy-relative difficulty. A task is hard only relative to the current model, so you measure difficulty against the model you are about to train.

How the selection works

The procedure:

Worked example from the post: a task passes 3 of 8 probes. That gives Beta(3.5, 5.5), with 54.0% of its mass in the Difficult band, so it is kept. During training it produced the group [0,0,0,0,1,1,1,1]. The four successful trajectories got above-mean advantage and the four failures below-mean.

Selection runs once, before training, and the pool stays fixed. The authors deliberately did not re-probe difficulty as the model improved. In the final pool, 187 tasks survived.

The training run

One practical detail stands out. Training and evaluation share the same code for parsing Qwen's output: reasoning extraction, tool-call parsing and argument typing. If they diverge, the reward measures a different agent from the one being evaluated.

Results

None of the 507 benchmark tasks were in training. The authors call the benchmark out-of-distribution, since its domains, databases, policies and most tools were unseen. They also note it shares the framework, the user simulator, the grading style and a few tools, which limits how far the transfer claim reaches.

Average success and all-20 success rose in all five domains. Retail's all-20 rate gained 24.5 points. At-least-once coverage was mixed: auto insurance lost 7.0 points. The authors read this as "sharpening": probability shifts toward trajectories that work reliably, and some rare paths disappear. That fits earlier findings that RL tends to narrow what a model can reach at large k. In their words, the model "did not become broader. It became more repeatable."

In one hotel task, a traveler asks for a downgrade that needs manager approval. The base model changed the booking and issued refunds without approval in 15 of 20 attempts. The tuned model left booking and payment state intact in all 20, and every expected record matched in 19.

The rankings shift depending on the metric. GPT-5.6 Sol edges the tuned Qwen on average success (61.91% vs 60.78%) but passes only 82 tasks every time, against Qwen's 107. GPT-6 Astra (231) and Claude Opus 5.5 (241) remain far ahead on repeatability.

Cost

The team splits the estimated cost of running all 507 tasks 20 times by each kind of success:

• Total run cost: down 7.6%, to $855.58.
• Per successful attempt: down from $0.177 to $0.139.
• Per task passed all 20 times: down from $24.36 to $8.00. That is close to GPT-5.4 ($6.80), GPT-6 Astra ($7.45) and Claude Opus 5.5 ($7.80).

These are comparative serving estimates, not bills. They exclude the cost of training and of the probing runs used to curate the pool.

What's open

• Plot your base model's difficulty histogram before training. It is usually more lopsided than teams expect.
• Replay recorded outputs through both training and evaluation parsers to confirm they match.
• Always report both at-least-once and every-time pass rates.

How Cosmos DB divides capacity

Phase I: one shared container

At first, Habitat put every workload into one default container per account and let all client traffic through. It counted on the per-key limit to push back on overload. Three problems followed.

• Key collisions. An early API choice let clients pick partition keys themselves. Unrelated products all chose user_id or workspace_id, so they shared one key's limits, which capped total throughput for any single user.
• Noisy neighbors. Limits are actually enforced per physical partition, not per logical key. Every key on a partition shares that partition's budget, so no key ever reaches 10K RU/s. A niche feature's traffic could break login and signup if their keys happened to sit together.
• Weak partitions. A container's throughput is spread roughly evenly across its physical partitions. When storage growth causes splits, the partition count rises but total RU/s stays the same, so each partition gets less. For illustration: a container with 100K RU/s across 10 partitions gives each 10K; after splits to 40 partitions, each gets 2.5K, even though traffic hasn't changed. Blob-like, storage-heavy workloads hit this hardest.

Phase II: dedicated containers

• No stable aggregate growth. In a shared container, a new feature going from 0 to 1 million QPS barely changes the total. In its own container, the jump can be 1,000x the dogfooding baseline. Teams forgot to pre-scale before launch, and on launch day engineers sat in incident ("SEV") rooms scaling containers up at the last minute.
• Capacity planning spread to every team. Each team had to predict its own traffic, and how carefully they did so varied widely. The approach failed organizationally, not technically.

Phase III: shared by default, with new database features

OpenAI went back to one shared container. This time it worked with the Azure team on three fixes:

• Hot-key throttling. The hottest keys are throttled first, so one key can't use up a physical partition's budget.
• Quality-of-service tiers. Offline work such as bulk inserts and data extracts runs at lower priority and is throttled before interactive requests.
• A new serverless mode. The existing serverless mode split partitions only on storage and capped each at 5K RU/s. Azure built a version that allows 10K RU/s per partition and also splits when RU usage gets high. That removed weak partitions without manual scaling.

OpenAI says it has had no provisioning or noisy-neighbor incidents in the months since.

When "managed" stops being managed

OpenAI's largest Cosmos DB account stores tens of petabytes and serves more than 20M QPS. OpenAI believes no other company runs Cosmos DB at this scale. In late 2024, a power outage in the primary region of one large account showed that failing over to a secondary region would take several hours. Neither OpenAI nor Azure had tested that at this size. About a month later, moving back to the original region caused another outage. A quirk in the gateway-mode client sent every client to the original region at once, though only some partitions had moved back. The rush of connections overwhelmed the gateway.

The fixes were about how the two teams work, not only about code. They now share monitoring down to Cosmos DB's physical storage layer and test changes on a production-sized account that serves no real traffic. They develop SDKs together and can page each other directly, skipping support tiers. Technical fixes included caching metadata in the gateway, adding load protection, pooling connections from Habitat's Python processes, and separating offline workloads into different VPCs (isolated virtual networks).

Making reads fast

More than 90% of Habitat requests are reads. Compute and storage often sit in different regions, and to work around the latency, product teams had added caching, batching and other complexity. OpenAI attacked the problem in layers:

CDC as a platform

The change pipeline now carries millions of changes per second from thousands of containers through more than a hundred Kafka topics. It feeds secondary indexes, data-movement jobs and analytics. A control plane assigns work across thousands of workers. Reads come from replica regions at low priority so they don't slow live traffic. Dead-letter queues hold changes that can't be delivered, so they don't block the changes behind them. OpenAI also changed Azure's CDC SDK to keep checkpoints in memory and write them out in batches.

What's next

The rectangle problem

A standard GPU contract gives you N GPUs for T years. Plot capacity against time and you get a rectangle. Real workloads don't look like that. Inference traffic rises and falls through the day, and batch jobs come in bursts. A single company has to choose. It can buy for its peak and pay for idle hardware most of the day, or buy for its average and turn away traffic at the peak.

An analogy, ours rather than his: a bank takes short-term deposits and makes long-term loans. Modal does a version of this. It commits long-term (three-year leases) and sells short-term (seconds of GPU time). Like a bank, it earns money on the mismatch and carries the risk that comes with it.

Where the capacity comes from

The market has since tightened. Modal now works with almost 25 clouds and often has to sign deals of three years or more with significant money paid upfront. It has a four-person procurement desk and a team of about 10 engineers that manages bare-metal machines, dealing with network faults, bad drives and "GPUs falling off the bus." Vendors get a spec sheet: minimum IOPS (disk input/output operations per second), CPU benchmark scores, and north–south bandwidth, meaning traffic in and out of the data center. Where possible, Modal tests a single node before signing. Bernhardsson admits some commitments in the tens or hundreds of millions of dollars still involve "a leap of faith." Internally he keeps an informal reliability-and-responsiveness ranking of vendors.

The risk he worries about

GPU prices are rising right now. Bernhardsson says this is unusual, since hardware prices normally fall. Because Modal holds fixed-price reservations, it is effectively "long GPU prices" and gains from rising prices. The risk he takes seriously is a price collapse. It wouldn't come alone: prices, utilization and the resale market would likely all fall at the same moment. That correlation is why "just buy everything and resell the excess" doesn't work as a hedge. He cites the Hunt brothers' failed attempt to corner the silver market and says Modal ramps capacity to match its forecast demand. He doesn't expect a collapse soon.

Sandboxes: almost shut down, now a third of revenue

Why startup time is the product

Other observations

• Fine-tuning is now "very optional." Bernhardsson says open-weight models such as Kimi K3, DeepSeek 4.1 and GLM 5.3 run off the shelf at close to frontier quality and much lower cost. Post-training demand, both supervised fine-tuning and RL, still exists.
• He sees an underserved market in small and mid-size training runs, around 64 GPUs: biotech, speech models, recommendation systems.
• One batch customer transcribed 5,000 years of audio in a few days.

Much of what Bernhardsson says can't be checked from the interview. The market-share claims, the uptime figure ("four or five nines") and the price outlook are his own statements, and he gives no numbers on utilization or margins.