What Is PHP2Shell and Why You Must Patch PHP Immediately

On October 21, 2026, PHP shipped emergency fixes for two critical holes in PHP itself. The public nickname is PHP2Shell. The official names are CVE-2026-109618 and CVE-2026-109619. On a server that still has the old PHP, a stranger on the internet can run commands with no password and no account.

This is not a bad plugin. It is not a weak password. Updating WordPress, a theme, or a plugin does not, by itself, repair it. PHP is the engine under the site. The repair is a PHP update on the server, applied today, then a restart of the workers that are still holding the old engine in memory.

This note is from the Prager Hosting Team at Prager Microsystems in Collegeville, Pennsylvania. The facts below were checked on October 21, 2026 against the PHP project’s security advisory, the CISA alert released the same day, and the parallel notices from the UK NCSC and the Canadian Centre for Cyber Security. The plain language half comes first. The IT half follows it. Both end in the same place. Patch now.

What happened, in plain language

Picture a car. People notice the paint, the seats, and the radio. That is WordPress, the theme, and the plugins. The engine is what makes the car go. That is PHP. It sits under the site, and customers never see it.

You can wash the car and change the seats. You can put in a new radio. None of that repairs the engine. PHP2Shell is a crack in the engine. On a server that still has the old PHP, a stranger does not need a key or a password. They can make the engine run their instructions.

PHP runs a huge share of the web. WordPress runs on it. So do many stores, membership sites, and the quiet admin tools a company forgot it installed in 2017. When this engine is cracked, every site that uses it has the crack, even when that site’s own pages are tidy.

There are two defects, announced together on October 21. You do not need their mechanics to make the right call. You do need a picture of why “we updated the plugins last week” is not the call.

Two ways in

Two ways the engine fails.

• 1The interrupted formCVE-2026-109618. A clerk is halfway through a ticket when the work is cut off. Cleanup then files the half written ticket as if it were finished.
• 2The leftover folderCVE-2026-109619. A note from the last visitor is still on the desk when the next visitor sits down, and the clerk trusts it.

The interrupted form

Picture a clerk filling out a ticket. Halfway through, the pen runs dry in a specific and ugly way, and the clerk is yanked off the task. The cleanup rule then treats that half written ticket as a real, finished ticket and files it. Someone who can force that interruption can arrange for their own instructions to be what gets filed.

That is the shape of CVE-2026-109618. PHP can be cut off while it is still building the internal paperwork for a visit, because it ran out of memory in the middle of a step. The cleanup that follows can treat that half built paperwork as valid. From the outside, the result can be remote code execution. The server runs the attacker’s instructions.

The leftover folder

Picture the same counter an hour later. One visitor’s folder was supposed to be thrown away when their visit ended badly. It was not. The next person sits down, and the clerk reads the leftover folder as if it belonged to them. Secrets from the first visit, and instructions that were never meant to survive it, get treated as legitimate.

That is the shape of CVE-2026-109619. A PHP worker serves many visits in a row, the way one clerk handles a line of people. Internal notes from one visit can outlive the memory that was supposed to hold them. A later visit handled by the same worker can trust those stale notes before the desk is reset. The result, again, can be remote code execution. The leaked memory can also include material from other visits, such as passwords, tokens, and keys.

You can forget both pictures after this paragraph. Keep the conclusion. A person who has never logged in can, on an unpatched server, reach past the website and into the machine. The PHP project’s own line is that every PHP installation serving web requests is in scope, and that on Apache with mod_php a demonstrated exploit can fire before any of the website’s own code runs. The website never gets a vote.

• Not thisA plugin bugUpdating plugins is still worth doing. It does not close PHP2Shell.
• Not thisA weak passwordNo account is required. Changing the admin password does not close it either.
• Not thisA theme issueThe theme is the paint. The flaw is under it.
• ThisThe PHP engineThe server has to be running a fixed PHP, and the workers have to be restarted.

Why the patch cannot wait

On October 20, the PHP project warned that two critical fixes were coming and asked every operator to be ready. The details did not stay private. A description of the bugs, and talk of a working tool nicknamed PHP2Shell, reached the public before the patched versions did. PHP moved the release up to October 21 rather than wait for the original window.

