PHP2Shell questions, answered

Short answers on CVE-2026-109618 and CVE-2026-109619: fixed versions, shared hosting, WordPress, WAFs, restarts, exploitation, KEV and old PHP.

Versions and fixes

Am I affected?

Probably, if you run PHP behind a web server and your version is below 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Both flaws are in PHP itself, so it does not matter which CMS or framework you use. Enter your version in the check, or use the triage page if you are not sure who runs PHP for you.

Which versions are fixed?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older got no release. The PHP project published source backport branches for 7.4, 8.0 and 8.1 only. The full table is on status.

Hosting, WordPress and WAFs

I use shared hosting. Do I need to do anything?

Your host patches PHP. Ask which PHP build serves your site and when the workers were restarted, and switch to a newer version in your panel if your site supports it. The steps and the three questions are in the shared hosting guide.

Is WordPress itself vulnerable?

No. Both flaws are in PHP. WordPress.org says no WordPress update is required or planned, and that you should update PHP. See how to check your PHP version.

Does a WAF or Cloudflare fix it?

No. The PHP project says there is no complete mitigation and that upgrading is the only safe option. Cloudflare reports that attackers changed their payloads to get past WAF rules. A WAF can add a layer of protection, and you still need the upgrade. See the WAF guide.

My distro shows an older version number. Am I fixed?

Maybe. Ubuntu, Debian, Red Hat and others patch their own packages and keep the old number. Check the package changelog for both CVE numbers, as in the guide for your system: Ubuntu, Debian, RHEL.

Do I need to restart anything?

Yes. A package update does not change PHP processes that are already running. Restart PHP-FPM, Apache or LiteSpeed, then check the version the web side reports. The steps are in after patching.

Exploitation and compromise

Is it being exploited?

Vendors say so. Cloudflare, watchTowr and Patchstack report attack attempts. CISA said it had not observed exploitation when it published, and BSI and CERT-EU had not confirmed it. The PHP project's announcement does not report exploitation either. Current notes are on status.

Is it in CISA's KEV catalog?

Not at our last check. Neither CVE was in the Known Exploited Vulnerabilities catalog on 21 October 2026. That can change, and we recheck before each update. The latest result is on status.

Old PHP versions and Docker

What about PHP 7.4 and PHP 8.1?

Both are end of life, and the PHP project offers only a source branch for each, which you would have to compile. Check whether your distribution or panel already patched its own build, or move to a supported version. See PHP 7.4 and PHP 8.1.

What about PHP 5?

The PHP project says nothing about PHP 5. Secondary sources claim it is affected, and there is no upstream fix. Treat it as affected and plan the move. See PHP 5.

Should I move to PHP 8.2?

Only for a short time. 8.2.35 fixes both flaws, but branch 8.2 ends on 31 December 2026. We recommend 8.4, or 8.3 if something is not ready. See PHP 8.2.

Does the Docker image tag matter?

Yes. Use a tag that resolves to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, such as php:8.4.27-fpm, and rebuild and redeploy your containers. RC tags are not the fixed release, and 8.1 and older tags are not patched. Restarting an old container brings back the old PHP. See the Docker guide.

Is the PHP command line affected?

The official list of affected ways to run PHP is PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The command line (CLI) is not on that list. Upgrade the package anyway: the CLI and the web side usually come from the same install, and php -v tells you what you have.

How do I know if I was hacked?

You may not be able to tell. The advisories publish no indicators of compromise, and a clean log is not proof, because an attack can happen before PHP logs anything. CISA's guidance is to look for PHP workers starting shells or download tools. Start with after patching and, for WordPress, if your site was hacked.

Mitigations and upgrades

Can I just turn off session.upload_progress?

That helps with only one of the two flaws. The PHP project lists session.upload_progress.enabled=0 as a mitigation for CVE-2026-109619 and nothing equivalent for CVE-2026-109618. It reduces exposure, and you still need to upgrade. The official temporary settings are on what to do if you cannot upgrade yet.

Will upgrading break my site?

It can, mainly when you jump several versions. Test on a copy first. The guides cover the common breakages: 7.4 to 8.4, 8.1 to 8.4, 8.2 to 8.4, or see all upgrades.

About this site

Who are you, and how do you make money?

We are an independent site, not affiliated with the PHP project or WordPress. The fix information is free. We earn money from optional paid help, and any future paid link will be marked. Details are on about and recommended.

Last reviewed on 22 October 2026.