Threat Intel · 31 Oct 2026

PHP2Shell (CVE-2026-109618, CVE-2026-109619): patch PHP now

Two memory-safety bugs in the PHP engine allow unauthenticated remote code execution through ordinary web requests. Exploitation started within hours of disclosure and CISA has added both to KEV. What is affected, what to patch and how to hunt.

← Threat Intel / Vulnerability

At a glance

ItemDetail
CVEsCVE-2026-109618, CVE-2026-109619 ("PHP2Shell")
ComponentThe PHP engine itself, not a framework or plugin
ImpactUnauthenticated remote code execution; worker memory disclosure (passwords, tokens, keys)
SeverityCVSS 4.0 9.2 (both)
AffectedPHP serving web requests: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP. Vulnerable code dates back to PHP 5.4 (2012)
Fixed in8.5.12, 8.4.27, 8.3.36, 8.2.35
ExploitationMass scanning within an hour of disclosure; working shells on honeypots; used against PAN-OS management interfaces chained with a Linux privilege escalation
Disclosed20–21 October 2026 (PHP security release)

What is wrong

Both bugs sit in how PHP recovers from fatal conditions in the middle of a request:

  • CVE-2026-109618: when PHP runs out of memory part-way through an operation, the request is abandoned in a half-initialised state, and shutdown code later works on that invalid memory.
  • CVE-2026-109619: after a fatal error, global state belonging to the request is freed but still referenced. A later request handled by the same worker reads the stale memory (a use-after-free). One documented path goes through the session upload progress feature.

Because the flaw is in the engine, every PHP application is in scope: WordPress, Drupal, Laravel, Magento, custom code, and appliances that embed PHP for their web interface. Exploitability depends on configuration, and Apache mod_php is the most urgent case.

Who is affected

  • Any server running PHP for web requests on a version older than the fixed releases above.
  • End-of-life branches (5.4 to 8.1) are the bigger problem. Qualys found that about 71% of PHP installations with a known version run unsupported branches. PHP published limited source backports for 7.4, 8.0 and 8.1, but most of these systems will only be fixed by a distribution package or an upgrade.
  • Appliances and hosted panels that bundle PHP (firewall and VPN management interfaces, NAS devices, control panels). Palo Alto Networks confirmed exploitation against internet-exposed PAN-OS management interfaces.
  • Distribution packages may keep an older version number with the fix backported. Check your vendor's advisory, not just php -v.

What to do

1. Patch (the only complete fix)

  1. Find every PHP runtime: servers, containers, base images, appliances and shared hosting.
  2. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's fixed package (for example Ubuntu USN-8948-1).
  3. Restart every service that loads PHP (Apache, PHP-FPM pools, LiteSpeed). The old code stays in memory until you do.
  4. Rebuild container images and redeploy. Pinned base images keep shipping the vulnerable build.
  5. For appliances, apply the vendor's fix and take management interfaces off the internet.

2. If you cannot patch today

These reduce exposure only. Set them administratively (php.ini, FPM pool, server config); ini_set() and .user.ini are not enough.

  • Disable session upload progress: session.upload_progress.enabled = 0, then restart workers.
  • On PHP 8.5, set fatal_error_backtraces = 0.
  • Tighten request limits: post_max_size (8M without uploads, 32M with), upload_max_filesize below it, lower max_input_nesting_level and max_file_uploads, and enforce body, header and multipart limits at the proxy or WAF. Block multipart requests where the site does not take uploads.
  • For PHP-FPM, consider pm.max_requests = 1 if performance allows, so a poisoned worker is not reused.
  • Put a WAF or IPS rule in front (Palo Alto Networks and other security vendors shipped PHP2Shell signatures from 20–21 October), or restrict access to the site until it is patched.

3. Hunt for compromise

Exploitation started before most organisations patched, so check servers that were exposed after 20 October:

  • Process lineage: a web server or PHP worker (apache2, httpd, php-fpm, php-cgi, lsphp, w3wp) spawning sh, bash, cmd.exe, powershell, curl, wget, nc or reconnaissance commands (id, whoami, uname).
  • Files: new PHP files in upload, cache or temp directories; recently modified .htaccess; executables in /tmp, /dev/shm or /var/tmp.
  • Persistence: new cron entries, authorized_keys changes, new systemd units or local accounts.
  • Credential access: reads of .env, wp-config.php and other config files, or calls to cloud metadata (169.254.169.254) from the web server.
  • Logs: bursts of large multipart POST requests, PHP-FPM workers exiting on signal 11 (segfault) or memory-limit errors, and repeated requests to the same endpoint from rotating addresses. Scanning has been deliberately low-volume, so rate-based alerts may miss it.

If you find signs of compromise, rotate every secret the server could read (database passwords, API keys, cloud credentials, session secrets). Memory disclosure alone can leak them, even without a shell.

How Kage can help

  • Exposure check: we identify internet-facing PHP and appliances across your estate and confirm which are vulnerable.
  • Compromise assessment: if a server was exposed, our incident response team checks for web shells, persistence and credential theft.
  • Monitoring: our threat intelligence service watches for your hosts appearing in scanning and exploitation activity.

References