PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Critical PHP RCE Flaws, Affected Versions, Fixes and Detection

PHP2Shell is the name given to two critical remote code execution (RCE) vulnerabilities in the PHP engine itself: CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2, both can be triggered by an unauthenticated remote attacker, and both were fixed in an emergency PHP security release on October 21, 2026. Because the bugs live in PHP and not in your application, a fully patched WordPress, Magento or Laravel site can still be exposed if the server's PHP runtime is old.

PHP2Shell at a Glance (TL;DR)

• What: two memory-safety flaws in PHP core that can lead to unauthenticated RCE as the web worker user (for example www-data).
• CVEs: CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Older branches: PHP 7.4, 8.0 and 8.1 have no official release, only minimal source backports. PHP 7.3 and older (including PHP 5) have no fix at all.
• Exploitation: attack attempts were reported in the wild by several vendors (details below), and some sources date the first attempt to October 17, four days before disclosure.
• What to do: update PHP, then restart every PHP worker. Configuration changes are stop-gaps only.

What Is PHP2Shell?

PHP2Shell is the collective name used by researchers and the press for a pair of bugs discovered by researchers at Calif.io, with OpenAI and Wiz also credited by the PHP Foundation. Both flaws share one root cause: when a request ends abnormally, PHP can be left with half-initialized or stale internal state, and later code trusts that state as if it were valid. An attacker who can steer that bad state can turn it into memory corruption and, from there, into code execution.

PHP's own advisory warns that the risk is highest for Apache mod_php, where an unauthenticated request can trigger the attack before any application code runs. That is why application-level logins, firewalls inside the app and "we have no upload form" arguments do not protect you.

The Two Vulnerabilities Explained

A note on accuracy: published write-ups do not label the two bugs identically. Tenable, watchTowr, Datadog and BleepingComputer describe CVE-2026-109618 as the out-of-memory flaw and CVE-2026-109619 as the stale-state use-after-free, while Sansec's summary assigns the mechanisms differently. The original Calif.io write-up describes the shared root cause without mapping each CVE to a single bug. For your response this does not change anything: both are fixed by the same PHP update.

How the attack works at a high level

Datadog Security Labs gives the clearest technical walk-through. For the out-of-memory case, PHP's hash-table insertion for string keys updates its entry counters before it allocates the key copy. If that allocation exceeds memory_limit, PHP aborts and leaves a counted but uninitialized bucket. During request shutdown, PHP destroys $_POST and reads that stale bucket as if it held real PHP values.

For the stale-state case, PHP workers are reused across requests. If a fatal error interrupts state cleanup, or a late diagnostic recreates state after cleanup, a later request can read freed memory. Two confirmed paths are the fatal-error backtrace feature (PHP 8.5 only) and upload processing, where session upload-progress is enabled by default and runs even if the application never calls session_start().

Exploitation is not trivial. The attacker has to size a request so the allocation fails at exactly the right moment, and has to defeat ASLR. Even so, Calif.io reports working pre-authentication RCE against a long list of popular PHP applications, and Datadog notes that a successful attack may still return HTTP 200 and leave the worker running.

Affected and Fixed PHP Versions

Calif.io traces the earliest affected code path back to PHP 5.4.0, released in 2012. Linux distributions and LTS vendors received patches in advance, and they often backport a fix without changing the version number. A version string like 8.1.34 therefore does not tell you whether you are safe. Check your vendor's package changelog for the CVE ID instead.

All PHP runtimes that serve HTTP are in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. Do not forget containers and applications that bundle their own interpreter, since the PHP binary in your CLI may differ from the one your web server runs.

Is PHP2Shell Being Exploited in the Wild?

Reporting on exploitation is moving quickly and sources differ slightly, so here is what is attributed to whom:

