PHP2Shell: critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) — what to do now

Two critical flaws in the PHP engine itself allow unauthenticated remote takeover of a server and are already being exploited. Check your versions, patch, and verify that you have not been compromised.

In short

• What: two critical vulnerabilities in the PHP engine (dubbed “PHP2Shell”) allowing unauthenticated remote code execution. CVSS v4.0 score: 9.2 each.
• Who is affected: virtually every PHP installation serving web traffic — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. Highest risk: mod_php.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (released 21 October 2026).
• Status: actively exploited — added to the CISA KEV catalogue on 26 October 2026.
• What to do: update PHP immediately, restart all PHP processes, and check whether the server has already been compromised.

What happened

On 21 October 2026, the PHP project released emergency security updates for all supported branches. They fix two vulnerabilities in the language engine itself — not in applications, frameworks or plugins:

• CVE-2026-109618 — memory corruption in out-of-memory handling. When PHP aborts a request during initialisation, the clean-up routine can treat partially prepared data as valid.
• CVE-2026-109619 — “stale global state”. Internal request state can survive after the memory it points to is freed and be used by the next request handled by the same process.

In both cases the result can be remote code execution with the web server’s privileges, without logging in to the application. According to the researchers, even the simplest application can be vulnerable — the flaw is in the engine, not in the site’s code.

A leak made things worse: details appeared on social media a day before the planned disclosure, so attackers got the information at roughly the same time as administrators.

Are your systems vulnerable?

Three important notes:

1. The version number is not the whole story. Linux distributions and LTS support vendors received the fixes early and often ship them without changing the main version number. Check that your vendor’s patched package is installed, not just php -v.
2. Older branches. For PHP 7.4, 8.0 and 8.1 the PHP project provided only minimal source-code fixes. If anything in your company still runs on such an old version, migration cannot wait any longer.
3. PHP 8.2 reaches end of support on 31 December 2026. Systems on that branch should go straight into the migration plan.

How serious is the threat?

• watchTowr has seen exploitation attempts in its honeypots since 21 October.
• CISA added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalogue on 26 October, and ordered US federal agencies not only to patch but also to carry out post-compromise analysis.
• Rapid7 reports many attack attempts. Publicly available exploits currently work only in specific configurations, but researchers expect more universal ones soon.
• In Poland, the Central IT Centre (COI) temporarily took offline Public Information Bulletin (BIP) sites running on the SSDIP system on 22 October.

So this is not a “theoretical” vulnerability. Every internet-facing PHP server should be treated as at risk until it has been updated and checked.

What to do — today’s plan

1. Inventory PHP across the company. Not just the main website: also the marketing team’s WordPress, the intranet, admin panels, online shops, B2B systems, test environments, containers and Docker images, shared hosting, and vendor appliances or software that run PHP “under the hood”. Start with internet-facing systems.
2. Update PHP to a fixed version or install your OS vendor’s patched package.
3. Restart all PHP processes (PHP-FPM pools, Apache with mod_php). Installing the package is not enough if the old processes are still running.
4. Rebuild container images on an updated base image and redeploy them.
5. Verify after the update that the patched version is running on every server.
6. Ask your suppliers — hosting providers, software vendors and agencies — to confirm in writing that their environments are patched.

If you cannot update immediately

The PHP project has published risk-reduction measures. It stresses clearly, however, that they do not make an installation safe — they only reduce exposure until you can update:

• set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration,
• set memory_limit=-1 administratively (e.g. via php_admin_value) and limit post_max_size (8M without uploads, 32M with uploads),
• on PHP 8.5, also set fatal_error_backtraces=0,
• limit request size and complexity at the web server or proxy; if the application does not accept multipart forms, block them before they reach PHP,
• after every change, restart all PHP processes.

Settings applied via ini_set() in code or a .user.ini file take effect too late and do not protect you. Hiding errors (display_errors, @) does not help either. The safest temporary option is to restrict internet access to any system that cannot be updated.

Check whether you have been compromised

Since attacks began on the day of disclosure, patching alone may not be enough. On internet-facing servers, check for:

• new or modified PHP files in application, upload and temporary directories (a typical place for web shells),
• unusual processes run by the web server user,
• unexpected outbound connections from the server,
• changes to cron jobs, user accounts and SSH keys,
• PHP fatal errors and unusual requests in logs from 20 October onwards.

An absence of traces in the logs does not prove that no compromise occurred. If in doubt, treat the server as compromised: rebuild it from a clean image and rotate the passwords and keys used by the application.

A lesson for the board

Situations like this put three things to a hard test:

• Do we know what we have? Without an up-to-date system inventory, you cannot respond within hours.
• How fast do we patch? A company should have a defined response time for critical vulnerabilities — measured in hours or days, not weeks.
• Are we running outdated software? Systems on unsupported PHP versions are a risk that, with a vulnerability like this, becomes a real problem.

For companies covered by Poland’s new Act on the National Cybersecurity System, there is also incident reporting: an early warning of a significant incident must be submitted within 24 hours. I write more about these obligations in NIS2 for mid-sized companies: where to start.

Sources

• PHP — security release announcement, 21 October 2026 (php.net)
• PHP Foundation — Today’s PHP security release and how we’re strengthening PHP security
• Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP
• watchTowr — CVE-2026-109618: Exploited Remote Code Execution in PHP (FAQ)
• Wiz — PHP2Shell: PHP RCE
• Sekurak — Critical vulnerabilities in PHP core, patch released (in Polish)
• Android.com.pl — BIP sites taken offline due to PHP2Shell (in Polish)
• CISA — Critical Vulnerabilities in PHP Require Immediate Patching

Status as of 29 October 2026. The situation is evolving quickly — follow announcements from the PHP project and your system vendor.