Can Your Website Be Secure If PHP Underneath It Isn't?

Imagine that your website is fully updated. The login works correctly, inputs are validated, and you haven't installed a suspicious plugin.

Then someone tells you an attacker might still run code on your server without logging in.

My first question would be obvious: if the application isn't the problem, where is the attack happening?

With PHP2Shell, the answer sits underneath the application itself.

On October 21, 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. That means running an attacker's code with the permissions of the PHP web worker. PHP's official announcement identifies web-serving installations across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as in scope.

The part that caught my attention was how familiar this software is. We worry about security mistakes in newly generated code. But what happens when AI helps researchers turn a weakness in infrastructure we've trusted for years into a practical exploit?

Wait, how can running out of memory become an attack?#

Normally, reaching a memory limit should stop a request. It should not leave the engine confused about which objects exist or who owns them.

The first PHP advisory describes a failure in that boundary. PHP used longjmp() to abruptly escape an out-of-memory condition. If that escape happened while internal data was only partly initialized, shutdown code could later treat invalid memory as usable state.

Think of a workshop where someone presses the emergency stop while a machine is half assembled. The power stops, but a checklist still says the machine is ready. The next person follows the checklist and starts touching components that were never safely installed.

The second advisory concerns stale global state: memory can be freed while an internal reference survives. A later request may encounter that reference after the memory has been reused. This is called a use-after-free.

Neither explanation means every failed request gives someone a shell. Exploitation depends on reachable error paths, worker behavior and memory layout. The serious finding is that researchers established ways to turn those conditions into code execution or memory disclosure.

But shouldn't the login or application validation stop it?#

Only if the request reaches that code first.

PHP's OOM advisory describes a demonstrated Apache mod_php path that can fail during request startup, before application code runs. An application-level authentication check cannot protect a stage the request reaches earlier.

PHP-FPM behaves differently during startup, but it is not a blanket escape: the separate stale-state advisory confirms session-lifecycle code execution against FPM as well as mod_php.

That distinction matters. “PHP is affected” does not mean one identical exploit works against every hosting setup. It means the runtime needs fixing, with the exact exposure assessed for the deployment.

So what did OpenAI actually do?#

This was coordinated security research. According to OpenAI's account, Calif identified a critical flaw using GPT-5.6 Sol through Patch the Planet. Wiz independently discovered and reported both vulnerabilities. PHP maintainers led the fixes and release.

Wiz's researchers describe using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol across discovery, exploit development and validation.

The important change is the cost of investigation. A memory bug might require repeated experiments across versions and configurations before its practical impact becomes clear. Models connected to testing and debugging tools can help researchers work through that search.

That is my engineering interpretation of the reports, rather than a claim that a chatbot independently replaced the security teams.

Was this really a completely new bug?#

The history is more uncomfortable than that.

The PHP Foundation's account says early signs of the OOM problem were found in 2024, while work related to a Quarkslab audit was underway. A concrete remote-code-execution route was not established then.

Proposed fixes involved compatibility, performance and extension-ecosystem tradeoffs. Work stalled amid limited resources and a difficult decision process. The Foundation calls the delay a structural failure.

On August 11, 2026, Calif reported an unconditional RCE with that root cause. Additional reports helped establish the impact, and the fix became a top priority.

So AI did not create this old weakness. It helped make the consequences demonstrable. Long-lived software can accumulate risks that remain difficult to characterize, let alone repair.

Which systems and data were most affected?#

There is no trustworthy public ranking of victims by financial damage. The useful picture separates demonstrated exposure, operational disruption and potential consequences.

Sources: Wiz's original demonstrations, Wikimedia's service notice, and Palo Alto Networks' advisory, checked October 23.

The boundaries matter too. Wikimedia's notice describes deliberate protective shutdowns, not proof its data was stolen. Palo Alto Networks says the PAN-OS issue concerns the management web interface; its GlobalProtect portal and gateway are not affected. The vendor reports no known malicious exploitation against its products.

And “PHP powers a large share of the web” is not a count of compromised websites. A software ecosystem's reach, an exposed installation and a confirmed breach are different measurements.

Does that mean every WordPress site is currently unsafe?#

No. Hosting and patch status change the answer.

Automattic says WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr were already protected. For self-managed installations, it explicitly distinguishes updating PHP from updating WordPress, themes or plugins.

That gives me a more useful question than “Do we use WordPress?”:

Which PHP package is actually serving requests, and who is responsible for updating it?

Were attackers already trying it?#

Amazon Threat Intelligence reports an October 17 exploitation attempt against its MadPot honeypots, four days before public disclosure, followed by broader attempts after release.

AWS also says it was unclear whether the observed attempts would have succeeded against real systems. That supports urgency, but not an invented tally of successful compromises or an attribution of those attacks to AI.

For defenders, the implication is practical: the public advisory date is not necessarily the earliest date worth investigating.

And where does vibe coding fit into this?#

I've worried that people could generate a working website without understanding the security decisions inside it. If building becomes easier than reviewing, that gap could become expensive.

PHP2Shell adds another layer to that concern. The vulnerability may live in the infrastructure beneath an application, regardless of who wrote the application.

It does not establish how much insecure software vibe coding produces. It does challenge the comforting assumption that familiar infrastructure has already had every serious weakness worked out.

The question becomes: can the team understand and maintain the whole system it is deploying, including the parts it did not write?

Aren't AI guardrails supposed to prevent this?#

They have a different job.

A safeguard around a coding assistant can influence what the assistant generates or which actions it takes. It does not replace the PHP binary on a production server. An AI security review can help find problems; it is not a guarantee that every runtime dependency is safe.

OpenAI's own disclosure discusses the difficult balance between blocking misuse and preserving legitimate security research. This incident is not a measured test of those safeguards, so I wouldn't present it as proof that a particular guardrail failed.

My conclusion is narrower: AI guardrails are one layer. Operational security still needs patching, access controls, isolation and accountable ownership.

What should a PHP operator actually do?#

The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. India's CERT-In advisory identifies older releases in those branches as affected.

Follow PHP's remediation guidance: install a fixed package or confirmed vendor backport, and ensure the serving workers use it. Older branches need vendor-specific backport verification or migration to a supported release. WAF rules and configuration changes reduce particular attack paths; they are not complete substitutes for the update. Appliance owners should follow their appliance vendor's instructions.

I haven't run these exploits myself. This article follows maintainer advisories, original research and operators' notices.

What stays with me is that finding a vulnerability and protecting a system are separate engineering tasks. AI can accelerate the first. The second still requires someone to know what is running, what it can access and how quickly it can be replaced.