PHP CVE-2026-109618 and CVE-2026-109619: How to Check, Patch and Protect Your Server

Introduction

On 21 October 2026 the PHP project released emergency security updates for two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619. Each one is rated 9.2 out of 10 under CVSS v4.0, and each can let an attacker on the internet run code on a web server without logging in. The pair of bugs has been nicknamed php2shell by researchers.

PHP runs a large share of the web, including WordPress, Joomla, Drupal, Magento, and most hosting control panels, so this affects far more than developers. The risk is not limited to one application. The flaws sit in the PHP engine itself, which means updating WordPress, a plugin, or a theme does not fix them. Only a patched PHP does.

This guide from BDIX HOST explains what the vulnerabilities are in plain language, who is exposed, which versions are fixed, and exactly how to find, patch, and verify every PHP runtime on a server. It also covers temporary measures and their limits, how to check for signs of compromise, and what WordPress site owners and hosting customers should do.

Key takeaways

• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Update within your current branch.
• Who is at risk: every PHP install that serves web requests (Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed). PHP calls mod_php the highest risk.
• No login needed. An unauthenticated request can reach the vulnerable code before your application runs.
• Patching is the only complete fix. The configuration workarounds reduce exposure but do not make a server safe.
• Check every runtime. A server often has several PHP versions and handlers, and php -v shows only one.
• Restart after updating. Running workers keep the old code in memory until they are restarted.
• Old branches get no official fix. PHP 8.1 and older are unsupported, so plan a migration or get a vendor backport.
• Treat exploitation as likely. Reports differ on whether attacks have been confirmed, but security firms expect them.

What Happened: Timeline of the php2shell Disclosure

The flaws became public sooner than planned. Details of the early leak vary slightly between reports, so the table sticks to points that several sources agree on.

Date (2026)	Event
20 October	A post claiming two critical PHP flaws were about to be disclosed appeared on Hacker News and was removed, but screenshots spread. The CVE identifiers circulated before the official advisory.
20 October	The PHP security team published an advance notice of a security release for 21 October at 14:00 UTC. The PHP Foundation said it brought the release forward a day after the identifiers leaked.
21 October	PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Rapid7, Tenable, Datadog, Sansec, and Google Cloud published analyses the same day.
21 October	Researchers at Calif and Wiz published technical details. Wiz showed unauthenticated code execution against WordPress, Drupal, and Joomla, plus a memory disclosure path that could expose secrets.
21 October	CERT-EU published advisory 2026-018. Cloudflare rolled out stopgap WAF rules for all customers.
21 to 22 October	Reports on attacks differ. watchTowr reported exploitation attempts against both flaws on its honeypots, Cloudflare said early attacks were emerging, and Huntress saw none across its partners as of 21 October.

The PHP Foundation also noted that the identifiers that leaked first carried an incorrect score of 10.0. The official rating for both is CVSS v4.0 9.2.

One caution: after the leak, exploit code began to circulate online. The PHP Foundation said it did not identify functional exploits at release time, and unverified exploit code can itself contain malware. Do not download or run it on production systems.

The Two Vulnerabilities Explained

Both bugs are memory-safety flaws in how PHP handles a request, which is why they work regardless of what your website does. The table compares them, and the paragraphs below explain each without needing a security background.

	CVE-2026-109618	CVE-2026-109619
Short name	RCE via out-of-memory (OOM) corruption	RCE via stale global state (use-after-free)
Advisory	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
CVSS v4.0	9.2 Critical	9.2 Critical
Vector	Network, no login, no user interaction (AV:N/PR:N/UI:N)	Network, no login, no user interaction (AV:N/PR:N/UI:N)
Impact	Remote code execution with the web worker’s privileges	Remote code execution, plus memory disclosure
Highest risk setup	Apache mod_php	mod_php and PHP-FPM, through confirmed paths
Needs a prior request?	No, the demonstrated attack works in a single request on mod_php	Yes, a later request on the same worker reuses stale state

CVE-2026-109618: memory corruption when PHP runs out of memory. When PHP cannot get memory it needs, it abandons the request abruptly. If that happens while internal request data is only partly set up, the cleanup routine afterwards treats the half-built data as valid and operates on it. A crafted request, such as a multipart form with the right shape, can push PHP into this state even when it appears to fit the configured limits. On Apache with mod_php, cleanup runs even when startup fails, so the advisory reports a demonstrated attack that works before any application code runs, with default input and memory limits. PHP-FPM ends a worker when startup fails, which blocks that exact sequence, although the advisory says source analysis suggests FPM may still be susceptible after a successful startup. No complete FPM exploit is reported for this one.

