Patch the Planet: What AI-Found Bugs Mean for Disclosure and Defenders

On 21 October 2026, OpenAI published "Patch the Planet: global response coordination as agents uncover critical vulnerabilities". It describes how a coalition handled two critical PHP flaws and proposes a five-stage disclosure framework. It affects every team that runs open source. The practical answer: know your inventory, patch in hours, and keep humans approving changes.

Below: what OpenAI's post says, what AI-driven discovery means for coordinated disclosure, using PHP2Shell and PwnEscape as examples, and what defenders can do now. For the research side of those two bugs, read our earlier post on AI-found vulnerabilities in PHP2Shell and PwnEscape. This one is about the coordination and the response.

What OpenAI's post says

OpenAI's post describes a response it led over roughly two months to two critical vulnerabilities in PHP. According to the post, Calif found one of the flaws using GPT-5.6 Sol as part of the Patch the Planet initiative, and Wiz independently found and reported both. PHP's maintainers led the fix and the release. OpenAI says Wiz, Cloudflare and others contributed research, technical support and coordination before disclosure.

The post frames the timing this way: because frontier AI found the bugs before attackers did, maintainers and security providers had what OpenAI calls a "Defender's Window" to prepare fixes and protections ahead of public disclosure.

Who the post names

The post names a mix of companies, government bodies and open source groups. We list them as the post does, without ranking.

The five-stage framework

The core of the post is a proposed framework for responding to critical flaws in widely used software. In our own words:

Who joins each stage, the post says, depends on the organisation's protective role, its ability to act in time, and its ability to handle sensitive information. What they receive scales with that, from indicators of compromise up to working proof of concept exploits. Because even limited details can reveal a bug, each disclosure is weighed against the protection it enables.

When timelines change

The post does not set fixed embargo lengths. It says the timeline should be reassessed if there is active exploitation in the wild, a leak, a public patch that reveals the bug, or rising risk to users because remediation has stalled. For operators deciding how fast to act, it points to CISA's guidance on prioritisation and remediation, which is Binding Operational Directive 26-04.

What OpenAI is sharing

• A PHP version checker. OpenAI released php2shell-checker on GitHub as a Codex skill and a standalone Node script to help operators find potentially vulnerable PHP versions.
• A public website. patchtheplanet.org is described as bringing together public disclosures and guidance for operators: how to identify affected systems, find the right update, verify the fix, and apply interim mitigations, backup and recovery steps.
• Programs for maintainers and defenders. Maintainers can apply to Patch the Planet for hands-on support, and the post mentions Codex for OSS subscriptions for maintainers. It says OpenAI has committed $1 billion in subsidised Daybreak access through Daybreak for Frontline Defenders, aimed at organisations with limited security resources that protect essential services. That figure is subsidised access, not a cash grant.

What OpenAI says comes next

OpenAI says these PHP bugs are among several significant vulnerabilities it has already found and is working to fix, and that it expects similar findings to rise sharply in the coming months. It lists longer term goals: secure defaults in code, migrations to memory safe languages, formal verification of critical components, and stronger sandboxing for software that handles untrusted input.

The post asks for public feedback on four open questions:

1. Disclosure windows. How much time maintainers, operators and defenders need to prepare and deploy reliable fixes.
2. Emergency patching. When, if ever, governments or other operators should use a vulnerability to patch systems they own but have lost administrative control of.
3. Early notice. Who needs advance warning to take a useful protective step, including defenders who might be missed.
4. Secure by default packages. How to find and fix vulnerabilities in downstream packages while upstream fixes are pending, including backports for older versions.

Where Patch the Planet started

OpenAI announced Patch the Planet on 22 June 2026 as a Daybreak initiative with Trail of Bits to help maintainers find, validate and fix security issues. Its framing: "discovery alone does not protect users."

Calif's own PHP2Shell write-up says OpenAI invited Calif into Patch the Planet and that PHP was picked as a high impact target. Calif says it brought in Volker Dusch of the PHP Foundation.

Timeline

PHP2Shell and PwnEscape: two disclosures, two paths

The two bugs that defined this week both involved AI in the research. Only one was part of Patch the Planet.

PHP2Shell went through the coordinated path

PHP2Shell is Calif's name for CVE-2026-109618 and CVE-2026-109619, which PHP describes as unauthenticated remote code execution flaws. Calif's write-up credits Calif, OpenAI and Wiz with the discovery, with research and write-up by Ryan Austin.

On the AI side, the sources describe it a little differently. OpenAI's post says Calif found one flaw using GPT-5.6 Sol. Calif's write-up describes an LLM companion and an agent reviewing PHP source code, and says no special harness and no models unavailable to the public were used in the initial discovery; in our reading it does not name a specific model.

