Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were patched on October 21, 2026. Here’s what they are, who’s affected, and a free Zabbix template that shows you which servers need attention.
If your organization runs PHP, and odds are it does somewhere, this week brought a patch you shouldn’t sit on. The PHP project has released fixes for two critical PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution (RCE) on a web server. Both carry a CVSS score of 9.2, and a working exploit has already been demonstrated.
What Are the PHP2Shell Vulnerabilities?
Both bugs come down to how PHP cleans up after something goes wrong in the middle of handling a web request.
- CVE-2026-109618 involves out-of-memory errors. If PHP runs out of memory while it’s still setting up a request, the cleanup code can treat half-built data as if it were valid. An attacker who can trigger that condition can turn it into code execution.
- CVE-2026-109619 involves leftover state. Data that belongs to one request can outlive the memory it points to, and the next request handled by the same PHP worker can use it before it gets reset.
The part that makes this serious: a single request with no login can trigger the attack before any application code runs. It doesn’t matter how well your WordPress site, Laravel app, or internal portal is written. The flaw is in PHP itself.
Which PHP Versions and Servers Are Affected by PHP2Shell?
Any PHP installation that serves web requests. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project considers mod_php the highest-risk setup. Palo Alto Networks’ Unit 42 estimates more than 22 million internet-facing instances may be exposed.
How to Patch the PHP2Shell Vulnerabilities
The PHP2Shell vulnerabilities have been addressed in the following PHP releases. Update affected installations to the appropriate patched version:
| PHP branch | Fixed in |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 and older | No official release (end of life). Use your vendor’s patched package or upgrade. |
Most Linux servers get PHP from their distribution (Red Hat, Debian, Ubuntu, and others) rather than from php.net. Those vendors received the patches ahead of time, so check your vendor’s security advisories and apply their updated packages, then restart PHP-FPM or Apache.
If you can’t patch right away, the PHP advisory lists interim configuration changes that reduce exposure, such as limiting request sizes and disabling session upload progress. They narrow the attack paths but don’t close them, so treat them as a stopgap, not a fix.
Finding Vulnerable PHP Installations Across Your Environment
Patching is the easy part. Finding every server that needs it is harder. PHP gets installed as a dependency, left behind on retired apps, and pinned to old versions on servers nobody has touched in years. A spreadsheet from last quarter won’t tell you what’s running today.
If you already use Zabbix to monitor your Linux servers, you have everything you need to answer that question across your whole environment.
How to Detect PHP2Shell Vulnerabilities with Zabbix
Zabbix can discover installed PHP packages, track their versions, and flag potentially vulnerable systems. ATS Group’s free PHP package discovery template automates this process across monitored Linux hosts, helping administrators identify systems that require investigation or patching.
We’ve published a free, open-source Zabbix template, PHP package discovery by ATS, that you can link to your Linux hosts. It uses the Zabbix agent’s built-in package inventory, so there’s nothing to install on your servers and no scripts to maintain.
Here’s what it gives you:
- An inventory of every PHP package on each host, with its installed version, collected once an hour.
- A PHP2Shell status for each PHP install: Not affected, Vulnerable, or End-of-life branch.
- Problems in Zabbix for any host running a vulnerable or end-of-life PHP version. They clear on their own once the server is patched.
- An alert when PHP versions change, so you can confirm patches actually landed.
Because it plugs into Zabbix problems, everything you already have set up works with it: dashboards, email or Teams notifications, and ticket creation. Filter your Problems view by the tag cve: CVE-2026-109618, and you have a live list of every server that still needs attention.
PHP packages discovered on a RHEL 9 server in Zabbix. This host runs PHP 8.0, an end-of-life branch, so the template flags it.
Accounting for Vendor-Patched PHP Packages
Enterprise Linux vendors often patch PHP without changing its version number. A fully patched Red Hat package might still report an older PHP version, so the template could flag it even though it’s safe. Once your vendor confirms which package release contains the fix, add it to one setting in the template and those alerts clear. The README walks through it.
How to Install the Free Zabbix PHP Discovery Template
- Download the template from our GitHub repository: PHP package discovery by ATS.
- In Zabbix (7.0 or newer), go to Data collection → Templates → Import and import the YAML file.
- Link the template to your Linux hosts, or to the template or host group that covers them.
- Within an hour, check Monitoring → Problems for anything flagged.
The README covers every setting, how the check works, and how to handle vendor-patched packages.
Need Help with Zabbix Monitoring?
ATS Group helps organizations design, run, and get more out of their Zabbix environments. If you want help rolling this out, building a vulnerability dashboard, or tightening up your monitoring in general, reach out to our team.