CVE-2026-109619: leftover state from an earlier request. A PHP worker handles many requests in a row. Some internal state can keep pointing at memory that was freed at the end of an earlier request. If a fatal error or timeout interrupts cleanup, a later request on the same worker may read that stale pointer before it is reset. The confirmed paths are:

• Session upload progress, which is enabled by default. It can consume stale session state before normal initialization and does not require the application to call session_start(). This path works on both mod_php and PHP-FPM.
• PHP 8.5’s fatal error backtraces, enabled by default, on mod_php.

The FPM route needs three things: an operation that leaves state behind after a successful start, a fatal error, and a follow-up request that reaches the same worker. Running more workers or recycling them lowers the chance per attempt but does not remove the condition.

Why “any PHP script” is exposed. Datadog’s analysis stresses that the vulnerable path runs inside PHP before your code does. A script that only prints a line is just as exposed as a complex application, and application login screens do not help.

Who Is Affected?

In short: almost everyone running PHP on a public web server. PHP’s own advisory says all installations serving web requests are at risk. Reports from Calif and Google Cloud say the affected code path reaches back to PHP 5.4, so every release from 5.4 up to 8.5.11 is vulnerable until patched.

Setup	Exposure
Apache with mod_php	Highest. A demonstrated exploit triggers before application code runs.
PHP-FPM (Nginx or Apache)	Exposed through the session upload progress path of CVE-2026-109619, and possibly after a successful startup for CVE-2026-109618.
php-cgi and FastCGI	In scope per the advisory.
LiteSpeed (lsphp)	In scope per the advisory. Restart lsphp processes after updating.
FrankenPHP	In scope per the advisory.
Command-line scripts only	Not web-reachable, so lower priority, but still update the binary.

What runs on top does not change the answer. Wiz demonstrated unauthenticated code execution against WordPress, Drupal, and Joomla, and Magento stores were flagged by Sansec. The common point is PHP underneath.

Also check places people forget:

• Control panels and hosting stacks: cPanel (EasyApache), CloudLinux alt-PHP, Plesk, DirectAdmin, Webuzo, and aaPanel each manage their own PHP packages.
• Several PHP versions on one server: shared hosting commonly offers 8.1, 8.2, 8.3, and 8.4 side by side, and every one that serves a site needs attention.
• Containers and images: a rebuilt image is needed, since updating the host does not change PHP inside a container.
• Bundled PHP: vendor appliances and Windows software that ship php.exe or php-cgi.exe.

Scale matters too. PHP is used by about 69% of websites whose server-side language is known, according to W3Techs, and estimates of exposed hosts in public reporting range from roughly 1.3 million to more than 1.9 million.

Fixed Versions and End-of-Life Branches

Stay on your current branch and move to its fixed release. You do not need to jump to a newer branch just for this patch.

PHP branch	Vulnerable before	Fixed in	Status
8.5	8.5.12	8.5.12	Supported
8.4	8.4.27	8.4.27	Supported
8.3	8.3.36	8.3.36	Supported
8.2	8.2.35	8.2.35	Security fixes only, ends 31 December 2026
8.1	All	No official fix	End of life. Minimal source backport published for builders only.
8.0 and 7.4	All	No official fix	End of life. Minimal source backport published for builders only.
7.3 and older, down to 5.4	All	No fix	End of life, vulnerable

A few things to keep in mind:

• Distribution packages may not show the upstream number. Ubuntu, Debian, AlmaLinux, and CloudLinux often backport the fix into their own build, so php -v can show an older-looking version that is already patched. Verify with the package changelog (see Step 3), not just the number.
• End-of-life branches are the real problem. PHP 8.1 and older will not get official updates. Options are a vendor or extended-support backport (some distributions and CloudLinux-style providers offer them), building from the minimal source backport, or migrating. Migrate when you can, because the next flaw will face the same situation.
• PHP 8.2 is close to the end. It reaches end of life on 31 December 2026, so 8.3 or 8.4 is the sensible target for any migration you start now.
• Third-party repositories may lag. The volunteer-run Remi repository had no updated packages on release day, and PHP advised switching to distribution packages or building from source until they appear.

Step 1: Find Every PHP Runtime on Your Server

The PHP you see in a terminal is often not the PHP that serves your websites, so build an inventory first.

1. Identify the operating system and control panel

