Now Detecting: CVE-2026-109618/CVE-2026-109619 (php2shell)

Update, 21 October 2026: PHP has released fixes. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now and restart every PHP worker. Exploit code is public and attacks have been reported in the wild.

Two critical flaws in the PHP interpreter itself, dubbed PHP2Shell, may let remote attackers execute code on any server running PHP. Details leaked ahead of the embargo, fixes shipped on the 21st of October, and we were already detecting exposed targets before the fix was released.

What's the vulnerability?

CVE-2026-109618 and CVE-2026-109619 are two unauthenticated remote code execution vulnerabilities in PHP core. PHP rates both CVSS v4.0 9.2. Both are use-after-free bugs triggered by crafted HTTP requests, before any application code runs.

  • CVE-2026-109618, RCE via out-of-memory corruption. PHP uses longjmp() to bail out of out-of-memory errors. A crafted multipart request can exhaust memory during request startup, before state is fully initialized, and request shutdown then reads the corrupted state.
  • CVE-2026-109619, RCE via stale global state. A worker keeps global state (errors, session, objects) that points to memory owned by one request. A fatal error leaves that pointer dangling, and the next request on the same worker uses it. Confirmed paths include session upload progress, which is on by default and needs no session_start(), and PHP 8.5's fatal_error_backtraces.

Every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP says the risk is highest for mod_php (php.net advisory). Because the bugs sit in the interpreter, WordPress, Drupal, Magento, Laravel and custom code are all in scope.

The flaws were reported by researchers from Calif, Wiz Research and OpenAI.

Which versions are affected?

PHP will publish the exact affected and fixed versions with the release. Public reporting so far suggests:

  • All PHP versions from PHP 5 onward may be affected (unconfirmed by PHP)
  • Fixes are coming only for the supported branches: 8.2, 8.3, 8.4 and 8.5
  • PHP 8.1 and older are end-of-life and will not receive a fix

The latest releases before the patch are 8.5.11, 8.4.26, 8.3.35 and 8.2.34. Mallory counted roughly 884,000 internet-facing hosts advertising PHP 8.1 or older, which will stay exposed after today (The Hacker News).

What should you do?

Patch now. In PHP's words, "there are no complete mitigations, updating is the only safe choice" (php.net advisory).

  1. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package. Cover containers, base images, shared hosting and staging hosts too.
  2. Restart every PHP worker (PHP-FPM pools, Apache, FrankenPHP) so no process keeps running the old binary.
  3. Deal with end-of-life runtimes. PHP 8.1 and older get no official fix. Migrate to a supported branch, use a vendor LTS build, or take them off the internet.

If you cannot patch right away, these settings reduce exposure but do not fix the flaws (CVE-2026-109618, CVE-2026-109619):

  • Set session.upload_progress.enabled=0 in php.ini or the pool config, not through ini_set() or .user.ini, and restart all workers
  • On PHP 8.5, set fatal_error_backtraces=0
  • Set memory_limit=-1 so applications cannot override it, with a low post_max_size (8M without uploads, 32M with) and upload_max_filesize below it, enforced at the frontend too
  • Block multipart/form-data at the WAF or reverse proxy if the application does not need uploads, and turn on your WAF vendor's PHP2Shell rules
  • Alert on php-fpm, php-cgi, httpd or apache2 spawning shells, interpreters or download tools such as curl and wget

If an internet-facing server ran a vulnerable version after 20 October, check it for compromise. Look for web shells and unexpected child processes, then rotate the credentials it held: database passwords, API keys, application secrets and cloud tokens.

How Ethiack helps

Ethiack's continuous testing now detects php2shell across your attack surface. We identify every internet-facing PHP runtime you expose, including hosts outside your known inventory, and flag those still running vulnerable or end-of-life versions.

As technical details and fixed versions become public, we validate which assets are actually exploitable, so your team can patch the right systems first.

References

Early signal first detected by Ethiack Zero. Validate your exposure before attackers do. Try Ethiack: 30-day free trial, no commitment.

Validate your exposure

before attackers do.

30-day free trial. No commitment.

def hello(self): print("We are ethical hackers")

class Ethiack: def continuous_vulnerability_discovery(self: Ethiack): self.scan_attack_surface() self.report_all_findings() def proof_of_exploit_validation(self: Ethiack): self.simulate_attack() self.confirm_exploitability() self.validate_impact()

while time.time() < math.inf: ethiack.map_attack_surface() ethiack.discover_vulnerabilities() ethiack.validate_exploits() ethiack.generate_mitigations() ethiack.calculate_risk() ethiack.notify_users() log.success("✓ Iteration complete")

ISO27001

Compliant

Activate AI penTesting

Console.log
001
 
Ethiack — Autonomous Ethical Hacking for continuous security Continuous Attack Surface Management & Testing