PHP Releases Emergency Patches for PHP2Shell Flaws Threatening Millions of Web Servers

Blog WriterCybersecurity News - Original News Source is cybersecuritynews.com


PHP has released emergency security updates for two critical vulnerabilities that could let unauthenticated attackers run code on vulnerable web servers.

Tracked as CVE-2026-109618 and CVE-2026-109619, and collectively called PHP2Shell, the flaws affect PHP’s handling of memory during web requests. The PHP project rates both vulnerabilities 9.2 out of 10 under CVSS 4.0. Administrators should update PHP as soon as possible.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The vulnerabilities affect earlier versions in those branches. PHP 8.1 and older are no longer supported by the project, though some Linux distributions and long-term support providers may offer backported fixes. Administrators using older releases should check with their vendor or plan a move to a supported version.

PHP branch Affected versions Patched version
PHP 8.2 Earlier than 8.2.35 8.2.35
PHP 8.3 Earlier than 8.3.36 8.3.36
PHP 8.4 Earlier than 8.4.27 8.4.27
PHP 8.5 Earlier than 8.5.12 8.5.12

PHP2Shell Flaws

CVE-2026-109618 stems from how PHP responds to an out-of-memory condition. PHP previously used a mechanism called longjmp() to exit the current operation when memory ran out. In some situations, that sudden exit could leave request data partly initialized. PHP’s later shutdown process could then read or act on the invalid data, opening a path to remote code execution.

The PHP advisory explains that multipart form data can help trigger the memory problem. For example, a request may contain many headers within a part, or many empty file fields that still make PHP create metadata.

Nested field names can add to the memory needed to process the request. The advisory also describes a case where a multipart request without a usable content length can pass an early size check while PHP continues parsing data. These conditions can exhaust memory even when a request appears to stay within some configured limits.

The impact is especially clear for Apache’s mod_php. The PHP security advisory says researchers validated unauthenticated code execution over HTTP against this setup, using default PHP input and memory limits. The request can reach the vulnerable state before the application’s own code starts. The risk differs across server setups. For PHP-FPM, the advisory says source analysis indicates susceptibility, but the same complete exploit was not demonstrated for that server setup.

CVE-2026-109619 involves stale global state in long-running PHP workers. A worker may retain a reference to memory from a request after PHP has freed that memory. If an error or other event interrupts cleanup, and a later request reaches that leftover state before PHP resets it, the worker may use invalid memory.

he advisory describes confirmed paths involving fatal errors, error-reporting data and session upload-progress handling. Whether a specific server is exposed depends on its PHP setup, configuration, application, and extensions.

The second flaw matters because web workers handle requests one after another. A state left behind by one request can affect a later request handled by the same worker. The PHP advisory’s confirmed cases include a mod_php scenario. It also describes a PHP-FPM path that depends on an application operation and a later request reaching the same worker. These details make the setup important, but they do not reduce the urgency of patching.

The fix for CVE-2026-109618 changes PHP’s handling of out-of-memory errors. Instead of abruptly leaving an operation in a way that can expose incomplete request state, PHP delays a graceful memory error until a safe point.

A separate hard limit handles more severe memory pressure. The related fix for CVE-2026-109619 resets a wider range of request-related global state so that a worker is less likely to carry invalid references between requests.

Security coverage has described the flaws as affecting PHP web deployments across several server setups, including Apache with mod_php and PHP-FPM. Exposure estimates underline the scale of the concern: BleepingComputer reported a VirusTotal estimate of more than 5.1 million PHP hosts visible online. That figure is an estimate of exposed hosts, not a count of confirmed vulnerable or compromised servers.

PHP Team Recommends Updating

The PHP project says updating to a release with the fixes is the complete mitigation. After upgrading, administrators should restart PHP workers and check that all web-facing pools and services are using the patched version. Updating the command-line PHP package alone may not update a separate PHP-FPM service or an Apache module.

If an update cannot happen immediately, temporary measures can reduce some risk but do not replace patching. For CVE-2026-109618, the advisory names an administrative memory_limit=-1 setting as a primary configuration step, while warning that it is not complete protection. It also recommends limiting request sizes and multipart inputs at the frontend. Administrators should avoid RLIMIT_AS and RLIMIT_DATA, which can cause allocation failures on the vulnerable path.

For the stale-state flaw, the advisory says there is no complete general configuration workaround. On PHP 8.5, disabling fatal_error_backtraces can remove the producer used in one confirmed case. Disabling session upload progress can reduce exposure to a demonstrated session-related path.

Neither setting addresses every possible producer and consumer of stale state, so organizations should treat them only as temporary risk-reduction steps.

Cybersecurity News has also reported on a public PHP2Shell testing tool and early exploitation attempts. These reports are a reason to prioritize upgrades, not a substitute for checking a system’s actual version and vendor guidance. The primary references are the PHP advisory for CVE-2026-109618 and the related advisory for CVE-2026-109619.

If organizations can’t patch immediately, reduce public exposure where possible, review PHP and web-server logs, and confirm which worker processes handle live traffic. Log checks can help identify errors, but clean logs don’t prove a system is safe. The strongest defense is to move every web-facing PHP installation to a fixed release and verify that the updated workers have restarted.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post PHP Releases Emergency Patches for PHP2Shell Flaws Threatening Millions of Web Servers appeared first on Cyber Security News.