cat /etc/os-release
ls /usr/local/cpanel 2>/dev/null && echo "cPanel found"
ls /opt/cpanel 2>/dev/null | grep ea-php
ls /opt/alt 2>/dev/null | grep php    # CloudLinux alt-PHP

2. Check the default command-line PHP

php -v
php --ini

This shows only the CLI binary. It may differ from what serves websites.

3. List every PHP-FPM service and running PHP process

systemctl list-units --type=service | grep -Ei "php.*fpm"
ps -eo pid,user,etime,cmd | grep -Ei "[p]hp-fpm|[l]sphp|[p]hp-cgi" | head -30

4. List installed PHP packages

# Debian and Ubuntu
dpkg -l | grep -Ei "php|libapache2-mod-php"

# AlmaLinux, Rocky, CloudLinux, cPanel
rpm -qa | grep -Ei "^(php|alt-php|ea-php)"

5. On cPanel, check each EasyApache version separately

for v in /opt/cpanel/ea-php*; do
  echo "== $v"; $v/root/usr/bin/php -v | head -1
done

6. Write down each runtime and what uses it

A simple table avoids missing one. Record the PHP branch, how it is installed (distribution package, EasyApache, alt-PHP, panel build, or source), which handler runs it (mod_php, FPM, lsphp, CGI), and which sites depend on it. In cPanel, WHM’s MultiPHP Manager shows which PHP version each domain uses.

Also look beyond the server itself: containers, staging servers, old test machines, and vendor software that bundles PHP. Rapid7 has published a Velociraptor artifact, Generic.Applications.PHPInventory, that collects PHP versions, binary paths, modules, and running processes across Windows, Linux, and macOS if you manage many machines.

Step 2: Patch PHP on Your Platform

Patch internet-facing systems first. Take a snapshot or backup before big updates, and use a maintenance window for busy servers. Your platform’s package channel decides when a fix becomes available, so if an update does not show the fix yet, check the vendor’s advisory page and try again later rather than assuming you are safe.

cPanel, WHM, and EasyApache 4

# As root: update all EasyApache PHP packages
dnf clean all          # use yum on older systems
dnf update "ea-php*"

# Restart handlers
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

In WHM you can also run Software > EasyApache 4 and review each installed PHP version. If you use LiteSpeed with cPanel, restart it gracefully so lsphp workers reload:

/usr/local/lsws/bin/lswsctrl restart

Check every PHP version in MultiPHP Manager, not just the default one. If a version has no update yet, plan its migration or ask your provider about extended support.

CloudLinux (alt-PHP)

dnf update "alt-php*"      # or: yum update "alt-php*"

Verify each alt-PHP branch your customers use, and watch CloudLinux’s status page for package availability. Restart FPM and the web server afterwards.

Ubuntu and Debian

sudo apt update
sudo apt upgrade
apt-cache policy php8.3-cli php8.3-fpm     # adjust to your PHP version
sudo systemctl restart php8.3-fpm          # or: sudo systemctl restart apache2

Ubuntu and Debian ship their own patched builds, so check their security notices for the exact fixed package number on your release.

AlmaLinux, Rocky Linux, and Fedora

sudo dnf clean metadata
sudo dnf upgrade "php*"
sudo systemctl restart php-fpm     # or: sudo systemctl restart httpd

Plesk

Open Tools & Settings > PHP Settings, identify every PHP handler, and install the vendor’s updates. Verify each handler that serves a site.

Webuzo

/usr/local/emps/bin/php /usr/local/webuzo/cli.php --emps update

aaPanel

Open App Store, click Update App List, update each installed PHP version, then restart PHP and test the sites.

DirectAdmin

Follow the vendor’s guidance for your install method, including CustomBuild, install patched builds, and restart services. Avoid unverified manual edits to version files.

Docker, Kubernetes, and cloud runtimes

Rebuild images from a patched PHP base image and redeploy. Updating the host does not change PHP inside a container. On managed platforms such as Google App Engine and Cloud Run, supported runtimes patch automatically, but custom runtimes and unsupported branches must be rebuilt or upgraded.

Manual or custom builds

Package managers will not update them. Obtain a security-fixed source release (or the vendor build), rebuild carefully with the same options, replace the old binary, and restart every worker.

Unsupported versions (PHP 8.1 and older)

Check whether your operating system vendor or a commercial provider backports the fix. If not, move the site to 8.3 or 8.4 as soon as it is tested, and until then restrict access to the site (see Temporary Mitigations).

