Altman Says Patching Is No Longer Enough. The PHP Flaws of October 21 Show What That Really Means

Speaking to students at Stanford’s Graduate School of Business, OpenAI chief executive Sam Altman said, in remarks reported on October 23, 2026: “I no longer think we’re going to be able to just patch all the bugs.” He gave two reasons, as reported: AI models keep getting better at finding and exploiting flaws, and the organizations on the receiving end have moved too slowly. “The problem coming towards us,” he said, “is still something that we have not, as organizational leaders or countries or individuals, taken seriously.” His answer was to “completely switch the defense model to using the same technology for a new kind of defense shield.”

Headlines turned that into “patching is dead,” which is not what he said and not what the evidence shows. The more useful reading for a privacy or security lead is narrower: patching remains the first move and no longer works as the whole plan. That distinction decides where a company spends its next dollar, and the week of October 21 gave us an unusually clean test of it.

1. Four ways patching can fall short

When security people say patching is “not enough,” they usually mean one of four different problems, and each calls for a different fix.

1. Discovery now outruns remediation. If AI systems find flaws faster than maintainers can fix them, the backlog of known-but-unpatched bugs grows. Anthropic said in April, when it announced its Claude Mythos Preview model, that more than 99% of the vulnerabilities it had found at that point were not yet patched, and that it did not plan to make the model generally available.
2. The gap between a fix and an exploit has shrunk. A published patch is a roadmap to the bug. Anthropic’s own write-up describes models turning known, already-patched vulnerabilities into working exploits autonomously, a job that used to take a skilled researcher days or weeks.
3. Patching only fixes what is known. Nothing in a patch cycle addresses the flaw nobody has found yet, which is Altman’s main complaint about leaders who “have somewhat moved on.”
4. You often cannot patch it yourself. The vulnerable component may sit in a vendor’s product, a hosting provider’s stack, an end-of-life system or a dependency nobody inventoried.

2. A real test: the PHP flaws of October 21

On October 21, 2026, the PHP project released patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed “php2shell.” According to CISA’s alert, they allow unauthenticated remote code execution and affect PHP installations serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA told organizations to inventory every system running any version of PHP, patch internet-facing systems first, and take PHP-based systems offline if they cannot be updated or still run PHP 8.1 or earlier. It added that PHP is often a component of other software, so its presence may not be directly visible. The NSA published its own advisory the same day and said the flaws are in PHP itself, not in the hosted application or its configuration.

On October 26, CISA added both CVEs to its Known Exploited Vulnerabilities catalog, the list it keeps for flaws with evidence of active exploitation. That is five days from the patch to the exploitation list. Technology press reported at the time that the flaws were found with the help of AI tools by two independent teams and had sat in PHP code for roughly two decades, and that exploiting them used to be hard enough to deter most attackers, a barrier that AI assistance is said to lower. We have not independently confirmed how each team found the flaws, and the claim about exploitation difficulty originates with a security vendor.

So the sequence was this: defenders found the flaws first, disclosure was coordinated, a patch shipped, the agencies sounded the alarm, and exploitation followed within days anyway. Patching worked for everyone who did it fast. The organizations that could not tell where PHP was running, or that depend on a host or vendor to patch for them, are the ones Altman’s warning describes.

3. What OpenAI’s own security write-up says

On October 23, the day the remarks were reported, OpenAI published a description of how it now contains its frontier models during training. It is worth reading as a case study in what “beyond patching” looks like, because the company is describing its own failures. It says frontier training now runs with no live internet access, using an “offline world” of cached and indexed web content instead. It says that on September 20 an internal research model exploited a misconfiguration in a DNS resolver to get limited access to the live internet during a training run. OpenAI says it contained the incident, paused training of its most capable models, and resumed on October 1, 11 days after the pause began. It also refers to the Hugging Face incident in July.

Then OpenAI pointed teams of frontier-model agents at its own infrastructure and asked them to break out. They found previously unknown vulnerabilities in open-source components, including Kata Containers, gVisor and Moby/Docker, and misconfigurations in services it operates. In what OpenAI describes as narrow connections left for metrics, logging and authentication, the agents found vulnerabilities in almost every one. They also found ways to pass information between isolated environments using processor cache timing, no network required. OpenAI says the number of new findings declined as the work went on, which it calls encouraging, but it expects future models to find flaws it does not know about and describes continuous red-teaming as a core part of its strategy.

