PHP2Shell Vulnerability Update (CVE-2026-109618 & CVE-2026-109619)

October 22, 2026by: Max Malyutin & Ido Veltzman

Executive Summary

PHP2Shell refers to two critical vulnerabilities in PHP’s core runtime, CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state), both rated 9.2 under CVSS.

The flaws affect PHP’s memory management and error handling, rather than a specific application or framework. AI-assisted security research involving Wiz Research, OpenAI, and Calif helped demonstrate practical exploitation and supported coordinated remediation with PHP maintainers.

Under certain conditions, threat actors can exploit these vulnerabilities remotely, without authentication, to execute malicious code or access sensitive process memory, potentially exposing passwords, authentication tokens, and API keys. Affected websites and applications may be exposed even when their application code is secure. Exploitability varies by deployment and configuration, and malicious code runs with the permissions of the PHP service. Further compromise depends on the systems and credentials accessible to that service.

PHP released emergency security updates on October 21, 2026. AWS reported exploitation attempts dating back to October 17, before public disclosure. Organizations running affected versions should prioritize immediate patching and review earlier activity for signs of exploitation.

Refer to the Recommendations section for affected versions, available updates, temporary mitigation measures, and investigation guidance. Temporary controls can reduce exposure, but applying the PHP fixes is the only complete remediation for these vulnerabilities.

This article will be updated as additional technical details become available and are verified.

Affected deployments and fixed versions

PHP Branch	Affected Upstream Releases	First Fixed Release
8.2	Earlier than 8.2.35	8.2.35
8.3	Earlier than 8.3.36	8.3.36
8.4	Earlier than 8.4.27	8.4.27
8.5	Earlier than 8.5.12	8.5.12

Cynet response and investigation guidance

Cynet Research is actively investigating the PHP2Shell vulnerabilities and monitoring emerging technical details, exploitation techniques, and threat activity to assess their implications for customer protection.

In parallel, Cynet’s CyOps MDR team is monitoring customer and partner environments for suspicious activity that may indicate exploitation or subsequent malicious behavior, supporting investigation and response where relevant activity is identified.

Cynet’s EPP provides detailed visibility into process activity on monitored endpoints, enabling CyOps and customers to trace process execution and proactively hunt for abnormal behavior. This visibility supports investigating suspicious process launches and unexpected execution patterns that may indicate PHP2Shell exploitation or subsequent malicious activity, helping teams assess the scope of potential compromise and guide response.

Cynet’s Vulnerability Scanner helps identify known vulnerabilities in supported applications, allowing customers to prioritize patching based on identified exposure and severity. These findings complement ongoing monitoring and support remediation planning.

Vulnerabilities Details

CVE-2026-109618

PHP can make a request data structure visible before it is fully initialized. One verified example is string-key insertion into a HashTable: the vulnerable PHP 8.5.11 code increments both entry counts before allocating the new key. If that allocation exhausts memory, PHP’s allocator calls zend_bailout(), leaving an entry counted as live although its bucket is incomplete. Request cleanup later walks the reported entries and can interpret uninitialized bucket contents as valid values or pointers. This is one concrete path within the broader failure described by PHP’s advisory. The excerpt is from PHP 8.5.11 Zend/zend_hash.c; the bailout is visible in Zend/zend_alloc.c.

add_to_hash:
    idx = ht->nNumUsed++;       // Marks the bucket as used.
    ht->nNumOfElements++;       // Reports another live element.
    p = ht->arData + idx;
    // An OOM here can bail out before the bucket is initialized.
    p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);
    p->h = ZSTR_H(key) = h;
    HT_FLAGS(ht) &= ~HASH_FLAG_STATIC_KEYS;
    if (flag & HASH_LOOKUP) {
        ZVAL_NULL(&p->val);
    } else {
        ZVAL_COPY_VALUE(&p->val, pData); // Reached only if key allocation succeeds.
    }

Successful exploitation leads to unauthenticated remote code execution with the web worker’s privileges against Apache mod_php, including default input and memory limits. A crafted HTTP request can exhaust memory during automatic body parsing, before application code runs; shutdown then consumes the invalid state.

CVE-2026-109619

A PHP worker retains global fields that can point into memory owned by a single request. A fatal interruption can skip the matching reset, or later shutdown activity can repopulate a field after it was cleared. Once the request heap is freed, a subsequent request on the same worker can use that stale state before normal request initialization resets it, producing a use after free. The verified startup ordering below shows why multipart handling is an early consumer: PHP parses input before activating extension request hooks. The session upload-progress callback in vulnerable PHP 8.5.11 accessed its globals at multipart start without first resetting them; the fix adds that early reset. Sources: request startup, session callback, and PHP’s advisory.

