PHP2Shell: Update PHP Before the Next Request

Two critical vulnerabilities in PHP can allow an unauthenticated attacker to execute code on a web server. Fixed PHP releases are available, attack traffic is already being observed, and the useful version of this article can be reduced to one sentence: update PHP immediately.

The flaws are CVE-2026-109618 and CVE-2026-109619. Both have a CVSS 4.0 score of 9.2, and exploitation may happen before normal application code gets much opportunity to help.

This is a PHP runtime problem. Updating WordPress, Magento, Laravel, or a plugin is always sensible, but it does not fix these vulnerabilities. A beautifully maintained CMS on top of vulnerable PHP is still running vulnerable PHP.

What happened

The two bugs affect different parts of PHP request processing. One can corrupt memory when an out-of-memory condition interrupts the initialization of internal request data. The other can leave request-related state available after its memory has been freed, allowing a later request handled by the same worker to use stale data.

That is enough internals for today. The practical result is more important: specially prepared web requests can create conditions that may let an attacker run code on the server without logging in.

The PHP project warns that installations serving web requests through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed are at risk. A complete unauthenticated exploit has been demonstrated against common mod_php configurations, and vulnerable paths also exist in PHP-FPM environments.

Early notifications said that no active exploitation had been seen. That changed quickly, as expected after public disclosure. Cloudflare reports observing attack traffic and attempts to modify payloads to bypass filtering. CISA is also urging immediate patching.

Install a fixed PHP release

The PHP project has published the following fixed versions:

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

Install the corrected packages provided by the repository or operating system vendor you actually use. That distinction matters. Debian, Ubuntu, AlmaLinux, CloudLinux, Remi, control-panel vendors, NAS manufacturers, and managed hosting platforms may backport a fix while retaining their own package version scheme. Check the vendor’s security notice instead of deciding that a server is safe from the first two numbers in php -v.

After installing the update, restart Apache, PHP-FPM, containers, or other long-running PHP workers. New packages on disk do not repair old processes already sitting in memory.

Then verify the version used by the website itself. The command-line PHP binary, web server module, FPM pool, and container image can all be different installations. It is surprisingly easy to update the polite PHP binary that answers in your terminal while the public website continues talking to its older cousin.

If PHP comes from a container image, rebuild or pull a corrected image, redeploy it, and confirm that no old replicas remain. If it is part of a NAS, router, home appliance, or hosting control panel, follow that vendor’s bulletin. Do not replace an integrated package manually unless the vendor specifically instructs you to do so.

Old PHP needs more than optimism

PHP 8.1 and older branches are no longer supported by the PHP project. The maintainers have supplied minimal source-level backports for PHP 7.4, 8.0, and 8.1 to help downstream vendors, but these are not new supported PHP releases and are not a good excuse to keep an obsolete stack indefinitely.

Cloudflare’s analysis says the vulnerable behavior reaches back to PHP 5.4. Administrators of old applications should therefore check whether their distribution or commercial long-term-support vendor provides a corrected package. If it does not, migration to a supported PHP version is part of the security fix.

An old PHP release may be hidden behind a site that has worked quietly for years. Unfortunately, “it still serves pages” and “it still receives security fixes” are two entirely different health checks.

If you cannot update immediately

Updating is the only complete fix. The following measures may reduce exposure while an emergency update is prepared, but they should buy hours, not become the new architecture.

The safest temporary option is to prevent requests from reaching PHP. Stop the affected PHP or web service, or block public access at the load balancer, reverse proxy, or firewall. A WordPress or Magento maintenance page is not the same thing: PHP still executes to display it. Making the application read-only is also not sufficient by itself because the vulnerable processing happens inside the runtime, not only when the application writes data.

Cloudflare has deployed temporary WAF protection for all plans, including Free. Putting a site behind Cloudflare can add a useful layer while systems are updated, but Cloudflare explicitly describes this as defense in depth, not a replacement for patching. Other proxies and WAF products may publish their own rules and guidance.

The official PHP advisory also recommends temporary hardening measures:

• Disable session upload progress with session.upload_progress.enabled=0, then restart every PHP worker. Set it in php.ini, a PHP-FPM pool, or another server-level configuration loaded before request parsing. Setting it through application code or .user.ini is too late for this purpose.
• Reduce post_max_size and upload_max_filesize to the smallest values the application needs. If uploads are unnecessary, reject multipart requests at the web server or reverse proxy.
• Enforce request-body limits at the proxy or web server, including for requests without a usable Content-Length header.
• On PHP 8.5, set fatal_error_backtraces=0 and restart workers.

These controls limit confirmed attack paths, but the vulnerabilities form a chain with more than one route. There is no magic configuration switch that makes a vulnerable PHP build equivalent to a patched one.

An early industry email also suggested enabling session.use_only_cookies. That remains reasonable session hygiene, but the final PHP guidance specifically focuses on disabling session upload progress. Neither setting should delay the update.

Check what happened before the patch

Because attacks are now being observed, applying the update is only the first task on an internet-facing server. Review web, proxy, PHP, authentication, and system logs for unusual requests or behavior. Look for unfamiliar files, scheduled jobs, users, processes, SSH keys, and unexpected outbound connections.

If there are signs of compromise, isolate the server. Preserve the information needed for investigation, rebuild from a known-good source, and rotate credentials and secrets that the host could access. Changing one password is not enough if the server stored database credentials, API tokens, deployment keys, or access to other systems.

Backups should already be stored in an independent location, encrypted, and periodically tested. A backup is extremely useful after an incident, provided it is neither attached to the compromised server nor waiting to surprise you with a restore error.

Finally, make an inventory. Check production, staging, development, forgotten subdomains, old customer projects, CI runners, appliances, and containers. Internet scanners do not know which server was supposed to be temporary, and they are not known for respecting TODO comments.

Patch first, investigate second, postpone neither

CVE-2026-109618 and CVE-2026-109619 affect the layer underneath a huge number of websites and applications. They are critical, patches exist, and hostile requests are already circulating.

Update to a fixed PHP build, restart every worker, and verify the version actually serving web traffic. If an immediate update is genuinely impossible, remove the service from public access or place temporary defenses in front of it while the maintenance is completed. A maintenance page and good intentions are not security controls.