Opening soon

PHP2Shell PHP Security Update: Check, Restart, Automate

Updated October 30, 2026 · 9 min read

On October 21, 2026, around 14:00 UTC, the PHP project shipped security releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix CVE-2026-109618 and CVE-2026-109619, two flaws rated CVSS 9.2 that can let an attacker run code without logging in. The PHP 8.4.27 release notes say: “There are no complete mitigations, updating is the only safe choice.”

PHP gave advance notice on October 20, as Laravel News reported. The Dutch NCSC calls the pair PHP2Shell and keeps a public tracker of affected vendor products. If you updated PHP but never restarted it, your site may still run the old code. Below is how to check, and how to set up a patch routine that runs whether or not anyone remembers it.

What has happened since the fix shipped?

Since the release, exploit code for CVE-2026-109618 has been posted publicly and, according to Syhunt, PHP has published a further advisory. One third-party group also reports attacks.

  • October 23, 2026: according to the Syhunt repository below, PHP published an informational advisory for a separate, configuration-dependent issue, CVE-2026-115560, in session upload progress.
  • October 24, 2026: the defensive repository Syhunt php2shell-protection reports exploitation in the wild consistent with CVE-2026-109618 against unpatched PHP. PHP and the CERTs had not confirmed this when we wrote this article.
  • After the release: a public proof-of-concept exploit for CVE-2026-109618 was posted on GitHub (eness/php2shell PoC), so treat exploit code as public and patch now. Do not run it against any site you do not own.

Why does patch speed matter more now?

AI tools help defenders and attackers find serious bugs in larger numbers. More of those bugs lead to code execution. The gap between disclosure and attack can be a few days.

On September 30, 2026, Google Threat Intelligence Group reported that 141 vulnerabilities were exploited from January to August 2026, against 127 in all of 2025. It also reported, as SecurityWeek summarized, that monthly disclosures doubled in 2026. Half of likely AI-discovered flaws led to remote code execution, against 26% of the rest, Help Net Security reported. Attackers exploited one flaw found by an AI research agent within four days of disclosure.

Keep this in proportion. GTIG calls exploitation of AI-found flaws an early indicator, not an established trend. VulnCheck counted 1,061 vulnerabilities attributed to AI-assisted discovery, and 14 of them (1.3%) were confirmed exploited. No source says PHP2Shell itself was found with AI. Still, a critical fix in the language behind WordPress should be installed and running within days. Waiting for the next quarterly cleanup leaves weeks of exposure.

Which PHP build does your site really run?

Check the PHP that serves web pages, not only the command line. They can differ. Then compare it with the fixed releases or your distribution's security notice.

  1. WordPress: go to Tools > Site Health > Info > Server and read the PHP version.
  2. On the server (Linux): php -v shows the command-line PHP. On Debian and Ubuntu, /usr/sbin/php-fpm8.3 -v shows the web-facing build (the number in the name varies). On AlmaLinux, use /usr/sbin/php-fpm -v.
  3. Compare: upstream builds need 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later on the same branch.
  4. Distribution packages: Ubuntu, Debian and AlmaLinux may backport fixes without changing the version number. Check the changelog for both CVE IDs instead. Debian and Ubuntu: apt changelog php8.3-fpm | head -n 40. AlmaLinux: rpm -q --changelog php-fpm | head -n 40. Package names vary.
  5. From your laptop (macOS or Linux): curl -sI https://example.com | grep -i '^x-powered-by' sometimes shows the version. Many servers hide it, so an empty result proves nothing.

If your branch no longer gets security releases, it got no fix at all. Plan a move to a supported branch: back up, test a staging copy, then switch.

Why can your site still run the old code after an update?

PHP-FPM workers keep the old code in memory until they restart. Installing the package is half the job. Restart PHP-FPM or the web server after every PHP update.

  • Debian and Ubuntu: sudo systemctl restart php8.3-fpm (service name varies).
  • AlmaLinux: sudo systemctl restart php-fpm.
  • Apache with mod_php: sudo systemctl restart apache2 on Debian and Ubuntu, sudo systemctl restart httpd on AlmaLinux.

To list services still running old libraries, use sudo needrestart -r l on Debian and Ubuntu (package needrestart) or sudo needs-restarting -s on AlmaLinux (package dnf-utils).

What if your site is on shared or managed hosting?

Your host installs PHP, so your job is to confirm the fix, not apply it. Check the PHP version in your control panel and in WordPress Site Health. If you cannot confirm the fix, ask.

Open a ticket and ask: “Are the October 21, 2026, PHP security fixes for CVE-2026-109618 and CVE-2026-109619 installed and loaded for my site?” At least one host disabled session.upload_progress.enabled overnight as a stopgap before the fix, Paid Memberships Pro reported. That is not a fix: PHP states there is no complete mitigation.

How do you make patching run on its own on a VPS?

