Security vendors now report exploitation attempts against the two critical PHP flaws CVE-2026-109618 and CVE-2026-109619, often called PHP2Shell, and some say they have seen successful attacks. The only complete fix is unchanged: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker. If you patched after October 21, also check your server for signs of compromise. Our first report covers the original advisory.
Are the flaws being exploited?
When PHP shipped the fixes on October 21, the team said none of the proof-of-concept code it had reviewed actually worked. The picture has changed since then:
| Source | What it reports |
|---|---|
| Amazon Threat Intelligence | Saw an exploitation attempt on October 17, four days before disclosure, and says the flaws are now broadly exploited (as reported by Tenable) |
| watchTowr | Has observed exploitation of both flaws in its honeypot network since October 21 |
| Cloudflare | Its CTO said early attacks are beginning to emerge |
| CISA (US) | Had not added the flaws to its Known Exploited Vulnerabilities catalog as of October 22 |
Sources differ on attempts versus confirmed compromise, but the takeaway is the same: an unpatched PHP server exposed to the internet is now being scanned and targeted. The UK NCSC advised considering taking systems offline if they cannot be patched, and CERT-EU recommended isolating internet-facing applications until they are updated.
Affected and safe versions
| Version | Status | Action |
|---|---|---|
| 8.5.x before 8.5.12 | Affected | Upgrade to 8.5.12 |
| 8.4.x before 8.4.27 | Affected | Upgrade to 8.4.27 |
| 8.3.x before 8.3.36 | Affected | Upgrade to 8.3.36 |
| 8.2.x before 8.2.35 | Affected | Upgrade to 8.2.35; 8.2 reaches end of life on December 31, 2026 |
| 8.1, 8.0, 7.4 | No official release | Distribution/LTS packages or PHP’s source backports; ideally move to 8.3 or later |
| 7.3 and older (back to 5.4) | No fix | Migrate to a supported branch |
According to researchers, the vulnerable code path goes back to PHP 5.4.0, so old sites that have not been touched in years are exposed as well.
Linux version numbers can mislead
PHP shared the patches with distributions and long-term support vendors in advance, and Debian, Red Hat Enterprise Linux, Fedora and Gentoo have shipped fixed packages. Distributions usually backport the fix into their own package versions, so php -v may still print an older number such as 8.2.20. On these systems, compare your installed package against the version listed in your distribution’s security advisory for these CVEs rather than the upstream PHP number.
After you patch
- Restart all PHP workers. PHP-FPM pools and Apache keep running the old code until they are restarted.
- Verify the running version. The CLI version can differ from the one the web server uses; check with a temporary
phpinfo()page and delete it immediately. Our PHP version guide shows other ways. - Update every installed PHP version. Hosting panels can bind sites to different versions; remove the ones you no longer use.
- On shared hosting, get written confirmation from your provider and make sure your site is set to a current version in the panel.
Signs of compromise
If you patched after the October 21 disclosure, watchTowr recommends the following checks. Back up logs and suspicious files before changing anything so evidence is preserved.
- Web shells: unfamiliar
.phpfiles created recently in site directories. - Scheduled tasks and accounts: new cron jobs, system users or CMS administrator accounts.
- Logs: unusually large multipart POST requests or ones with deeply nested field names, and PHP workers crashing with out-of-memory errors.
- Network: unexplained outbound connections from PHP processes.
If you find anything, patching alone is not enough: rotate passwords and API keys and consider rebuilding from a clean backup. The HTTP headers tool shows what your server reveals publicly.
If you cannot patch yet
PHP’s advisory lists settings that may reduce the risk until you can upgrade. PHP states clearly that they do not make an installation safe, and watchTowr says .ini-based mitigations should be treated as ineffective. Treat them only as a bridge to the upgrade:
| Flaw | Interim setting suggested by PHP | Caveat |
|---|---|---|
| CVE-2026-109619 | session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart all workers | Changing it with ini_set() or .user.ini is not enough |
| CVE-2026-109619 (PHP 8.5) | Also fatal_error_backtraces=0 | Hiding error details is not protection on its own |
| CVE-2026-109618 | Lower post_max_size (e.g. 8M) with upload_max_filesize below it, and cap request size at the web server or proxy | PHP also mentions memory_limit=-1; it removes the memory cap, so use it only with a container or cgroup limit |
A web application firewall such as Cloudflare’s managed rules can block known attack patterns, but only for traffic that passes through it, and it is no substitute for the upgrade.
WordPress and other CMS sites
Researchers report confirming unauthenticated remote code execution against specific versions of WordPress, Drupal, Joomla and Magento. The bug is in PHP itself, not in these applications, so updating plugins or themes does not close it. In WordPress you can see the PHP version under Tools → Site Health → Info → Server.
Sources: PHP security advisory, watchTowr and Tenable (last updated October 23, 2026). This article will be updated as the situation changes.
Common Questions
Is PHP2Shell being exploited right now?
Amazon, watchTowr and Cloudflare report exploitation attempts and attacks. CISA had not added the flaws to its Known Exploited Vulnerabilities catalog as of October 22. Assume unpatched servers are being targeted.
php -v shows an old version but my distribution is updated. Am I safe?
Distributions such as Debian and RHEL backport fixes into their own package versions. Compare your installed package with the version listed in your distribution’s advisory for these CVEs.
I patched. Is there anything else to do?
Restart all PHP workers, confirm the version the web server is using and, if you patched after October 21, check for new PHP files, cron jobs and accounts.
I am on PHP 7.4. What should I do?
There is no official 7.4 release, only source backports and some distribution or LTS packages. The safest path is a supported branch, preferably 8.3 or later.
Does updating WordPress plugins fix it?
No. The flaw is in PHP itself. The server’s PHP must be updated; confirm this with your hosting provider.