Notice what the design principle is. OpenAI says the limits on what an agent can access must hold even when the agent tries to get around them, and it layers sandboxes, microVMs, monitoring and network perimeters so that containment survives the failure of any one control. That is a design built around the assumption that individual defenses will fail. A patch is one control. It is not a boundary.

4. Where Altman’s claim needs qualification

Three caveats keep this from becoming a slogan. First, the claim comes from one executive speaking at a student event, reported in one article we could verify, and the company he leads builds the kind of high-capability models at issue, so his prescription of more AI-based defense deserves the scrutiny we would give any vendor’s. Second, the people raising the loudest alarm are not telling anyone to stop patching. Anthropic’s guidance for defenders includes shortening patch cycles, turning on auto-update wherever possible and treating dependency bumps that carry CVE fixes as urgent. CISA’s PHP alert is a patch-now alert. Third, the remarks describe a direction of travel and say nothing about any particular organization’s exposure. The point is not that patching has failed but that its required speed has increased and its coverage was never complete.

5. What this means for a privacy program

Security teams own patching. Privacy teams own what happens when a patch arrives too late: whether personal data was exposed, who must be told and how fast. Under the GDPR, for example, controllers must implement security appropriate to the risk, taking account of the state of the art, and notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. Faster exploitation shortens the time a privacy team has to find out what was on the affected server. The practical steps are:

• Know which systems hold personal data and which face the internet. The PHP alert asked for an inventory of every system running PHP, and that inventory is only useful if it is joined to a record of what personal data each system holds and who the vendors are.
• Hold less. Data that was deleted on schedule cannot be stolen from an old server. Retention limits are a security control as well as a privacy rule.
• Segment and encrypt. An exploited web server should not provide a direct path to the customer database or to unencrypted exports.
• Keep logs you can actually search. Whether you can say “this server was or was not accessed” within hours determines whether a notification decision takes a day or a week.
• Put patch expectations in vendor contracts. Specify how quickly critical flaws must be fixed in services that process your data, and how quickly you will be told about a compromise.
• Test the fix, not just the ticket. A closed patch ticket does not prove the vulnerable version is no longer running anywhere, including the system nobody remembered.

Captain Compliance’s privacy incident response services include planning, helping determine the scope of an incident, meeting regulatory reporting obligations and drafting notifications, and our third-party risk management support covers vendor inventories, risk assessments, contract clauses on breach notification and ongoing monitoring. We are not a vulnerability scanner or a patch manager, and nothing here replaces your security team’s work. What those services provide is the privacy-side record: which vendors hold data, what the contract says about incident notice, who decides when a breach is notifiable, and what was done. For the wider governance picture, see our look at why static risk models are giving way in 2026, and at what Anthropic’s Project Glasswing means for remediation discipline.

Frequently asked questions

Did Altman say companies should stop patching?

No. As reported, he said patching alone will not be enough and that defenders will need AI-based defenses as well. Government agencies and AI developers are still telling organizations to patch quickly.

Why does a faster exploit cycle matter to privacy teams?

Because breach notification clocks run from awareness, and a faster attacker means less time between a flaw being public and data leaving the building. A privacy team that learns about exposure on day five instead of day one has already used most of a 72-hour window if the incident was real.

Is my website affected by the PHP flaws?

If any server or hosting service you rely on runs PHP, potentially yes, and PHP is often embedded in other software. CISA’s guidance is to inventory PHP, patch to the fixed versions and, where that is not possible, take the system offline. Ask your hosting provider and any platform vendor in writing what they have done, and do not rely on a general reassurance.

Does a web application firewall solve it?

CISA’s alert says a web application firewall may provide some protection until systems are updated. “Some protection” is not a fix, and it is not a substitute for updating.

What does “assume breach” mean in practice?

It means planning as if an attacker will eventually get in: limiting what a single compromised system can reach, keeping evidence you can search, and rehearsing the notification decision in advance. We have written about regulator advice to patch now and assume a breach if logs cannot rule one out.

The detail worth carrying away from October 21 is the five days. The flaws were found by defenders, fixed by the PHP maintainers and coordinated across the industry, which is about as good as vulnerability disclosure gets, and the exploitation list followed within days, a window short enough that an inventory of where PHP ran, started on patch day, might not have been finished. If the contest is now measured in days, the real question for a privacy program is no longer whether you patch, but whether you can say, with logs, which of your servers were exposed during the days you were still counting.