Turn on automatic security updates on the server itself, and send their reports to a mailbox or chat someone reads. Never rely on a reminder on a laptop that sleeps.

Debian and Ubuntu

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

In /etc/apt/apt.conf.d/50unattended-upgrades, set Unattended-Upgrade::Mail "[email protected]"; and Unattended-Upgrade::MailReport "on-change";. Reports need a working mail program and relay, for example bsd-mailx with msmtp-mta pointed at your mail provider's authenticated submission port. Send a test with echo test | mail -s 'update report test' [email protected] and confirm it arrives. Then run sudo unattended-upgrade --dry-run --debug once.

AlmaLinux

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

In /etc/dnf/automatic.conf, set upgrade_type = security, apply_updates = yes, emit_via = email and email_to = [email protected]. This also needs a working local mail relay; send a test message and confirm delivery.

Neither tool always restarts every PHP service. Add the restart check from the next section to your routine. Also subscribe a monitored inbox or team chat to PHP announcements on php.net and your distribution's security notices. The October 20 notice gave a day's warning.

What can you copy and run today?

Use this checklist and script on Debian or Ubuntu servers. It lists installed PHP-FPM packages, checks their changelogs for both CVE IDs, and shows when each PHP-FPM service last started.

#!/bin/sh
# php-fix-check.sh - Debian/Ubuntu only. Run on the server: sudo sh php-fix-check.sh
for pkg in $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php*-fpm' 2>/dev/null | awk '$1=="ii"{print $2}'); do
  echo "$pkg $(dpkg-query -W -f='${Version}' "$pkg")"
  for cve in CVE-2026-109618 CVE-2026-109619; do
    if apt changelog "$pkg" 2>/dev/null | grep -q "$cve"; then
      echo "  $cve listed as fixed"
    else
      echo "  $cve NOT found: check your vendor's security notice"
    fi
  done
done
echo "Last PHP package changes:"
grep ' upgrade php' /var/log/dpkg.log | tail -n 5
echo "PHP-FPM service start times (each must be later than the last PHP upgrade above):"
for unit in $(systemctl list-units --type=service --plain --no-legend 'php*-fpm*' | awk '{print $1}'); do
  echo "  $unit $(systemctl show -p ActiveEnterTimestamp --value "$unit")"
done

Packages from third-party repositories may not publish changelogs to apt changelog; check that repository's notes instead. If you schedule this script, run it from cron on the server with [email protected] set and the mail relay tested.

Checklist:

  1. Take a backup or snapshot.
  2. Update PHP packages.
  3. Restart PHP-FPM or the web server.
  4. Confirm the fixed build or changelog entry for both CVEs.
  5. Confirm update reports reach a person.
  6. Review access logs for unusual POST requests to PHP pages since October 21, for example sudo grep '"POST ' /var/log/nginx/access.log | less on Linux with nginx. If anything looks wrong, restore a clean backup and rotate passwords and keys.

How does this work at PomeloHost?

A PomeloHost KVM VPS gives you full root access, and it is self-managed unless you add the managed option. You can run Ubuntu, Debian, AlmaLinux or any system from your own ISO. Outbound port 25 is closed by default and may be opened on request after review, so send update reports through your provider's submission port or a chat webhook. Snapshots are available before you update. A weekly backup stored outside the data center is included, but it does not replace your own backups. If SSH stops working after an update, the browser console still works. Ticket support runs 24/7 and is answered by people.

What should you do this week?

Confirm the fixed PHP build on every site, and restart PHP so it loads. Then make updates run on the server and report to a person. When the next critical PHP release ships, it gets installed even in a week when nobody is reading security news.

Frequently asked questions

Does the PHP version in my browser headers prove my site is patched?

No. Many servers hide the version header, and distribution packages often backport fixes without changing the number. The header also says nothing about whether PHP-FPM restarted. Check the package changelog for CVE-2026-109618 and CVE-2026-109619 on the server, or ask your host to confirm the fix is installed and loaded.

Will turning off session upload progress protect my site?

Not fully. At least one host disabled session.upload_progress.enabled overnight as a stopgap before the fix shipped. PHP states there is no complete mitigation and that updating is the only safe choice. Treat the setting as a short bridge at most, then install the fixed release and restart PHP-FPM.

Was PHP2Shell found with AI?

No source we used says so. Google's threat intelligence team reported broader trends: more disclosures, more AI-found flaws leading to code execution, and one AI-found flaw attacked within four days. VulnCheck found only 1.3% of AI-attributed flaws confirmed exploited. These trends explain why patch speed matters. They say nothing about how PHP2Shell was found.

Can I schedule the patch check on my laptop?

No. A laptop sleeps, travels and misses runs, so the check silently stops. Run it with cron on the server itself, set MAILTO to a mailbox someone reads, and send a test message first. A chat webhook works too, as long as a person actually watches the channel.