That sequence matters more than the nickname. A vulnerability nobody has heard of can sit quietly. A vulnerability with a name, a score of 9.2, and a public description does not. Researchers at Sansec said they expected mass attack traffic within about 15 minutes of the release. SecurityWeek reported that some security teams were already seeing exploit attempts before the patches landed. Qualys reported that Cloudflare had seen attack traffic aimed at these bugs, including attempts to slip past protections. CISA’s alert, published October 21, said CISA had not confirmed exploitation as of that writing, and still told organizations to patch immediately.

Those reports are not in conflict in any way that helps an unpatched server. One agency had not yet confirmed a successful break in. Other teams were already watching people try the handle. Waiting for a single headline that says “it is widespread” is how a server becomes one of the examples in tomorrow’s headline.

The bug was described in public before a patched version of PHP existed. Updating tonight closes it. Waiting until next Thursday leaves the old version in place while people are already trying it.

Partial workarounds exist. PHP published them for operators who cannot update in the same hour. The same advisory says they reduce exposure to specific paths and do not make an installation safe. A web application firewall may block some of the obvious attempts. CISA describes that as a bridge, not a fix. Hiding error messages does nothing. The only complete repair is the updated PHP.

If a system cannot be patched today, take it off the public internet until it can. That is CISA’s advice for organizations that cannot update immediately, and for anyone still on PHP 8.1 or older, which the PHP project no longer maintains. “We will watch it” is not a control. A quiet server is not evidence that nobody has knocked. It is evidence that you have not looked.

What Prager has already done

If someone else hosts the site, ask them today which PHP version is actually answering requests. Acceptable answers are PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a Linux distribution package the vendor explicitly says includes these two fixes. “We are on PHP 8” is not an answer. “WordPress is up to date” is not an answer. “The firewall is on” is not an answer.

We host business sites so this kind of afternoon does not land on the owner. Server setup, current patches, firewalls, monitoring, and managed WordPress are the work, not an extra after the design. The service is described on our managed web hosting page. If the host you have cannot tell you the PHP version today, that is the finding. Call 610.409.1605 or write info@pragermicrosystems.com. The office is 3819 Germantown Pike, Suite A, Collegeville, PA 19426.

The same issue, for IT teams

The PHP project’s advisory of 21 October 2026 states that PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution, and that all PHP users should update immediately. Both flaws were scored 9.2 on CVSS v4.0 in the October 20 advance notice and in subsequent government alerts.

Who is at risk, in the project’s words, all PHP installations serving web requests, including PHP FPM, Apache with mod_php, php cgi, FrankenPHP, and LiteSpeed. The project considers the risk highest for mod_php, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. PHP FPM is not a free pass. The project has also described application level paths to code execution there. WordPress, Drupal, Joomla, Magento, Laravel, Symfony, MediaWiki, and anything else sitting on PHP inherits the exposure. Their own code can be clean and the site can still be owned.

CVE-2026-109618, out of memory corruption

Advisory GHSA-w8hw-w9fx-j79w. Out of memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat that invalid data as valid. The corruption is reachable from request setup, which is why mod_php is the ugly case. The bug can fire before the interpreter hands the request to the application. Framework middleware, a WordPress must use plugin, and an application WAF written in PHP never get a chance to run. Memory disclosed down this class of bug can include credentials and tokens belonging to other requests or to the process itself.

The only complete fix is the patched release. PHP’s temporary guidance, which it says is incomplete, is to set memory_limit to unlimited, in a context the application cannot override, such as php_admin_value in the FPM pool or the Apache configuration, and to confirm no pool, directory, or app setting puts a finite limit back. That removes one controllable failure. An underlying allocation failure can still reach the vulnerable path. The project also recommends a low post_max_size (8M where uploads are unnecessary, otherwise 32M, with upload_max_filesize kept below it) and real limits at the proxy for decoded body size, field count, multipart part count, header count, and nesting depth, including requests that arrive without a usable Content Length. A cgroup or container limit that kills only the affected worker is an availability boundary. Do not substitute RLIMIT_AS or RLIMIT_DATA. Those can cause the allocation failure you are trying to avoid.

CVE-2026-109619, stale global state