Step 3: Restart Everything and Verify the Fix

An update that installed successfully does not prove you are safe. Long-running workers keep the old code in memory until they restart, and a distribution may have patched PHP without changing the visible version number.

1. Restart all PHP workers and the web server

Restart PHP-FPM pools, lsphp, Apache, Nginx, and LiteSpeed as relevant. On a busy server, use a graceful reload where your stack supports it, then confirm the old processes are gone:

ps -eo pid,lstart,cmd | grep -Ei "[p]hp-fpm|[l]sphp|[h]ttpd|[a]pache2" | head

Process start times should be after your update.

2. Find processes still running deleted old files

sudo lsof 2>/dev/null | grep -i "DEL.*php" | head
# Debian and Ubuntu: also run  sudo needrestart

Any hit means a process is still using a replaced PHP binary or library, and needs a restart.

3. Confirm the fix landed, using the changelog

For distribution and vendor builds, the package changelog names the CVE even when the version looks old:

# Debian and Ubuntu
apt changelog php8.3-fpm | grep -m3 -E "CVE-2026-10961[89]"

# AlmaLinux, Rocky, CloudLinux, cPanel
rpm -q --changelog php-fpm | grep -m3 -E "CVE-2026-10961[89]"
rpm -q --changelog ea-php83-php-fpm | grep -m3 -E "CVE-2026-10961[89]"

For upstream or source builds, php -v should report at least 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

4. Check the runtime that serves each site, not only the CLI

Use a temporary file that prints the version, load it through the site’s own URL, then delete it immediately. Or use your panel: in cPanel, MultiPHP Manager shows each domain’s version, and each version’s binary is under /opt/cpanel/ea-phpXX/. Do not leave version-printing files on a live site.

5. Test the sites

Log in, upload a file, run a checkout or form, and test background jobs and database connections. Check service logs for new errors after the restart.

6. Confirm with a scanner if you have one

Vulnerability scanners were updated for these CVEs. Tenable, for example, published plugins that detect the affected PHP versions. A credentialed or agent scan gives the most reliable result.

Temporary Mitigations, and Why They Are Not Enough

If you cannot patch right now, for example because a package is not yet available for your branch, these steps reduce exposure. The PHP project states clearly that they “do not make an installation safe.” Use them to buy time, then patch.

Setting or control	Targets	How to apply	Limits
session.upload_progress.enabled = 0	CVE-2026-109619 (session path)	Set in php.ini, an FPM pool, or server config that applies before request parsing. Do not use ini_set() or .user.ini. Restart all workers.	Blocks only the confirmed session paths. Datadog warns it does not protect against these flaws on its own. Apps that use upload progress will lose it.
fatal_error_backtraces = 0	CVE-2026-109619 (PHP 8.5 backtrace path)	Same as above, PHP 8.5 only.	Blocks the confirmed backtrace path only.
memory_limit = -1, set so apps cannot override it (php_admin_value)	CVE-2026-109618 (out-of-memory trigger)	FPM pool or Apache config, then restart.	Removes the memory ceiling, so a single request can exhaust the server. Use a container or cgroup limit that kills only the affected worker as an availability boundary.
Lower post_max_size (8M without uploads, 32M with) and keep upload_max_filesize below it	CVE-2026-109618	php.ini or pool config.	Can break legitimate large uploads.
Frontend limits on request size, field count, multipart parts, headers, and nesting depth	CVE-2026-109618	Web server, proxy, or WAF. Must also cover requests with no usable Content-Length.	Needs careful tuning.
Block multipart/form-data at the frontend	Both, through upload paths	Only if the site does not use form uploads. Sansec lists this among emergency options.	Breaks uploads, comment forms with attachments, and many plugins.
Cloud WAF rules (for example Cloudflare’s stopgap rules)	Known exploit patterns	Route traffic through the WAF.	Cloudflare itself calls them a stopgap, and they cover only traffic that passes through them.

Two more warnings from the advisory:

• Do not use RLIMIT_AS or RLIMIT_DATA to cap memory. They can trigger the exact allocation failure that causes the bug.
• Hiding errors does not help. Settings like error_reporting, display_errors, log_errors, or the @ operator do not stop stale-state access, and an empty error log does not prove a server is safe.

For servers that cannot be patched (old PHP, vendor appliances), CERT-EU recommends isolating internet-facing applications until patches are applied and verified. In practice that means putting them behind a VPN, an IP allowlist, or a WAF, or taking them offline.

