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

Both stem from the same behavior. When a request ends abnormally, most often from an out-of-memory condition, PHP can free the request's heap while internal bookkeeping still points at it. The worker process survives and handles the next request carrying that corrupted state.

Why can a fully updated site still be exposed?

The bugs sit below your application. Neither flaw needs authentication or a bug in your code, and on Apache mod_php an exploit can fire before any application code runs. PHP-FPM is also affected, but exploitation there depends more on the application. Calif reported pre-authentication code execution in its lab against specific versions of WordPress, Drupal, Joomla, and Magento, but exploitation doesn't depend on those platforms.

Which versions are affected, and which are fixed?

Every version from 5.4 through 8.5.11 is affected. Fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 7.4, 8.0, and 8.1 got minimal source backports, not releases, so prefer a build from your Linux distribution or LTS vendor. Anything older has no fix from the PHP project. PHP 8.2 reaches end of life on December 31, 2026, so plan the move to 8.3 or later now.

Which setups are most at risk?

PHP considers every web-serving installation at risk, including PHP-FPM, php-cgi, lsphp, FrankenPHP, and LiteSpeed. Apache mod_php is the highest risk, because a demonstrated exploit fires before any application code runs. Start there with anything internet-facing.

How many internet-facing PHP hosts are there?

A lot. A Shodan search for "php" on October 22, 2026 returned about 3.0 million results, led by the United States, China, Japan, Germany, and Indonesia. Treat that as a measure of how widely PHP is exposed, not of how many hosts are vulnerable. The count includes patched systems and services that only show PHP signs in their banners, and it can't tell you which build is actually serving traffic.

Shodan search for "php", October 22, 2026. Darker shading means more results.

Is it being exploited?

Yes, and the picture has moved since the first reports. Amazon Threat Intelligence recorded an attempt on October 17, four days before disclosure, and says exploitation is now broad. Cloudflare reported early attacks as well. Details leaked on October 20. The August 19 date in some write-ups is when researchers privately found the bugs, not when attacks began. No threat actor has been publicly attributed.

Is there a public proof of concept?

Yes. Multiple exploits have been published. Treat any public exploit code as untrusted, since it is sometimes laced with malware. If you test one yourself, do it only in an isolated lab, never on production systems or from your work network.

What should I do first?

Patch first. Use mitigations only if you cannot patch today. In order:

I can't patch today. What can I do?

These are stopgaps that close known paths only.

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool, or server config, not through ini_set() or .user.ini. Keep upload_max_filesize below post_max_size. PHP's guidance suggests a post_max_size of 8M, or 32M if uploads are required.

• On PHP 8.5, also set fatal_error_backtraces=0.

• Enforce request size, field-count, and multipart-part limits at the web server or proxy, including for requests without a usable Content-Length.

• Remove invalid or deprecated per-request INI settings that emit early diagnostics, and fix attacker-reachable fatal errors and timeouts.

Are there mitigations I should avoid?

Yes. Don't use RLIMIT_AS or RLIMIT_DATA as a memory boundary, because they can trigger the vulnerable allocation failure. Use a container or cgroup limit that kills only the affected worker. Also be careful with memory_limit=-1. It doesn't stop an allocation failure from reaching the vulnerable path. It also removes the "Allowed memory size" log signal that several hunts rely on. That second point is an inference, so compensate with other telemetry.

Can my WAF or CDN protect me?

Partly. Cloudflare and Fastly have published managed rules, but these cover known vectors only and won't catch variants. For custom rules, match on multipart part headers so uploaded file contents never trigger them, and block three shapes no legitimate client sends: a PHPSESSID form field, a PHP open tag in a filename (full and short echo tags only), and serialized-object syntax in a filename. Log PHP_SESSION_UPLOAD_PROGRESS but don't block it, since it's the legitimate progress-bar mechanism. These rules stop the write to the session file but not a later local file inclusion read, so purge session.save_path as part of the rollout.

How do I know if I was compromised?

Start your window no later than October 17, 2026, and go further back if logs allow. Look for:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, malformed PHPSESSID response cookies, and unexplained worker churn.
• PHP Fatal errors containing "tried to allocate" and "in Unknown on line 0". This is a high-priority lead, not proof, since other vendors note it isn't specific to PHP2Shell. Correlate it with oversized POSTs, connection resets, and worker crashes.
• POSTs of 1,000,000 bytes or more. That's a starting heuristic that depends on the target's memory_limit. Add a burst rule of ten or more from one source in ten minutes.
• Shells spawned by apache2, httpd, nginx, lighttpd, caddy, php-cgi, php-fpm, lsphp, or frankenphp, and on Windows by php-cgi.exe or httpd.exe. Don't limit the user list to apache, www-data, and nginx.
• New files in /tmp, /dev/shm, /var/tmp, or web-writable directories, outbound connections on odd ports, and AH00052 child-exit entries in Apache logs.
• Persistence: changed SSH authorized_keys, new cron entries for the web user, and unfamiliar PHP files in web roots.

Are there known indicators of compromise?

Amazon Threat Intelligence published six IP addresses seen targeting its MadPot honeypots. The list includes shared anonymization infrastructure that isn't exclusive to this activity, so investigate any hits in your logs rather than blocking the addresses outright.

Do I need to rotate credentials?

Yes, for any exposed host. Memory disclosure can leak passwords, session tokens, API keys, and certificates from other users' requests. Rotate credentials, API keys, certificates, and session secrets, and invalidate active sessions. Do it after patching so new secrets aren't exposed too, and start with internet-facing mod_php servers.

How can I find which of my assets are affected without running a scan?

Scanning has gaps for this kind of flaw. A scan only sees what it can reach, and PHP is often buried in container images, hosting panels, and appliances, where the php -v version may not match what serves traffic. Hive Pro's scanless technology predicts which of your assets are impacted by CVE-2026-109618 and CVE-2026-109619 without needing to scan them. That gives you a prioritized list quickly, so you can start with internet-facing mod_php servers while credentialed scans are still being scheduled. Treat the prediction as a starting point, and confirm the live PHP build on each flagged asset against the vendor changelog before you close it out.

Hive Pro Uni5 Xposure platform: PHP2Shell advisory with predicted impacted assets.

What's the last step once everything is patched?

Roll back emergency settings and restore a sensible finite memory_limit. Re-check exploitation reporting, which is still changing, and update your hunt if the picture shifts.