OpenAI says researchers working through its Patch the Planet initiative used GPT-5.6 Sol to help uncover critical vulnerabilities in PHP, the server-side language used by websites and web applications. The disclosure is notable for two reasons: it shows how AI-assisted analysis can help security teams investigate difficult software flaws, and it puts a practical task in front of PHP operators—identify affected runtimes and install the appropriate fix.
The PHP project published security releases on October 21, 2026, for two critical vulnerabilities. OpenAI says PHP maintainers led the fixes, while researchers and security partners contributed technical work and coordinated preparations for disclosure. The finding is not a WordPress-specific bug, but WordPress sites can be affected because PHP runs on the server beneath the content management system. ([openai.com](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/))
What OpenAI says happened
In its October 21 disclosure, OpenAI described a coalition involving maintainers, researchers and security providers. Calif identified a critical flaw with GPT-5.6 Sol as part of Patch the Planet. Wiz independently discovered and reported both vulnerabilities, according to OpenAI. The company says PHP’s maintainers led the remediation and release, while OpenAI, Wiz, Cloudflare and others contributed research, technical support or coordination.
This distinction matters: the public account describes AI as part of a human-led security process, not as an autonomous system that independently found, verified and fixed the bugs. Researchers investigated the code and findings, and maintainers were responsible for the PHP changes and release. OpenAI also says the work included testing fixes and coordinating with providers and government cyber agencies ahead of public disclosure. ([openai.com](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/))
What the PHP vulnerabilities could allow
The two issues are tracked as CVE-2026-109618 and CVE-2026-109619. PHP’s security advisories classify both as critical and describe them as potentially enabling remote code execution. In plain terms, under certain conditions, a remote attacker could cause code to run with the privileges of the affected web worker. That could put the server and the data or services it can access at risk.
The first issue concerns PHP’s handling of out-of-memory errors. The advisory explains that, in some circumstances, an error can interrupt request processing while internal state is only partly initialized. Later cleanup may then interact with invalid state. The second involves request-related global state that can remain stale after one request and be used during processing of a later request handled by the same worker.
These are flaws in PHP itself, rather than a defect that must be present in a particular WordPress plugin or theme. That does not mean every PHP website is equally exposed or that compromise is inevitable. The advisories describe conditions that vary by runtime, configuration, application and request path. But application code that appears sound does not, by itself, rule out a vulnerability in the underlying PHP engine. ([github.com](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w))
Why the story has broader reach—and what “70%” means
Tom’s Hardware reported the estimate that PHP runs about 70% of websites. That figure illustrates why a flaw in a widely deployed server-side language can draw attention, but it should not be read as meaning that 70% of websites are confirmed vulnerable or exploitable. Exposure depends on whether a site or product actually uses an affected PHP runtime, which version it runs, how it is configured, and whether a vendor has supplied a fix or backport.
PHP may be installed directly on a server, supplied by a hosting company, included in a container image, or bundled inside an appliance or other product. A site owner may not manage the PHP installation personally. A managed host may control upgrades, while an organization running its own servers may need to patch packages, rebuild images, or update an application appliance through its vendor. ([tomshardware.com](https://www.tomshardware.com/tech-industry/cyber-security/openai-says-gpt-5-6-sol-helped-uncover-critical-php-flaws-that-could-affect-70-percent-of-websites-ai-assisted-researchers-turned-two-year-old-bug-that-stumped-human-developers-into-working-exploits-in-two-weeks))
Which PHP releases have fixes?
The PHP project’s published fixed releases for the affected supported branches are:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
These are upstream version numbers. Linux distributions, hosting providers and software vendors may package or backport the security fix differently, so an operator should not decide a system is vulnerable—or safe—based only on a version string viewed without context. Check the PHP advisories and the guidance from the organization that supplies your PHP packages or service. PHP 8.1 and older are not among the currently supported upstream branches listed for these releases; some vendors may provide their own security updates for older deployments. Confirm that explicitly rather than assuming an unsupported installation has been fixed. ([github.com](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w))
Practical steps for site owners and administrators
- Identify every PHP runtime you operate. Check web servers, PHP-FPM pools, containers, staging systems, management interfaces and products that bundle PHP. A WordPress dashboard or plugin list may not tell you which server runtime is active.
- Ask your host or vendor for the exact status. If a provider manages the server, ask whether the runtime or its package includes fixes for CVE-2026-109618 and CVE-2026-109619, when the update was applied, and whether PHP workers were restarted. For appliances and bundled software, follow the product vendor’s advisory.
- Update through the supported channel. Install the applicable fixed PHP release or a vendor-confirmed security backport. On self-managed systems, use the operating system or package vendor’s instructions and follow your normal testing and change-control process. Do not assume that changing the WordPress application version updates PHP.
- Verify the running service, not just the package. Confirm the active PHP version or patched package in the environment serving requests, then restart or reload the relevant service when required by your deployment. Check all pools, containers and hosts behind a load balancer.
- Plan carefully for old branches. If your installation is outside PHP’s currently supported upstream branches, determine whether a trusted vendor has issued a backport. If not, plan a move to a supported release and assess the compatibility work needed.
- Review incident-response needs. Patching removes the vulnerable code path but does not establish whether a system was previously compromised. If you have signs of suspicious activity, follow your incident-response process, preserve relevant logs and seek qualified help. Avoid treating the absence of an obvious alert as proof that no incident occurred.
PHP’s advisory says updating to a release containing the fix is the only complete mitigation for the out-of-memory issue. It discusses configuration measures for systems that cannot immediately update, but explicitly warns that those measures are incomplete. Treat temporary settings or traffic controls as risk reduction while arranging a supported fix—not as a replacement for one. ([github.com](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w))
What the discovery says about AI in cybersecurity
The OpenAI AI-discovered PHP vulnerabilities offer a concrete example of AI-assisted defensive research: a model helped researchers examine a complex, widely used codebase, and the reported work became part of a coordinated effort to validate findings and prepare fixes. OpenAI presents this as a “Defender’s Window”—a period in which defenders can use emerging capabilities to find and fix weaknesses before similar capabilities are more widely available to attackers.
That framing also points to a genuine risk. Tools that help researchers reason about code and vulnerabilities could also help malicious actors. OpenAI itself says the same capabilities can assist attackers in developing offensive tools. The lesson is not that AI makes software secure automatically, or that every AI-generated finding is correct. It is that capable tools may speed parts of security research, while responsible disclosure, human review, maintainers’ expertise, careful patch testing and broad deployment remain essential.
There are limits to what can be concluded from a single disclosure. OpenAI’s account is a first-party description of its own initiative; it is not, by itself, an independent evaluation of how much the model contributed relative to researchers or other tools. The PHP advisories provide the authoritative technical and remediation details. The incident also does not prove that every PHP site was exploitable, that all AI-assisted findings will be valid, or that a patch can be safely skipped because an installation appears low-risk.
Frequently asked questions
Is this a WordPress vulnerability?
No. The disclosed flaws are in the PHP runtime. WordPress sites may be affected if they run an affected PHP installation, but updating WordPress alone does not patch the server’s PHP engine. Contact your hosting provider or administrator to confirm the runtime’s status.
Does the 70% figure mean 70% of websites are vulnerable?
No. It is a reported estimate of PHP’s use across websites, not a count of confirmed vulnerable sites. Actual exposure depends on the PHP version, vendor updates and deployment conditions.
Which version should I install?
For upstream supported branches, the published fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Check the official PHP advisories and your package, hosting or product vendor’s guidance to identify the correct update for your environment. A vendor may provide a backport under a different package version.
Will a web application firewall or a PHP setting fix the issue?
Do not assume so. PHP’s advisory says updating is the only complete mitigation for CVE-2026-109618 and describes configuration changes as incomplete risk reduction. Follow official PHP and vendor guidance, and prioritize applying a confirmed fix.
What should a managed WordPress site owner do?
Ask the host whether every PHP runtime serving your site is patched, including any staging or secondary environment. Request confirmation of the relevant CVEs or the provider’s security bulletin, and ask whether service workers were restarted if that is part of its update procedure.
Bottom line
OpenAI’s disclosure shows how AI-assisted research can contribute to defensive work on foundational software—but the practical outcome depends on maintainers, vendors and operators completing the response. PHP maintainers have published fixes for supported branches. If you operate a PHP-based site or product, identify the runtime, verify the applicable vendor guidance and deploy the appropriate security update promptly.