Here is an example of an administrative pool override, which application code cannot undo. Adapt the numbers to your needs and restart FPM:

; /etc/php/8.3/fpm/pool.d/www.conf  (path differs by platform)
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 7M

Check Whether You Were Already Compromised

Patching closes the door but does not remove someone who already walked through. Because the flaws were public and exploit code circulated from 21 October, check any server that was unpatched and internet-facing. No confirmed indicators of compromise (IP addresses, file hashes, payload strings) had been published when this was written, so the useful approach is to look for behavior rather than signatures.

1. PHP workers that spawn shells or tools. This is the strongest signal. Web workers (php-fpm, lsphp, php-cgi, httpd, apache2) should almost never start a shell or a download tool. Datadog and Huntress both point to this behavior. A quick live check:

ps -eo pid,ppid,user,etime,cmd --forest | grep -E "php-fpm|lsphp|php-cgi|httpd|apache2" -A2 | grep -E "sh -c|/bin/(ba)?sh|curl|wget|nc |ncat|python|perl|/dev/tcp"

If you run an endpoint or workload security tool, alert on a PHP process that spawns sh, bash, python, perl, curl, wget, or nc. Huntress also lists command lines containing /dev/tcp/, fsockopen, or mkfifo, and reconnaissance commands such as whoami, id, and uname -a run from the web server account.

2. New or changed PHP files. Webshells are the usual follow-up. Look for PHP files changed since 20 October, and especially PHP in upload and cache folders:

find /home/*/public_html /var/www -type f -name "*.php" -newermt "2026-10-20" 2>/dev/null | head -100
find /home/*/public_html/wp-content/uploads -type f -name "*.php" 2>/dev/null

PHP files inside wp-content/uploads are a red flag on WordPress sites.

3. Persistence. Check for new cron jobs, scheduled tasks, SSH keys, and accounts:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u $u 2>/dev/null | sed "s/^/$u: /"; done
last -n 20
find /home -name authorized_keys -newermt "2026-10-20" 2>/dev/null

4. Logs. Look for bursts of Allowed memory size ... exhausted errors during request startup, large or repeated POST requests to a single script, and multipart requests from one address. Datadog lists large form submissions and memory exhaustion during initialization as the main log patterns. An empty log proves nothing, because exploitation may not leave an error.

5. Run your malware scanner (for example Imunify360, ClamAV, or Maldet) over the web roots after patching.

If you find signs of compromise: isolate the server from the network, preserve the web server and PHP logs and a disk image before changing things, then look for webshells, new files in web roots, new users, and new scheduled tasks. The memory disclosure path means passwords, API keys, tokens, and certificates held by PHP may have been exposed, so rotate database passwords, API keys, WordPress salts, and SSH keys, and restore from a known-clean backup rather than trying to clean a rooted server.

What WordPress Owners and Hosting Customers Should Do

If you run WordPress, Joomla, Drupal, or Magento on shared or managed hosting. You usually cannot patch PHP yourself, because your host controls it. Do these things instead:

1. Ask your host in writing whether PHP has been updated to a fixed version for your branch, and which versions are covered.
2. Check your PHP version in your control panel. In cPanel, open MultiPHP Manager. In WordPress, open Tools > Site Health > Info > Server. Remember that a host’s patched build may keep an older-looking number.
3. Move off unsupported PHP. If your site runs PHP 8.1 or older, switch to 8.3 or 8.4 in your panel after testing on a staging copy, since it may need plugin or theme updates.
4. Do not assume a WordPress update fixes this. Updating WordPress, plugins, and themes is still good practice, but it does not patch the PHP engine.
5. Keep your own house in order. Remove unused plugins and themes, use strong unique passwords with two-factor login, and keep backups off the server.
6. Watch for odd behavior. Unknown admin users, new PHP files in uploads, redirects, spam pages, or unexpected emails can signal a compromise.
7. Back up now. A recent backup, stored away from the server, is your fastest route to recovery.

If you manage a VPS or dedicated server. You are responsible for the full process in this guide: inventory, patch, restart, verify, and hunt. Managed plans differ, so ask your provider exactly which parts they handle. Unmanaged servers, including those on other providers, are not patched for you.

If you are a reseller or agency. List every client site and its PHP version, update the ones you control, and send clients a short notice explaining what was done and what they need to do. Prioritize e-commerce and login-heavy sites.

