PHP2Shell: Twin Flaws in PHP's Engine Put Nearly Every Web Server at Risk

The PHP project has released emergency updates for two critical vulnerabilities in the programming language itself. Together nicknamed "PHP2Shell," the flaws can let an attacker with no account run their own code on a web server. The fixes appeared around 14:00 UTC on October 21, 2026, a day earlier than planned because details had leaked. Researchers at Wiz, Calif and OpenAI found and reported the bugs. Cisco Talos and The Hacker News have since reported exploitation attempts against unpatched systems.

What happened

Coordinated disclosure of the two bugs was set for October 22. After details leaked on October 20, PHP published its advisory and patches a day early, at roughly its scheduled release time of 14:00 UTC on October 21.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. A CVE is a standard public identifier for a security bug. Both are rated 9.2 out of 10 on CVSS v4.0, the industry scale for severity. The fixed releases are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Before the patches shipped, Cloudflare said it was already seeing early exploitation attempts and was adjusting its protections. Cisco Talos first reported that, as of 14:00 UTC on October 21, it had not seen in-the-wild exploitation. It updated its post on October 22 to say it had begun observing attempts within hours of disclosure.

Talos noted that the parties involved in the discovery suggest artificial intelligence played a significant role in finding the bugs. It also said the resulting wave of disclosures is putting pressure on how organisations handle patching.

Who is affected

The flaws sit in the PHP runtime, the engine that executes PHP code, rather than in any particular website. A site can be exposed even if its own code is flawless. According to the PHP advisory, even a bare "Hello World" page running on a vulnerable version can be attacked.

The bugs reach back to PHP 5.4. Both outlets say every PHP installation that handles web requests is at risk, whichever way PHP is connected to the web server:

• Apache mod_php, which PHP rates as the highest-risk setup
• PHP-FPM, a common process manager used with Nginx and other servers
• php-cgi
• FrankenPHP
• LiteSpeed

Talos warns that the possible blast radius covers much of the web. Sites built on WordPress, Drupal, Magento, Shopware, WooCommerce and Laravel, and PHP sites hosted through control panels such as cPanel and Plesk, may all be exposed. Talos assesses that every industry running PHP applications is at risk if systems stay unpatched. Neither source breaks down exposure by region.

Older versions are a particular concern. PHP 8.1 and earlier no longer receive official updates, and PHP 8.2 reaches end of life on December 31, 2026. Based on open-source intelligence, Talos estimates that around half of PHP systems will not receive a patch.

How it works

Both bugs involve PHP's internal bookkeeping while it is still preparing to handle an incoming web request. That is why they can be triggered before any application code runs.

CVE-2026-109618 involves running out of memory at the wrong moment. Talos explains that if PHP's out-of-memory handling interrupts it while internal request data is only half set up, the cleanup routine that follows may treat that incomplete data as valid. Mishandled memory of this kind can lead to code execution.

CVE-2026-109619 is a "use-after-free" style problem. Some internal state is reused after the memory behind it has already been released, before PHP's normal setup has a chance to reset it. A feature called session upload progress, which reports how far a file upload has got and is on by default, is involved in one confirmed attack path for this flaw.

The setup matters. On mod_php, researchers demonstrated an attack in which a single unauthenticated web request triggers the flaw. PHP-FPM behaves differently because it shuts down a worker process when a request fails early in setup. For the first flaw, PHP's analysis indicates FPM is susceptible, but no complete FPM exploit has been shown. For the second, code execution was demonstrated on both mod_php and FPM, although the FPM route depends on an operation inside the running application.

Code execution is not the only danger. An attacker can also read memory from a PHP worker process without first taking control of it. That memory may contain passwords, login tokens, API keys and certificates belonging to other visitors' requests. The researchers showed this memory leak working against applications they did not control.

How serious is it?

The two sources agree on the core facts. Both bugs are critical, rated 9.2, can be exploited without authentication, and affect nearly every PHP version back to 5.4. The low barrier to attack and the size of PHP's footprint are what make this incident stand out.

The picture of exploitation changed quickly. Cloudflare reported early attempts before the patch shipped. Talos initially reported none, then confirmed attempts within hours of disclosure. Talos says most activity so far is scanning, along with some uncoordinated efforts to deliver payloads using public proof-of-concept code. It expects volume and sophistication to grow as more capable groups, including state-linked and ransomware actors, add the flaws to their tools.

The sources differ on older branches. Talos says plainly that there is no patch for PHP 8.1 or older. The Hacker News reports that the PHP security team has published source-code backports for PHP 7.4, 8.0 and 8.1, aimed at people who compile PHP themselves or are waiting on a vendor. Both positions can hold at once: these are unofficial-style source fixes, not regular supported releases.

PHP core developer Gina Peter Banyard warned before the release that "the only mitigation is patching/upgrading PHP."

What to do now

For server administrators:

• Update the PHP runtime to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Then restart Apache, PHP-FPM and any long-running PHP workers.
• Remember that updating WordPress, Laravel or another application does not update PHP underneath it. The runtime comes from your server packages, your hosting provider or your container image.
• On Linux distributions, check the package changelog for the CVE numbers rather than relying on the version string. Distributions received patches in advance and may ship the fix under an older-looking version number, as Debian advises.
• If you run PHP 8.1 or older, plan an urgent move to 8.2 or later. PHP's source backports for 7.4, 8.0 and 8.1 can serve as a stopgap.
• If you cannot patch immediately, apply PHP's partial measures. They reduce exposure but do not make a server safe:
  • For CVE-2026-109618, set memory_limit=-1 so applications cannot override it, keep post_max_size low, and enforce request-size limits at the web server or proxy. Do not use RLIMIT_AS or RLIMIT_DATA as a substitute, because they can trigger the same vulnerable path.
  • For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini or the server configuration, not via ini_set(), and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. This blocks the confirmed session paths but not other variants.
• After patching, review memory settings. The fix adds a new hard memory limit, and hitting it ends the process without running shutdown handlers.
• Look for signs of earlier compromise: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, abnormally large PHPSESSID cookies, and unexplained worker restarts.
• Cisco customers can deploy Snort signatures 67359, 67360 and 67375, which are also in the Community Ruleset. Splunk Enterprise Security has a content update with detections.

For everyday users and site owners:

• If your site is on shared or managed hosting, ask your provider whether its PHP has been updated for these CVEs.
• Updating your CMS plugins alone will not fix this, so confirm that the server itself has been patched.

What we still don't know

• Whether any exploitation attempts have led to confirmed break-ins, and against which organisations.
• Whether a complete PHP-FPM exploit exists for CVE-2026-109618.
• Who leaked the details ahead of the planned disclosure, and how.
• Exactly how AI tools were used in finding the bugs. Talos infers a significant role from the parties involved but gives no specifics.
• How quickly hosting providers and vendors will roll out fixes to the large share of systems on unsupported versions.

ITVedas analysis: PHP2Shell is a reminder that many organisations treat the runtime layer as invisible: they patch WordPress diligently while PHP itself quietly ages underneath. With roughly half of PHP systems reportedly beyond official support and scanning already underway, the gap between "patch available" and "patch applied" is where most of the damage is likely to happen.