• Oct 17: Amazon Threat Intelligence observed an attempt against its MadPot honeypot four days before disclosure, per Tenable's summary. It is unclear how the attacker obtained exploit information. Further attempts on Oct 21 used payloads and infrastructure that Amazon says suggest multiple actors.
• Oct 20: the CVE identifiers leaked on social media before PHP's planned Oct 22 disclosure, and PHP published an advance notice. The leak claimed a CVSS score of 10.0, which the PHP Foundation says was incorrect. The official rating is 9.2.
• Oct 21: Cloudflare's CTO confirmed early attacks against both bugs, and Cloudflare deployed WAF rules as a stop-gap. PHP shipped patched releases at 14:00 UTC, a day earlier than planned. watchTowr reports exploitation observed by its honeypot network since that day.
• As of Oct 22: watchTowr lists the flaws as not yet in CISA's Known Exploited Vulnerabilities (KEV) catalog, and no threat-actor attribution is public.

Be careful with public proof-of-concept code. Tenable says circulating exploit code is unverified and may itself contain malware, and the PHP Foundation said it did not identify any functional exploits at release time. Sansec adds that public PoCs it examined do not work against a default PHP install, while Calif.io demonstrates working exploits under specific conditions. Treat the practical risk as real and rising rather than waiting for a confirmed mass campaign.

How Many Systems Are Exposed?

PHP powers roughly 69% of websites with a known server-side language, according to W3Techs figures cited by Tenable. Estimates of exposed hosts vary by method: VirusTotal estimates over 5.1 million PHP hosts online, Silas Cutler estimates more than 1.3 million internet-exposed hosts are potentially vulnerable, and a Shodan search counts over 1.9 million internet-exposed PHP hosts (a count of PHP hosts, not confirmed vulnerable ones). The UK NCSC told UK organizations to update immediately or take affected systems offline.

Calif.io reports pre-authentication RCE against current releases of WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. The common thread is that they all run on the same PHP engine.

How to Fix PHP2Shell: Step-by-Step

1. Inventory every PHP runtime. Include servers, containers, bundled interpreters and vendor packages. Record version, source and owner. Start with internet-facing systems.
2. Apply the update for your branch. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. On Debian and Ubuntu this usually looks like:

   sudo apt update
   sudo apt install --only-upgrade 'php*'

3. Verify the fix actually landed. Because vendors backport silently, check the changelog for the CVE:

   # Debian / Ubuntu
   zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz
   
   # RHEL family
   rpm -q --changelog php-common | grep CVE-2026-109618

4. Rebuild container images on a fixed PHP base and redeploy them.
5. Restart or replace every worker still running the old code. A patched package on disk does nothing while old PHP-FPM or Apache processes keep running:

   sudo systemctl restart php8.3-fpm   # adjust to your version
   sudo systemctl restart apache2

6. Plan migration off end-of-life branches. If you run PHP 8.1 or older, confirm your vendor covers this CVE or move to a supported branch. The official Docker php image does not receive a fix for 8.1 and older, according to Sansec.

Temporary Mitigations (Only If You Cannot Patch Yet)

PHP states that no configuration change fully mitigates these vulnerabilities, and PHP core developer Gina Peter Banyard said patches are the only permanent defense. If patching must wait, the following reduce risk. Restart all PHP workers after any change:

• CVE-2026-109618 (out-of-memory path): set memory_limit=-1, preferably with php_admin_value so applications cannot override it. Datadog says this blocks the known exploitation path but is not a long-term fix. Also cap post_max_size (PHP suggests 8M without uploads, 32M with uploads) and add a container or cgroup memory limit that kills only the affected worker.
• CVE-2026-109619 (stale-state path): set session.upload_progress.enabled=0. On PHP 8.5, also set fatal_error_backtraces=0.
• Edge filtering: block oversized or malformed POST bodies at your reverse proxy or WAF, and verify the WAF does not truncate large bodies. Cloudflare's rules help only for traffic that passes through Cloudflare. Sansec notes that blocking multipart/form-data breaks file uploads, so test checkout and admin flows if you try it.
• Isolate internet-facing applications you cannot patch (CERT-EU's recommendation).

What not to do: Datadog warns against using RLIMIT_AS or RLIMIT_DATA, because they can trigger the very allocation failures the bug depends on. Hiding errors with display_errors, error_reporting or the @ operator does not help either. And remember that memory_limit=-1 removes a safety cap, so watch server memory until you patch and then restore the limit.

How to Detect PHP2Shell Exploitation

There are no widely published indicators of compromise yet, so detection relies on behaviour. Datadog Security Labs recommends watching for the following:

• HTTP requests: POST requests with an unusually long field name (their reference sample was about 3.5 MB), and raw null or control bytes in form values, especially in fields with empty names. Calif.io and Sansec describe multipart requests as the known trigger, so inspect both content types.
• PHP error logs: PHP Fatal error: Allowed memory size of ... bytes exhausted with Unknown on line 0, which means failure during request initialization before any script ran. Memory exhaustion alone does not prove an attack, so correlate it with oversized POSTs and worker crashes.
• Apache logs: AH00052: child pid ... exit signal Segmentation fault (11) can indicate failed address guessing.
• Process behaviour (strongest evidence): a web worker such as apache2 or php-fpm running as www-data that spawns sh -c or bash, or makes unexpected outbound connections. Do not rely on HTTP status codes or crashes, since a successful exploit can return 200.

Amazon recommends starting investigations from October 17. If a host was internet-facing and unpatched, review web and process logs from that date, hunt for new web shells and unexpected files in writable directories, and rotate secrets stored on the server. Sansec notes the memory-disclosure side of these bugs can leak data from other requests, including passwords, session tokens, API keys and TLS private keys.

Frequently Asked Questions About PHP2Shell

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

They are two critical vulnerabilities in the PHP engine, nicknamed PHP2Shell. Both are rated CVSS v4.0 9.2 and can allow an unauthenticated remote attacker to run code on a server as the web worker user. They were fixed on October 21, 2026.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 have only minimal source backports and vendor packages, and PHP 7.3 and older have no fix.

Is my WordPress or Laravel site affected?

Yes, if the PHP runtime serving it is unpatched. The flaws are in PHP itself, so clean application code does not protect you. Update PHP on the server or ask your hosting provider to confirm they have.

Does setting memory_limit=-1 fix PHP2Shell?

No. It blocks the known exploitation path for the out-of-memory bug and is a temporary measure only. PHP says no configuration change fully mitigates the flaws, so install the patched release.

Is PHP2Shell being exploited right now?

Multiple vendors, including Amazon, Cloudflare and watchTowr, report exploitation attempts. Some sources, such as the PHP Foundation at release time, had not confirmed functional public exploits, so treat the situation as active and patch immediately.

How do I know if my server was already compromised?

Look for web workers spawning shells or making outbound connections, PHP fatal errors showing "Unknown on line 0", Apache segmentation-fault entries, and new unexpected files. Review logs from October 17 onward.

Need Help Securing Your PHP Estate?

Grivyonx Technologies helps teams find every PHP runtime in their environment, patch and verify it, and add runtime detection for web shells. Explore our DevSecOps services and cloud security services, or contact us for a rapid PHP exposure review. For more fast-moving vulnerability coverage, see our analysis of the critical FortiSIEM unauthenticated RCE flaw and browse the Grivyonx Intelligence Hub.

Sources and Further Reading

• Calif.io: PHP2Shell technical write-up
• Tenable: PHP2Shell FAQ
• watchTowr: PHP2Shell FAQ
• Datadog Security Labs: detection, analysis and remediation
• BleepingComputer: PHP ships emergency patches
• Sansec: PHP2Shell impact on Magento, Shopware and WooCommerce
• PHP.net: supported versions

This article reflects public reporting available on October 22, 2026. Details, exploitation status and vendor guidance are changing quickly, so check the linked sources and your vendor's advisory before acting.