If you are a developer. Rebuild container images on a patched base image, pin your PHP version in your build files, and add a check to CI so a vulnerable version cannot ship again. Also fix reachable fatal errors and timeouts in upload and import code, which the PHP advisory lists as ways to trigger stale state.

Hardening Checklist After Patching

Use this list once every runtime is fixed and verified. Tick items as you go.

• Every PHP runtime on every server and container is inventoried and patched.
• All PHP-FPM, lsphp, Apache, Nginx, and LiteSpeed processes were restarted after the update.
• Verification used package changelogs or version checks, not just a successful update command.
• No site is on PHP 8.1 or older without a vendor backport and a migration date.
• PHP 8.2 sites have a plan to reach 8.3 or 8.4 before 31 December 2026.
• Internet-facing systems that cannot be patched are isolated behind a VPN, IP allowlist, or WAF.
• The compromise checks (shell spawning, new PHP files, persistence, logs) were done for every server that was exposed.
• Secrets were rotated where a compromise or memory disclosure is possible: database passwords, API keys, WordPress salts, SSH keys, and certificates.
• Temporary workarounds were reviewed. Keep sensible limits such as post_max_size, and remove ones that break features, once you are patched.
• A web application firewall is in front of public sites and its rules are kept current.
• PHP processes run as separate users per site (PHP-FPM pools, CageFS, or similar) so one compromised site cannot reach another.
• Uploads and cache folders do not execute PHP.
• Backups are recent, stored off the server, and tested.
• Subscribed to PHP’s security announcements and your distribution’s security list.
• A written, repeatable process exists for emergency PHP updates, including who approves them and how restarts are done.

Frequently Asked Questions

What are CVE-2026-109618 and CVE-2026-109619?

They are two critical flaws in the PHP engine, both scored 9.2 under CVSS v4.0. CVE-2026-109618 is memory corruption triggered when PHP runs out of memory. CVE-2026-109619 is a use-after-free caused by stale request state. Either can allow remote code execution without logging in.

What is php2shell?

It is the name researchers gave to the exploit chain that targets these two flaws.

Which PHP versions fix them?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older get no official update, apart from minimal source backports for 7.4, 8.0, and 8.1.

Does updating WordPress fix this?

No. The flaws are in PHP itself, so WordPress, plugin, and theme updates do not address them. Only a patched PHP runtime does.

Is my server vulnerable if I use PHP-FPM instead of mod_php?

PHP considers mod_php the highest risk, but PHP-FPM is also exposed, mainly through the session upload progress path of CVE-2026-109619. Patch both.

Can I just turn off session upload progress?

It blocks the confirmed session paths of CVE-2026-109619 but not other variants, and it does nothing for CVE-2026-109618. Datadog warns it does not protect against these flaws on its own. Treat it as a short-term measure and patch.

php -v shows an older version after I updated. Am I still exposed?

Not necessarily. Distribution and vendor builds often backport the fix without changing the upstream version number. Check the package changelog for the CVE IDs and make sure workers were restarted.

Is it being exploited?

Reports differ and were changing as this was written. watchTowr reported exploitation attempts on its honeypots, Cloudflare said early attacks were emerging, and Huntress saw none on its partner systems as of 21 October. Security firms expect widespread exploitation, so act as though it is happening.

Should I use a public exploit to test my server?

No. Circulating exploit code is unverified and may contain malware. Use a vendor or scanner check, or compare your versions against the fixed releases.

Will a WAF protect me?

A WAF may block known patterns and Cloudflare deployed stopgap rules, but it does not remove the flaw, and it only helps for traffic that passes through it. Patch the PHP runtime.

What if my host controls PHP?

Ask them to confirm in writing that they have installed the fixed version for your PHP branch and restarted services. Switch your site to a supported PHP version in your control panel if you are on 8.1 or older.

Do I need to rotate passwords and keys?

If a server was exposed and unpatched, and you find any sign of compromise, yes. The memory disclosure path can expose secrets held by PHP, so rotate database passwords, API keys, WordPress salts, and SSH keys.

Conclusion

CVE-2026-109618 and CVE-2026-109619 are among the most serious PHP flaws in years because they sit in the engine, need no login, and affect almost every PHP release in use. The path to safety is clear: inventory every PHP runtime, update each to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or a vendor build that carries the fix), restart all workers, and verify through changelogs and real runtime checks. Use the temporary measures only as a bridge, check exposed servers for signs of compromise, and move any PHP 8.1 or older sites to a supported branch. Do the inventory today, patch the internet-facing systems first, and keep this guide as the template for the next emergency update.