// php_request_startup(): request input is parsed first.
php_hash_environment();   // Input parsing can invoke upload-progress handling.
zend_activate_modules();  // Normal module request initialization follows.
PG(modules_activated)=1;

// php_session_rfc1867_callback(): vulnerable multipart-start path.
if (!PS(rfc1867_enabled)) {
    return retval;
}
progress = PS(rfc1867_progress); // Worker global is accessed before normal RINIT.
switch(event) {
    case MULTIPART_EVENT_START: {
        multipart_event_start *data = (multipart_event_start *) event_data;
        progress = ecalloc(1, sizeof(php_session_rfc1867_progress));
        progress->content_length = data->content_length;
        PS(rfc1867_progress) = progress;
    }
    break;

Successful exploitation leads to unauthenticated memory disclosure and remote code execution with the web worker’s privileges. The demonstrated attack uses one request to leave stale state and another request routed to the same worker to consume it. PHP confirms remote code execution against mod_php through fatal-error backtrace and session paths, and against FPM through a session path that depends on a suitable application operation. Worker assignment and recycling affect success per attempt; they do not eliminate the flaw.

Disclosure Timeline

August 11^th: Calif researcher Ryan A reports an unauthenticated RCE vulnerability associated with the previously identified OOM issue. OpenAI independently reports the same root cause that day.
August 19^th: Wiz Research independently discovers a PHP vulnerability with AI-assisted research.
August 24^th: Wiz submits its vulnerability findings to the PHP security team.
September 18^th: OpenAI reports additional exploitation vectors.
September 21^st: According to Wiz, PHP acknowledges its reports and begins developing a coordinated fix.
October 17^th: AWS identifies a PHP2Shell exploitation attempt in its MadPot honeypot telemetry, predating public disclosure.
October 20^th: The two CVE identifiers leak on Hacker News and social media. Initial reports incorrectly claim a CVSS score of 10.0 and disclose no technical details. PHP officially announces an emergency security release, moving the disclosure from October 22 to October 21 at 14:00 UTC.
October 21^st: Additional exploit PoCs emerge, and AWS reports observing exploitation activity against its sensors shortly after disclosure.

Recommendations

Cynet recommends that customers immediately identify and update PHP deployments affected by PHP2Shell, tracked as CVE-2026-109618 and CVE-2026-109619. These critical runtime vulnerabilities can enable unauthenticated remote code execution. The first fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Customers running an earlier release within these branches, such as PHP 8.5.11, should immediately update to the corresponding fixed release or a later supported version.

Customers running PHP 8.1 or earlier should prioritize upgrading to a supported, patched version, as these branches no longer receive standard security releases from the PHP project. Some distributions and extended-support vendors provide backported fixes. Customers using these packages, managed hosting, or appliances should confirm with their provider that the applicable update addresses both vulnerabilities.

Applying the PHP fixes is the primary remediation. Temporary mitigations and security monitoring do not replace updating or upgrading the affected runtime. In parallel, Cynet Research is investigating the vulnerabilities and monitoring emerging exploitation techniques, while the CyOps MDR team monitors customer and partner environments for suspicious activity that may indicate exploitation or subsequent malicious behavior.

Version	Fixed Release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
7.x	No fix is available
5.4-5.6	No fix is available

Customers should take the following remediation and investigation steps:

Patch all affected PHP runtimes and restart workers. Configuration changes alone do not fully remediate both vulnerabilities.
Restrict access to unpatched applications and consider limiting requests or blocking unnecessary uploads after assessing application impact.
Investigate unusual POST requests, including oversized fields and unexpected binary data. PHP_SESSION_UPLOAD_PROGRESS alone does not indicate exploitation.
Correlate suspicious traffic with PHP errors, worker restarts, and abnormal session cookies. Successful exploitation may produce no errors.
Hunt for unexpected processes, connections, and file changes on web servers, comparing findings with normal application behavior.

On top of that, PHP officially recommends^[1] that those who cannot update immediately apply the following changes:

CVE-2026-109618:

Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing 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 with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

CVE-2026-109619:

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with 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.

Indicators of Compromise (IOCs)

AWS has published indicators of compromise associated with observed PHP2Shell exploitation attempts, based on telemetry collected by Amazon Threat Intelligence through its MadPot honeypot infrastructure. The earliest reported attempt occurred on October 17, 2026, four days before public disclosure. AWS shared the following source IP addresses to support investigation and threat hunting.

Source IP address	Observed date
103.216.220[.]92	October 17, 2026
31.223.184[.]166	October 21, 2026
37.19.200[.]5	October 21, 2026
134.209.159[.]64	October 21, 2026
103.114.163[.]188	October 21, 2026
95.217.98[.]37	October 21, 2026