Skip to content

The new BARC study is here

Download now
Try for free
Contact us Try for free

Home » Blogs » PHP “php2shell” Vulnerabilities (CVE-2026-109618 and CVE-2026-109619)

PHP “php2shell” Vulnerabilities (CVE-2026-109618 and CVE-2026-109619)

· 6 mins read

We take security very seriously. The trust our customers place in Exasol depends on the consistency and safety of our product, and we treat every critical vulnerability disclosure accordingly.

On 21 October 2026, the PHP project released security updates for two critical vulnerabilities that can allow unauthenticated remote code execution (RCE). Both are rated CVSS v4.0 9.2. Many organizations run PHP somewhere in their stack, often without a central inventory, so we want to share our current status and some practical guidance.

Based on Our Current Assessment, Exasol Is Not Affected, but You Should Check Your Other Systems

Following the PHP advisory, we checked our product and providers for dependencies on PHP. Based on our current assessment and the information available to us today, we have found no indication that Exasol is affected by CVE-2026-109618 or CVE-2026-109619.

We are monitoring the situation closely. Should new information change this assessment, we will publish an update here.

What Happened

According to the PHP security team, the two vulnerabilities are:

  • CVE-2026-109618 (RCE via out-of-memory corruption): When PHP runs out of memory, it can be interrupted while internal request data is only partly initialized. Request cleanup may then treat the invalid data as valid.
  • CVE-2026-109619 (RCE via stale global state): Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker can then use that stale state before normal initialization resets it.

All PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.

Step 1: Find Out Where You Run PHP

We recommend that every organization verify its own exposure rather than rely on assumptions. Do not stop at the servers you know about. PHP often hides in:

  • CMS platforms and plugins (WordPress, Drupal, TYPO3, Joomla and similar)
  • Web applications such as wikis, ticketing, monitoring and admin tools (phpMyAdmin, for example)
  • Container images and base images, including those pulled from third parties
  • Appliances and vendor products with an embedded web interface
  • Shadow IT and forgotten test or staging systems exposed to the internet

Quick checks on Linux hosts

php -v
php-fpm -v
apachectl -M 2>/dev/null | grep -i php
dpkg -l | grep -i php        # Debian/Ubuntu
rpm -qa | grep -i php        # RHEL/SUSE

Check containers and third-party systems

For containers, check the running images and your registry (for example by running php -v inside each image, or by querying your SBOM or image scanner for PHP packages).

Also review your external attack surface with an asset scanner, and ask your vendors and SaaS providers whether their products are affected.

Step 2: Update

A few points to keep in mind:

  • Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages first.
  • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor. Alternatively, upgrade to a supported version.
  • Because of the severity, the PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1, for those who build from source or have no LTS vendor.
  • PHP 8.2 reaches end of life on 31 December 2026, so plan your move to a newer branch now.
  • If you run PHP 8.6 release candidates, update to RC4. These are test versions and must not be used in production.
  • After updating, restart all PHP workers and web server processes, and verify the running version rather than just the installed package.

Step 3: If You Cannot Patch Immediately

The PHP project is clear that only an update is a complete solution. The measures below reduce exposure to specific attack paths but do not make an installation safe.

Treat them as a temporary bridge, and consider additional compensating controls such as taking the system offline, restricting access, or placing it behind a reverse proxy or WAF with strict request limits.

For CVE-2026-109618 (OOM corruption)

  • Set memory_limit=-1, ideally in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration). Check that no pool, directory or application setting reintroduces a finite limit. Note that an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size: 8M for applications without file uploads, 32M where uploads are required. Keep upload_max_filesize below post_max_size.
  • Enforce limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count and nesting depth. These limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup limit as an availability boundary, preferably one that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA, as these can trigger the vulnerable allocation failure.

For CVE-2026-109619 (stale global state)

  • Set session.upload_progress.enabled=0 and restart every worker. Apply it in php.ini, the FPM pool or server configuration, so it takes effect before request parsing. Do not rely on ini_set() or .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart all workers. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated per-request settings that emit diagnostics before initialisation. Hiding diagnostics via error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

The PHP team recommends setting session.upload_progress.enabled=0 until the next regular bugfix release, to protect against an unlikely RCE vector tracked as CVE-2026-115560.

It only occurs when an application sets session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime via ini_set() before session_start(), with upload progress still enabled. If you already applied the setting above, no further action is needed.

Step 4: Look for Signs of Compromise

Because these are unauthenticated RCE vulnerabilities, patching alone is not enough for systems that were exposed. Exploit attempts may have occurred since the release on 21 October. We recommend:

  • Reviewing web server and PHP error logs for unusual crashes, out-of-memory errors, fatal errors or timeouts, and for unusually large or malformed requests
  • Checking for unexpected child processes spawned by web server or PHP workers
  • Looking for new or modified files in web roots (web shells) and unexpected outbound connections from web servers
  • Rotating credentials and secrets stored on or reachable from affected systems if you suspect compromise
  • Involving your incident response process early if anything looks suspicious

Further Reading

This article reflects our current assessment as of the publication date and is based on the information available to us at this time. We will update it if new information becomes available.

Product security