Treat this as a PHP runtime incident
The urgent work is straightforward: identify every internet-facing PHP runtime you operate and move it to a fixed release. PHP’s security team released emergency patches for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively tracked as PHP2Shell. Both are described as unauthenticated RCE flaws. An application-level change is not the fix for a flaw in the PHP runtime.
BleepingComputer reports that the vulnerabilities affect PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team said the risk is highest for mod_php, citing a demonstrated exploit in which an unauthenticated request can trigger the attack before application code runs. That distinction matters: teams shouldn’t assume a request filter or a code change in one application has removed the underlying exposure.
The reported fixed PHP 8.x releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Administrators should match the running branch to its corresponding fixed release, then confirm the runtime actually serving requests has changed. If a hosting provider or platform team owns the PHP installation, ask them directly which runtime version is deployed and when it will be patched. A package installed on a machine is not useful reassurance if production workers are still running the old version.
What the two flaws do
The reported flaws share a broad theme: abnormal request termination can leave PHP memory in a corrupted state. CVE-2026-109618 involves out-of-memory corruption; the article describes a chain of weaknesses that can lead to remote code execution as the web worker account. CVE-2026-109619 is described as a stale-global-state vulnerability that can enable unauthenticated heap use-after-free, memory disclosure and remote code execution with the worker’s privileges.
Those technical descriptions are not a reason to speculate about which of your applications is exploitable. They are a reason to treat the PHP engine as the unit that needs attention. Inventory the ways PHP serves web requests in your environment, including the modes named above, and avoid narrowing the check to a single framework or site. If a server handles more than one PHP application, the relevant question is whether the shared runtime has been brought to a fixed release.
The report says PHP users should install the listed PHP 8.x fixes as soon as possible. PHP 7 and earlier users are advised to migrate to a fixed release. PHP 8.1 and older no longer receive updates from the PHP project, though some distributions and long-term-support vendors provide backported fixes. The PHP developers also supplied minimal source backports for PHP 7.4, 8.0 and 8.1 for people building from source or without access to an LTS vendor. These cases need vendor- or build-specific confirmation; don’t assume an old version is protected just because a package has a familiar version string.
Temporary measures are not a patch
The PHP team described mitigations that may reduce exposure to some attack paths when immediate patching isn’t possible. They do not fully protect against exploitation. That warning should govern how these controls are used: as a short bridge while arranging an upgrade, not as a reason to defer it.
For CVE-2026-109618, the reported measures include setting memory_limit=-1, preferably in a way an application cannot override, and setting a low post_max_size—8M for applications that don’t need uploads or 32M where uploads are required. The team also recommends using a container or cgroup limit as an availability boundary, preferably with a policy that terminates only the affected worker.
For CVE-2026-109619, the report lists disabling session.upload_progress.enabled and restarting every worker. On PHP 8.5, it also lists setting fatal_error_backtraces=0 and restarting every worker; the report says this blocks only the confirmed fatal-backtrace path. Other listed measures include removing invalid or deprecated per-request settings that emit diagnostics before initialization, and fixing attacker-reachable fatal errors and execution timeouts, including those in callbacks, upload or import processing, and cleanup.
These settings are specific and operationally consequential. Apply them only after checking the PHP team’s guidance and your service’s requirements. For example, reducing request-body limits can affect applications that accept uploads. The point isn’t to copy a configuration snippet blindly; it’s to understand which temporary control applies to which flaw, roll it out in the right runtime configuration, and still complete the update.
The PHP team cautioned that no mitigation fully blocks potential attacks. In particular, the report says hiding diagnostics with error_reporting, display_errors or @ does not help with the described issue. Don’t treat a quieter log or a successful configuration reload as evidence that the vulnerability is gone.
Verify the fix across the serving path
A useful response has a clear owner and a verifiable finish. Find the PHP versions and serving modes in use, identify who controls each runtime, and schedule the corresponding fixed release. After the change, verify the version used by the live workers—not merely the version reported by a build pipeline or package repository. Restart workers where the relevant change or deployment requires it, and check that all instances behind a load balancer have converged.
If you cannot patch immediately, document the temporary controls you have applied, which services they cover, and the remaining gap. Keep that work time-bounded. The BleepingComputer report says Cloudflare had deployed web application firewall rules for known PHP2Shell exploitation methods and observed early attacks before the patches were released. It also characterizes those rules as temporary protection and reports the PHP team’s view that official security patches are the only permanent defense. A WAF rule may help reduce known attack paths; it does not update the PHP process.
The same source reports that the UK National Cyber Security Centre advised UK organizations to update systems using PHP immediately or take them offline until they can be patched. That is a stark option, but it makes the decision plain: if a vulnerable runtime remains exposed and you cannot patch it, continuing to serve requests is not a neutral choice.
Make the next check concrete
Start with the runtime, not assumptions about application code. Record the service, PHP serving mode, current release, owner and planned fixed release. For unsupported branches, get confirmation from the distribution or LTS vendor, or plan migration to a supported version. Then verify the running workers after deployment.
PHP2Shell is a case where temporary mitigations have a role, but only a limited one. The source describes serious, unauthenticated flaws across common web-serving configurations and early attacks observed by Cloudflare. That is enough to justify a prompt, deliberate patch response without embellishing what is known about exploitation. Get the runtime updated; use the interim controls only to reduce some exposure while that work is underway.
