If you have a website, there is a reasonable chance it runs on PHP, even if you have never heard of it.
PHP is a server-side programming language that powers approximately 69.3% of all websites with a known server-side programming language, according to W3Techs data current as of October 21, 2026. You encounter it constantly without realizing it: WordPress, the platform behind approximately 42.5% of all websites on the internet, is built on PHP. So are major platforms like Wikipedia and a vast number of e-commerce, news, and business applications.
When a visitor loads a page on a PHP-powered site, the web server runs PHP code behind the scenes to assemble and deliver that page. PHP handles things like user logins, contact forms, shopping carts, and database queries. It is, in short, a foundational piece of infrastructure for a large portion of the modern web.
Security vulnerability research typically follows a process called coordinated disclosure: researchers who discover a flaw notify the affected software maintainers privately, give them time to develop and stage a fix, and then both parties announce the vulnerability and the patch at the same time. This protects users by ensuring a fix is available before the details of the flaw are made public.
In this case, that process was disrupted. Details of both vulnerabilities were leaked publicly on October 20, 2026, one day before the PHP project's planned disclosure date of October 21. The PHP security team responded by accelerating their timeline and scheduling the official patch release for 10:00 AM Eastern Time on October 21, with a commitment to push the release even earlier if they observed active exploitation in the wild.
As of the time of writing, no confirmed active exploitation of either vulnerability has been observed. The PHP project has also stated they would move up the release if that changes. That said, the gap between leak and patch (even a short one) is the period of highest concern with any disclosed vulnerability, and the fact that technical details were available publicly for approximately 24 hours before the patch means awareness and preparation are warranted.
The PHP development team released patched versions of PHP (8.2.35, 8.3.36, 8.4.27, and 8.5.12) addressing two critical vulnerabilities. Both are rated 9.2 out of 10 on the industry-standard CVSS severity scale and classified as Critical.
Both vulnerabilities allow what security researchers call Remote Code Execution (RCE), meaning an attacker on the internet, with no account or login, could potentially run arbitrary commands on a vulnerable web server just by sending a crafted HTTP request.
The two vulnerabilities are:
CVE-2026-109618 — RCE via Out-of-Memory (OOM) Corruption
Technical advisory: GHSA-w8hw-w9fx-j79w
PHP has a configurable memory limit for handling web requests. When that limit is hit, PHP uses an internal mechanism called longjmp() to abort the current operation quickly. The problem is that in some situations, PHP begins setting up data structures for a request before they are fully ready. If a memory failure happens at that exact moment, PHP exits abruptly and leaves those data structures in an incomplete, invalid state, but the cleanup process runs anyway and tries to use them.
Think of it like a factory worker who starts assembling a product, is suddenly called away mid-assembly, and then a colleague comes along and tries to quality-check the unfinished product as if it were complete, with unpredictable results.
An attacker can deliberately craft HTTP requests (for example, uploading large multipart form data) to push a PHP server into this exact scenario, potentially triggering the invalid memory handling and achieving code execution on the server. This exploit has been demonstrated in a working proof of concept against Apache mod_php, and it can succeed before any of your application's own security code even runs.
CVE-2026-109619 — RCE via Stale Global State
Technical advisory: GHSA-6wmf-4rv5-p3rp
PHP web servers handle many requests in sequence using persistent worker processes. After one request finishes, the worker resets its internal state before starting the next one. This vulnerability arises when that reset does not happen cleanly; specifically, when a fatal error interrupts a request before it can properly clean up after itself.
The leftover data from the interrupted request remains accessible in the worker's memory. When the same worker picks up the next incoming request, certain PHP operations that run very early, before normal initialization completes, completes, can inadvertently read that stale, now-freed memory. This is what security researchers call a use-after-free vulnerability. If an attacker can influence the shape of that stale memory, they may be able to redirect what the server executes.
This vulnerability has been confirmed as exploitable for remote code execution against both Apache mod_php and PHP-FPM configurations.
A few factors make these particularly noteworthy:
No authentication required. An attacker does not need an account, a password, or any prior access to your site. They only need to be able to send HTTP requests to your server; which, if you run a public website, is anyone on the internet.
Exploitation can occur before your application runs. In certain server configurations (most significantly Apache mod_php), the attack can succeed entirely during PHP's internal startup phase, meaning your application's own security controls (login checks, input validation, firewalls built into your code) are never reached.
Technical details were publicly available for approximately 24 hours before the patch. While no active exploitation has been observed yet, the early leak means the details were available to both defenders and potential threat actors alike during that window.
The scale of exposure is significant. Given that PHP underpins the majority of the web, the population of potentially affected servers is very large. All PHP installations serving web requests are considered at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
PHP 8.1 and older are no longer receiving standard security updates from the PHP project. If you are running PHP 8.1 or earlier, you are in a more complex position (addressed below).
The PHP team has released patched versions that resolve both vulnerabilities:
| Supported Branch | Patched Version |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
For most server environments, the appropriate action is to update PHP to the relevant patched version as soon as possible. Linux distribution packages were provided to vendors in advance, check your distribution's package manager (e.g., apt, dnf, yum) for updated PHP packages. Windows builds are available on the
PHP downloads page.
If you are running PHP 8.1 or older: The PHP project no longer provides standard security updates for these versions, but given the severity of these vulnerabilities, the PHP security team has published minimal source-level backports for PHP 7.4, 8.0, and 8.1. Some Linux distributions and long-term support (LTS) vendors also provide backported fixes; contact your vendor or hosting provider for guidance. If you are on an unsupported version, this is also a strong prompt to plan an upgrade to a currently supported branch.
A note on third-party package repositories: the PHP project has specifically noted that the volunteer-maintained rpms.remirepo.net repository will not have updates available today. If you rely on that repository, it is worth switching to your distribution's official packages or building from source for this update.
Patching is the only complete resolution. That said, if you are unable to update right away (due to application compatibility testing, change management windows, or other constraints) the following measures can meaningfully reduce exposure while you work toward a full update. These are not substitutes for patching.
For CVE-2026-109618 (OOM Corruption):
Set memory_limit=-1 administratively. This removes the predictable per-request PHP memory limit that enables the confirmed exploit path. Apply this at the server or FPM pool level (e.g., using php_admin_value in Apache or PHP-FPM pool configuration) so that individual applications cannot override it. Note that this does not eliminate all possible OOM scenarios — only the controllable limit-based ones.
Reduce post_max_size. For applications that do not require file uploads, set post_max_size = 8M. If file uploads are necessary, post_max_size = 32M is a reasonable conservative value. Keep upload_max_filesize below post_max_size.
Enforce request size limits at your web server or reverse proxy. Configure your frontend (nginx, Apache, load balancer) to limit decoded request body size, input field count, multipart part count, and header count independently of PHP. This provides an additional layer of protection even for requests that do not include a valid Content-Length header.
If your application does not use file uploads or multipart forms at all, consider blocking multipart requests at the web server before they reach PHP.
For CVE-2026-109619 (Stale Global State):
On PHP 8.5, set fatal_error_backtraces=0 administratively and restart all PHP workers. This disables the specific state storage mechanism behind the confirmed RCE demonstration for this CVE.
Set session.upload_progress.enabled=0 administratively and restart all PHP workers. This closes the demonstrated session lifecycle attack path. If your application does not use session upload progress (most do not), this is a low-risk configuration change that the PHP team recommends even after patching.
Audit your error and INI configuration. Enable log_errors=On, set error_reporting=E_ALL, and review your logs for repeated warnings or deprecations that appear before your scripts run. Reducing the number of INI-related diagnostics produced at startup limits the consumer paths for this vulnerability.
For lower-traffic environments, setting pm.max_requests=1 in PHP-FPM forces each worker to handle only a single request before recycling, which breaks the cross-request state contamination mechanism this vulnerability relies on. This comes at a performance cost and is not practical for high-traffic sites.
In all cases: restart all PHP workers after making configuration changes to ensure stale in-memory state is cleared.
Identify whether PHP is in your environment. If you manage web servers, hosting, or CMS platforms (WordPress, Joomla, Drupal, etc.), PHP is almost certainly present.
Check your PHP version. Your hosting control panel, server admin, or a developer can confirm this. Compare it against the patched versions listed above.
Apply the update. The patched PHP versions are available now. Work with your IT team, managed service provider, or hosting provider to apply the appropriate update as quickly as your change management process allows.
Apply interim mitigations if update timing is constrained. Use the configuration measures above as a bridge, not a destination.
If you are on an end-of-life PHP version (8.1 or older), treat this as an escalation point for a version upgrade plan.
Sources:
PHP Project Security Advisory, October 21, 2026
CVE-2026-109618 — RCE via OOM Corruption (GHSA-w8hw-w9fx-j79w)
CVE-2026-109619 — RCE via Stale Global State (GHSA-6wmf-4rv5-p3rp)