PHP's release notes show what stage 4 of the framework looks like in practice. PHP says Linux distributions and LTS vendors received the patches in advance, and minimal backports were provided for PHP 7.4, 8.0 and 8.1, which no longer get upstream releases. PHP also said one volunteer run RPM repository would not have updates on release day, so downstream readiness stays uneven even when upstream works.

The plan also met one of the conditions OpenAI lists for reassessing timelines. As we covered in governments take websites offline over PHP2Shell, a social media post leaked the coming disclosure on 20 October, and PHP published its advance notice that evening with a release slot the next day, reserving the right to ship earlier.

PwnEscape went through kernel maintainers directly

PwnEscape (CVE-2026-99999) is a Linux kernel flaw that lets a KVM guest affect its host, according to pwn.ai. pwn.ai credits PWNAI Research, led by Paulos Yibelo, working in Vercel's Sandbox challenge. It says the team used an experimental harness called Omega-Pwn with GPT-5.6 Sol as the main reasoning engine, reached the core primitive in about three days, and spent under $700 on API calls. It says humans led the research.

pwn.ai's post does not mention Patch the Planet. Disclosure ran through the kernel's own process: a private report to kernel security contacts and networking maintainers on 4 September, public netdev review in late September, and a mainline fix on 14 October. pwn.ai says it expects "exploits in weaker configurations to arrive in weeks."

Why the contrast matters

Both bugs were found with frontier models and fixed by maintainers through coordinated disclosure. One had a coalition, government contacts and staged notice; the other used the long standing kernel process. Either way, defenders end up with a public fix and a deadline they did not choose. For the technical detail of each, see our explainers on PHP2Shell and PwnEscape.

What AI-driven discovery means for coordinated disclosure

This section is our analysis, not OpenAI's.

More findings, same number of maintainers. OpenAI expects similar findings to rise sharply, and the June post already reports hundreds of issues across 19 projects. Validation and patching still fall on a small group of maintainers, which is why both posts stress human review before anything reaches them.

Staged notice is now explicit. Disclosures already worked in tiers: maintainers, then distributions, then everyone. The framework writes that down and adds governments and infrastructure providers. For most companies, the tier they are in is the last one, public guidance.

Patches are maps. OpenAI lists a revealing public patch as a reason to reassess the timeline. A source diff points straight at the bug. If models can read diffs quickly, the time between a public fix and a working exploit is likely to keep shrinking. That puts the pressure on the deploy side, not the disclosure side.

Leaks reset the clock. PHP2Shell showed how one post can collapse a schedule. Any process that involves more parties for longer carries more leak risk, which the framework weighs against the protection early notice buys.

Version checks have limits. OpenAI's own checker says distribution backports may not change the upstream version number, and that "UNKNOWN does not mean the target is patched!" A header based check is a first pass, not proof.

What it means for defenders

You cannot choose which stage you hear about a bug in. You can choose how fast you act once you do.

Use the BOD 26-04 questions as your triage

OpenAI points operators to CISA's BOD 26-04. The directive formally binds US federal civilian agencies, but its four questions work for any team deciding urgency:

Keep humans approving AI-made changes

Both OpenAI posts put human review at the centre of discovery. Apply the same rule to fixing: the assistant drafts the version bump and runs tests, a person approves each command, merge and deploy, and the assistant uses a short-lived, least-privilege identity.

What to do now

1. Check your PHP versions the way OpenAI's checker does, then confirm. The checker reads a site's X-Powered-By and Server headers, or runs php -v locally:

   git clone https://github.com/openai/php2shell-checker
   cd php2shell-checker
   node phpcheck.js "https://www.example.com" --json
   node phpcheck.js --local
   

   Treat UNKNOWN (exit code 3) as "investigate", not "safe". Many servers hide version headers.

2. Confirm on the host. Run php -v and php -i | grep "Server API". On Debian and Ubuntu, dpkg -l | grep -i php; on RHEL-family systems, rpm -qa | grep -i php. A distribution backport may carry a fix without a new upstream version, so compare against your vendor's advisory.

3. Check images, not only hosts. For each image, run docker run --rm --entrypoint php my-app:latest -v. With Safeguard, safeguard scan --image my-app:latest lists the packages in the image.

4. Upgrade and restart. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package, then restart workers, for example sudo systemctl restart php8.3-fpm. PHP says the listed workarounds reduce exposure but do not make an installation safe.

5. Check KVM hosts. Run uname -r and compare with your distribution's fixed kernel. Migrate guests, reboot or live patch, and run uname -r again.

6. Subscribe to the stage 5 channels. Watch patchtheplanet.org, PHP's news archive, your distribution's security list, and CISA's KEV catalog. Route them to an on call owner, not a shared inbox.

7. If you maintain an open source project, publish a private reporting channel and keep a release branch you can patch quickly.

What would have helped

The PHP2Shell response shows the upstream half working. The downstream half, inside each organisation, decides how long exposure lasts.

Practices any team can use

