# Two critical PHP vulnerabilities: what to do, and what we did

> On 21 October 2026 PHP fixed two critical vulnerabilities that let an attacker take control of a web server without a password. What they are, which versions to install, what to do if the server cannot be updated straight away, and how we handled it with our clients.

- Published: 2026-10-22
- Who it is for: Business owners, IT managers and anyone running a website or business application in PHP
- URL: https://cloudfactory.it/en/articles/critical-php-vulnerabilities-october-2026/

## What happened

On 20 October 2026 news of two critical vulnerabilities in PHP leaked online ahead of schedule, and the PHP team announced an out-of-band security release ([Huntress](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities)). On the afternoon of 21 October, Italian time, the fixed versions were released; that evening researchers published the technical details.

The two flaws are **CVE-2026-109618** and **CVE-2026-109619**, and some have dubbed them PHP2Shell. Both have a CVSS v4 score of 9.2 out of 10 and, under the right conditions, allow code to be executed on the server without authentication ([Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/)). CERT-EU, the cybersecurity service for the EU institutions, has also issued an advisory ([CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/)).

## Why it affects almost everyone

PHP is the language that runs WordPress, WooCommerce and a large share of web-based business applications. You do not see it, because it works on the server, but it is there: a well-maintained site with up-to-date plugins is still exposed if the server's PHP version is vulnerable.

According to the PHP team, every installation that serves web pages is at risk, whatever the configuration: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed ([Huntress](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities)). The two flaws exploit the handling of memory exhaustion and state left in memory between one request and the next; beyond code execution, researchers have demonstrated reading the process memory, which may hold passwords, tokens and access keys ([Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities)).

Qualys reports attack attempts already seen in the wild, flagged by Cloudflare, Amazon and some hosting providers ([Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities)). Rapid7 recommends emergency patching, outside normal maintenance cycles.

## The versions to install

These are the fixed versions ([Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/)):

| Branch | Fixed version | Notes |
| --- | --- | --- |
| PHP 8.5 | 8.5.12 | Supported |
| PHP 8.4 | 8.4.27 | Supported |
| PHP 8.3 | 8.3.36 | Supported |
| PHP 8.2 | 8.2.35 | Security fixes only |
| PHP 8.1 and earlier | No official release | Partial fixes in source code only for 7.4, 8.0 and 8.1 |

Be careful with Linux distribution packages: they often backport the fix while keeping the old version number, so what counts is the vendor's advisory, not the number you see on the server. Only a version that contains both fixes is considered a complete remedy.

## If the server cannot be updated straight away

It happens more often than you might think: unsupported operating systems, old PHP versions required by a business application, servers nobody wants to touch. In these cases there are temporary measures that reduce exposure, but they do not replace the update ([Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/), [Huntress](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities)):

- disable **session.upload_progress** in the server configuration (php.ini or the FPM pool), not from the application, and restart the PHP processes;
- on PHP 8.5, disable **fatal_error_backtraces** at the same level;
- limit the size of incoming requests, for example with post_max_size and with rules on the web server or the web application firewall;
- put the server behind a web application firewall or a VPN, or take it off the Internet if it does not need to be public;
- check whether PHP processes are spawning shells or download tools, and keep the logs for retrospective checks.

Hiding errors with display_errors or error_reporting offers no protection: the problem occurs regardless.

## How we handled it

We run PHP websites, e-commerce stores and business applications for clients in healthcare, publishing, tourism and services. On the day of the fix we worked in this order:

1. **Inventory before the patch.** On the morning of 21 October, before the release, we checked the PHP versions in use on every server, so we already knew where to act once the fix came out.
2. **Logs preserved.** We set aside the logs from the previous days, so we could search back for attack attempts once the technical details were published.
3. **A clear notice to every client.** Between 9:48 and 10:47 we wrote to nine clients, each with the list of their own affected systems: what is happening, what we are doing, what they need to do. Almost always, nothing.
4. **Update where possible.** On servers with a supported operating system, we updated PHP as soon as the fixed package was available, starting with those holding personal and health data, then checked that pages, forms and payments worked as before.
5. **Mitigations where the update is not enough.** On servers with older operating systems we applied the mitigations recommended by CERT-EU, put the applications behind Cloudflare, closed databases and internal services to outside access, shut down old test sites that were still reachable and enabled automatic security updates.

On one of the most exposed environments the check found no signs of intrusion or suspicious changes. The mitigations do come at a visible cost, though: with the request limit, for example, files larger than 30 MB can no longer be uploaded. For those servers the definitive solution is a move to new machines with a supported operating system, which we are planning with the clients.

## What a day like this teaches

- **Know what you have.** Without an up-to-date inventory of servers and versions, the first day is spent searching instead of fixing.
- **Be the first to tell.** A client who reads the news elsewhere and has not heard from their provider worries twice as much.
- **Prioritise data.** A form where people enter personal or health data must be secured before a brochure page.
- **Updated does not mean working.** Every update must be followed by a check, and every new restriction must be communicated.
- **An old server is a debt.** Mitigations buy time; sooner or later the migration has to happen, and it is better done calmly than on the day of the next vulnerability.

## Frequently asked questions

### Is my WordPress site at risk?

Yes, if the server's PHP version does not include the fixes of 21 October 2026. Updating WordPress and its plugins is not enough: PHP must be updated on the server.

### Which PHP versions are safe?

8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later, or your Linux distribution's packages that include both fixes.

### What do I do if I run PHP 7 or 8.0?

There are no official fixed versions. Apply the temporary mitigations straight away and plan the move to a supported version, together with whoever maintains the site or application.

### Are attacks under way?

Several sources, including Qualys, report attack attempts already seen in the wild. Any server that has not been updated should be considered exposed.

### Do clients managed by Cloudfactory need to do anything?

No. Updates, mitigations and checks are on us, and every client receives the outcome of the work on their own systems.

## Sources

- [Rapid7, CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/)
- [Qualys, PHP2Shell: PHP Patches Two Critical RCE Vulnerabilities](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities)
- [Huntress, php2shell: Leaked Critical PHP Vulnerabilities](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities)
- [CERT-EU, Security Advisory 2026-018](https://cert.europa.eu/publications/security-advisories/2026-018/)

---

Cloudfactory S.r.l., Rome. Contact: hello@cloudfactory.it