Advisory GHSA-6wmf-4rv5-p3rp. Request-owned internal state can survive after its backing memory has been freed. A later request on the same worker may use that stale state before normal initialization resets it. This is a use after free in the engine, tracked by national advisories under CWE-416. Confirmed routes discussed by the project include session upload progress, which is enabled by default and does not require the application to call session_start(), and fatal error backtraces on PHP 8.5. Both bugs can be driven toward code execution or toward memory disclosure. The nickname PHP2Shell refers to the pair used together, not to a separate third CVE.

These steps are temporary and incomplete. Set session.upload_progress.enabled=0 in php.ini or in FPM or server configuration that applies before request parsing, then restart every worker. Do not rely on ini_set() or a per directory .user.ini. On PHP 8.5, fatal_error_backtraces=0 blocks the confirmed backtrace path only. Remove invalid or deprecated per request settings that emit diagnostics before initialization. Changing error_reporting, using @, or turning off display_errors does not protect you. Neither does “fixing” fatal errors an attacker can reach only inside application code you happen to control. Restart is part of the mitigation. A setting that the old workers never read again is a comment.

What will not save you

• CMSCore, theme, pluginNecessary hygiene. Orthogonal to a runtime RCE.
• WAFSignaturesUseful while you patch. Evadable, and not the advisory’s definition of safe.
• Hidedisplay_errorsThe project says this does not affect CVE-2026-109619.
• CLIthe version flag aloneThe binary in PATH and the SAPI serving the vhost are often different.

Inventory has to include PHP you did not install on purpose. cPanel and similar panels, WHMCS, phpMyAdmin, Nextcloud, Roundcube, Magento, old Laravel apps, CI images, and appliances that embed a libphp are all in the blast radius. The Dutch NCSC has been maintaining a community list of products that bundle PHP. CERT EU points operators at that list for a reason. “We do not run WordPress” is not a scoping statement.

Linux distributors and LTS vendors received the patches ahead of the public release. Prefer those packages where you have them, and read the changelog rather than trusting the major version. The PHP project warned that the volunteer Remi repository would not have packages the day of the release, and told anyone depending on it to switch to distribution builds or compile from source so they could move immediately. Windows builds are on the PHP downloads page next to the source tarballs. Minimal source backports, not full supported releases, were published for PHP 7.4, 8.0, and 8.1 for people who build from source or have no LTS vendor. Those branches are still end of life. Backport, then schedule the migration. Do not call a 7.4 backport a strategy.

What to do right away

1. List every place PHP accepts a request. Check FPM pools, mod_php, php cgi, LSAPI, FrankenPHP, containers, and any admin hostname on the same machine.
2. Record the version the site is actually running, from the SAPI, not only from the CLI binary on the host.
3. Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to the vendor package that names CVE-2026-109618 and CVE-2026-109619.
4. Restart PHP FPM, Apache, LiteSpeed, or the container. Then hit the site and confirm the new version. A package that is “installed” while old workers are still alive is not patched.
5. Prioritize anything on the public internet, then jump hosts, staging servers that were left open, and forgotten subdomains. Attackers do not prefer production out of courtesy.
6. If the box is on PHP 8.1 or older and you cannot get a backport on today, take it offline. CISA’s language is to take PHP based systems offline until they are patched or upgraded. Do that.
7. Treat WAF rules and the temporary ini settings as cover while step 3 finishes. Remove the temptation to call them the remediation in the ticket.
8. After the patch, look for occupants. New admin users, PHP files in upload directories, unfamiliar cron or scheduled tasks, and outbound connections the application has never made. Patching closes the door. It does not evict a person who already walked through it, and exploit attempts were reported before the fixes shipped.
9. Write down the version, the time, and the person who restarted the workers. You will be asked, by a customer or by your future self, and “we think so” is a bad sentence.

Prager’s own list is already closed. The servers we operate, and the client websites on them, are on the fixed PHP. That confirmation is the point of publishing this on the day of the advisory rather than after a quiet week.

Questions we expect

Sources checked October 21, 2026

• PHP project, security advisory, 21 October 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• CISA alert, Critical Vulnerabilities in PHP Require Immediate Patching, October 21, 2026
• UK NCSC, Critical security issue affecting PHP
• Canadian Centre for Cyber Security, AL26-026