• A queryable runtime inventory. Every PHP version and server API, every container base image, every hypervisor kernel, and every vendor product that bundles its own runtime.
• An emergency patch path. Pre-approved change, named owners, and a way to build, test and ship a runtime upgrade the same day.
• Rebuild on demand. Images built from pinned bases that you can rebuild with a patched runtime without hand edits.
• Guardrails for your own agents. Per run credentials, limited egress, action logs, and a human approval step for production changes.

Where Safeguard fits

Safeguard helps with knowing your exposure and doing the fix work. It would not have prevented either bug, and it does not block exploit traffic.

• Exposure. SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image my-app:latest, safeguard scan --sbom sbom.json), with JSON results under ./output. Findings are matched against vulnerability databases, and the platform shows which projects contain a given component and version.
• Priority. Reachability analysis separates findings in code paths you use. Policies and gates are evaluated in the platform, so a build carrying a flagged version can be held.
• Fixing with a human approving. Autonomous remediation can open fix pull requests and is off by default. The Safeguard CLI's assistant can edit code and run commands with your approval; /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs it in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command. See our CLI overview.

Where it does not help: it does not patch or reboot host kernels outside the images and repositories you scan, so PwnEscape on a KVM host is a job for your distribution. It does not detect whether a PHP worker was already compromised; use host monitoring.

Zero-Day Discovery and Gold

Two Safeguard capabilities are about finding and fixing flaws in components earlier.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. PHP core and host kernels are outside those ecosystems, and Zero-Day Discovery played no part in finding PHP2Shell or PwnEscape.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit these tools support is the one that matters as AI raises the volume of findings: pull patched, signed components from a curated source, and be able to rebuild and redeploy quickly when a stage 5 advisory lands.

Common mistakes and troubleshooting

• Trusting a clean header check. Hidden headers give UNKNOWN. Reverse proxies may report their own version, not PHP's. Check the host.
• Treating a backport as unpatched, or the reverse. Distribution packages can carry fixes under older version strings. Read your vendor's advisory for the exact package release.
• Installing a kernel without rebooting. uname -r shows the running kernel, not the installed one.
• Waiting for a KEV listing. BOD 26-04 asks about KEV, but also about exposure, automation and control. A public, automatable RCE does not need to wait.
• Letting an AI assistant push to production unattended. Use approval modes and short-lived credentials, the same way the discovery side keeps humans in the loop.

FAQ

What is Patch the Planet?

It is an OpenAI initiative announced on 22 June 2026 with Trail of Bits, under OpenAI's Daybreak program, to help open source maintainers find, validate and fix vulnerabilities with AI-assisted research and human review. The 21 October post extends it to coordinating the wider response to critical flaws, starting with PHP.

Who found the PHP2Shell vulnerabilities?

Calif's write-up credits Calif, OpenAI and Wiz. OpenAI's post says Calif found one flaw using GPT-5.6 Sol and Wiz independently found and reported both. PHP's maintainers wrote and released the fixes.

Was PwnEscape part of Patch the Planet?

Not according to pwn.ai's write-up, which does not mention the initiative. pwn.ai says it found the bug in Vercel's Sandbox challenge with its own harness and GPT-5.6 Sol, and disclosed it privately to kernel maintainers.

Does the framework set a fixed embargo period?

No. OpenAI's post asks for feedback on how long disclosure windows should be, and says timelines should be reassessed on active exploitation, a leak, a revealing public patch or stalled remediation.

Can I rely on OpenAI's PHP checker to confirm I am patched?

Use it as a first pass. Its README says it reads version headers or php -v, that distribution backports may not change the version number, and that it does not verify a fix independently. Confirm against PHP's release or your vendor's advisory.

What is the most useful single step for defenders?

A runtime inventory you can query in minutes. Our guide to finding and patching every PHP runtime walks through building one.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none shows Patch the Planet or PHP2Shell.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with approval, and pushes nothing. For PHP2Shell, you would run the same kind of scan against your PHP image and ask the assistant to bump the base image tag to a fixed PHP release; it asks before each command.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here, you would pick the repo holding your Dockerfile or deployment config, ask for the PHP version change, and approve each edit, which is the human in the loop pattern both OpenAI posts apply to discovery.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session sending work to a computer running the CLI and approving a command with Allow once, Allow for turn or Deny. PHP's release was set for 14:00 UTC, which is late evening across much of Asia and Australia; this is how an on call engineer could approve a php -v check or a worker restart from a phone without granting open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For the wider month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• OpenAI: Patch the Planet, global response coordination as agents uncover critical vulnerabilities
• OpenAI: Patch the Planet, a Daybreak initiative to support open source maintainers
• OpenAI php2shell-checker on GitHub
• Patch the Planet website
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• PHP news archive 2026: advance notice and security release
• Calif: PHP2Shell
• pwn.ai: PwnEscape
• Hacker News search: Patch the Planet stories

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.