Two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, could let an unauthenticated visitor run code on a web server. The PHP project announced them on 21 October 2026 and rates both 9.2 on CVSS v4.0. CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on 26 October 2026.
This is a short, defensive summary for people who run PHP sites (WordPress, Drupal, Joomla or custom code). I read the PHP advisories, CISA and the NVD record rather than news posts, and I list at the end what I could not confirm.
What to run
Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, then restart PHP-FPM, Apache or IIS so every worker loads it. PHP's advisory says updating is the only complete fix. PHP 8.1 and older no longer get project updates, although the project published minimal source backports for 7.4, 8.0 and 8.1 and some vendors ship their own fixes.
WordPress, Drupal and Joomla do not carry their own PHP. They use the PHP of your server or hosting plan, so patching the CMS does not fix this.
The version number can mislead
Debian, Ubuntu and Red Hat family distributions often backport a fix and keep the old version number. AlmaLinux says so explicitly about its patched packages. So an old-looking version is not proof you are exposed, and a new-looking one is not always a patch. Check your distribution's security notice for the package build (for example the Debian security tracker or Ubuntu's CVE page), or ask your host in writing which fix they applied.
Also remember that php -v shows the command-line PHP, which can differ from the one your web server uses. Check php-fpm -v, your control panel's PHP selector, or the WordPress Site Health info page.
Patched is not the same as clean
Security vendors report exploitation attempts before the patches existed, so patching does not remove anything an attacker already left behind. Preserve logs first, then check, read-only:
- New or recently changed
.php,.phtmlor.pharfiles in upload, cache and temp folders, and files you did not deploy:
find /var/www -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -mtime -30
- Changed
.htaccessorweb.configfiles - Unexpected CMS administrators, new cron jobs or server users
- Web server or PHP processes starting shells, or making outbound connections you do not expect
If you find something: isolate the server, rotate every credential it held (database, API keys, CMS admin, SSH), rebuild from a clean source on a patched system, restore data only after review, and find the entry point. Deleting a suspicious file alone is not enough.
If you cannot patch today
CISA advises taking PHP-based systems offline until they are updated if you cannot patch immediately, and says a web application firewall may give some interim protection. PHP also lists interim settings (for example session.upload_progress.enabled=0), but they reduce risk only. Read the advisories before changing anything.
What I could not confirm
I could not read the Red Hat bulletin or confirm a fixed Red Hat package, so ask your vendor. I could not confirm which CVE the observed attacks used, or the exact date they began, because vendors disagree. I have not tested any of this on a compromised server, and nothing here guarantees a system is clean.
The full guide, with every source linked and dated, is on our blog: https://www.cloudekhosting.com/blog/php2shell-patch-php-and-check-for-web-shells.html
Top comments (0)