PHP2Shell: what the critical PHP flaws are, how serious they are, and what to do

This article covers what is known as of 22 October 2026. The story is still moving, and attack data in particular can change within hours. I have tried to mark which statements come from official sources and which come from a security company's own claims.

On 21 October 2026 the PHP team released an emergency update that fixes two critical vulnerabilities. They are CVE-2026-109618 and CVE-2026-109619, and both score 9.2 on the CVSS 4.0 scale. According to PHP, they can allow unauthenticated remote code execution. Security people call the event "PHP2Shell". Reuters reports that some government websites in Europe went offline and that Wikimedia, which runs Wikipedia, took some systems down.

The short version: the flaws are real and serious, a fix exists, and the fix is an update. The phrase "the whole internet is under threat" is only half true. The rest of this article explains why.

What is PHP and why does it matter?

PHP is a programming language that runs on the server side of websites. When a page reaches your browser, PHP has often prepared it first: pulled the text from a database, dropped it into a template, turned it into HTML. Think of a restaurant kitchen. You only see the plate at the table, while PHP cooks in the back.

According to W3Techs on 22 October 2026, 69.3% of sites with a known server-side language use PHP. WordPress, Drupal, Joomla and Laravel all run on it. That is why the flaw is not in a WordPress plugin but in the interpreter underneath WordPress. On the same W3Techs page, 65.3% of PHP sites are on the PHP 8 series, 26.9% on PHP 7 and 7.7% on PHP 5. Roughly a third of PHP sites are therefore on series that no longer get support.

What happened: two days in brief

In Huntress's account, a social media post on the morning of 20 October claimed that two critical PHP flaws were about to be announced. The post was removed, but screenshots spread. watchTowr confirmed it was a leak and said the disclosure was supposed to wait until Thursday. The PHP team posted an advance notice the same day for 21 October at 14:00 UTC and reserved the right to release earlier if details became public or exploitation appeared.

According to CERT-EU, the fixes shipped at 13:30 UTC on 21 October, slightly ahead of plan. That evening researchers from Calif and Wiz published technical details. Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images of the day. Those were demonstrations in controlled test environments.

What exactly is the flaw? An explanation without the jargon

In one sentence: PHP sometimes trusts information it believes it has cleaned up, but which is actually half-finished or left over. An attacker can abuse that trust with data they prepared themselves.

Let me unpack that. PHP hands every visitor request on your site to a "worker". While working, the worker uses the computer's memory like a notepad. When the job ends, it tears out the pages, which means it frees the memory. Both flaws come from that collecting and clearing going wrong somewhere.

• CVE-2026-109618, when the notepad fills up: If the notepad runs out, the worker drops the job halfway. A page is left half written, but the cleanup step treats it as complete and processes it. Handling a half-finished page wrongly can open a door for an attacker.
• CVE-2026-109619, the leftover: When a job ends the pages are thrown away, but the worker may still carry the address of those pages in its pocket. When the next request to the same worker looks at that address, something else may now be sitting there. If an attacker prepared that something, the result is dangerous.

This is called "unauthenticated remote code execution". The attacker does not need an account on your site. A specially crafted request sent over the internet can be enough, and the server may run the command the attacker wants. That amounts to losing control of the server.

According to PHP, the riskiest setup is Apache's mod_php module. There the attack can fire even before your site's own code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also among the affected setups.

In JFrog's account, one of the routes goes through a feature that feeds the progress bar while a file uploads, and that feature is on by default. This is why one of the interim measures is to switch it off. Wiz also showed that passwords and keys can be reached just by "reading the worker's notepad", without running any code. That is Wiz's own claim and demonstration.

Who is affected?

• Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older builds of 8.5, 8.4, 8.3 and 8.2 are vulnerable.
• PHP 8.1 and older no longer get updates from the PHP project. Some Linux distributions and long-term-support vendors supply their own patches. The PHP team also offered minimal source backports for 7.4, 8.0 and 8.1 for people who build from source.
• Sites that do not use PHP are not directly affected, because the flaw is in the PHP interpreter. The DonanımHaber story says platforms that are not PHP-based, such as Squarespace and Wix, are not affected in the same way. You cannot always know whether a service you use runs PHP behind the scenes.
• The runtime is the problem, not the application. Updating WordPress, plugins or a theme does not close the hole on its own. PHP itself has to be updated and the services restarted.
• Distributions may apply the fix without changing the version number. Looking at the php -v output is not enough; check the vendor's security notice.

Wiz's research says releases back to PHP 5.4 were affected. According to CyberScoop, CERT-EU also wrote that PHP 5 and later could be affected. watchTowr notes that this scope is not officially confirmed, and PHP's advisory gives no list for old releases. Since there is no definitive list for unsupported series, the safest assumption is that all of them are vulnerable.

Is it overblown? What should you believe?

The evidence for seriousness is strong. Neither flaw needs authentication, PHP itself says a working exploit exists, independent researchers demonstrated code execution in leading software, and CISA and CERT-EU issued urgent warnings. The report that government sites went offline is not an empty sign of panic either. Those agencies judged that taking a system down was cheaper than leaving it open until a patch was in.

There is also some exaggeration, and most of it clusters around exploitation status and numbers.

• Reports of attacks conflict. CISA said it had not observed exploitation at the time of publication. Huntress said that on 21 October it saw none on the systems it can see. Patchstack said hosting partners reported "multiple active exploitation incidents", but later that afternoon its own telemetry showed only scanning and probing. Cloudflare's CTO said early attacks were appearing. watchTowr said it saw exploitation on its honeypot network, which is the company's own observation. None of this says "the internet is down", and none of it says "nothing is happening".
• The numbers do not agree. CyberScoop cites more than 1.3 million internet-exposed hosts and about 1.9 million on Shodan. According to Censys data relayed by Reuters, about 1.5 million of 2.6 million hosts reporting a PHP version run one with no fix. VirusTotal counted, among servers that disclose their version, about 758,000 on PHP 5.4 through 8.1, which are unsupported, and about 272,000 on supported branches. These are counts of servers that are exposed. They do not mean every one can be exploited, because the affected versions are officially limited and configuration changes the outcome.
• Fake exploit code is circulating. JFrog reported that some supposed proof-of-concept repositories on GitHub are fake, and one hides a command that changes the desktop wallpaper. Security firms also warn that such code can carry malware. Do not try it on your own server.
• There are commercial interests in the story. Companies that used AI models in the discovery, such as OpenAI and Wiz, present it as a success for their products. That may be true, but it is not a measured result.

My reading is this. The headline phrase "threatens the whole internet" is accurate if it means unpatched PHP servers, and not accurate for patched ones. For an ordinary user there is nothing to panic about. For anyone running PHP, though, there is no reason to wait on the theory that their turn will not come. With flaws like these, exploitation tends to speed up after technical details become public. Here the details are already out.

The AI angle: why it got so much attention

What sets this event apart is how the flaws were found. Calif researchers were working with an OpenAI model under OpenAI's "Patch the planet" initiative, and Wiz reached the same problems independently with its own tools. According to Wiz's own write-up, Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol were used during the research, and the models helped work through complex exploit chains and adapt them to different setups. As relayed by CyberScoop, Wiz says the bug sat in the code for decades and was hard to exploit, and that AI lowers that difficulty. That should be read as the company's own assessment.

The practical meaning is a sense of direction more than a proven number. Large, old and complex codebases hold bugs that went unnoticed for a long time, and finding them may have become cheaper than before, for defenders and attackers alike. That makes the patch window, the time between the announcement and your own update, the critical thing.

What should an ordinary user do?

If you have no website, there is little to do, and staying calm is part of it. A few sensible steps remain.

• Read security notices from the services you use. If a service says data may have leaked from memory or asks you to reset passwords, take it seriously and change yours.
• Do not reuse a password across sites, and turn on two-step verification where you can. A password leaked from one site's server will work on others if you reused it.
• Do not click "urgent security update" emails or links that use the flaw as a pretext. Scam attempts rise around events like this.
• If a site is in maintenance or offline, that can be a sign it is applying the patch. The alternative is usually worse.
• Updating your browser or phone does not close this hole; it is on the server side. The most effective protection on your side is account security.

What should site owners do?

This group has the real work. In order:

• Take an inventory. Which server runs which PHP version? Do not forget PHP that ships embedded in other software. CISA also recommends inventorying every system, embedded PHP included.
• On shared hosting, write to your provider: when will they apply the PHP patch, and have they? If the control panel lets you move your PHP version to a supported, patched series, do it.
• If you run your own server, update the packages and then restart Apache, PHP-FPM and any long-running workers. The restart is essential; installing packages alone does not update the running process. Qualys recommends confirming that both the installed packages and the running processes include the fix after patching.
• If you use Docker, rebuild your image on a patched base and redeploy. Check that tags do not point at an older release.
• On PHP 8.1 or older, ask your vendor for a patch or move to a supported version. If you cannot, take the server off the internet, put it behind a VPN or firewall, and apply the interim measures below. CISA recommends taking PHP-based systems offline if patching is not possible.
• On PHP 8.2, patch, but plan ahead: according to the PHP notice, security support for 8.2 ends on 31 December 2026.

If you cannot patch right away, PHP's own advisory lists interim measures. It says plainly that they "reduce exposure to specific attack paths but do not make an installation safe". The sample settings below follow the advisory's guidance.

; php.ini (applied before request parsing)
memory_limit = -1            ; ideally via php_admin_value in the FPM pool
post_max_size = 8M           ; 32M if uploads are required
upload_max_filesize = 8M     ; must stay below post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; PHP 8.5 only
; Restart every PHP worker after changing these

A few notes. Setting memory_limit to -1 removes the per-request memory cap and raises the risk of resource exhaustion, so it has to go back to a finite value after patching. Do not use RLIMIT_AS or RLIMIT_DATA for a memory limit, because they can trigger the vulnerable path; a container or cgroup limit is recommended instead. Apply settings through php.ini, an FPM pool or server configuration, not ini_set() or .user.ini. These measures close only the confirmed paths, not other variants.

Cloudflare switched on an initial set of WAF rules for all customers, free plans included. Cloudflare itself calls it a stopgap. According to Patchstack, that protection only helps if your server takes traffic exclusively through Cloudflare. Also do not trust fake plugins that claim to close the hole, or code snippets copied from the internet; Patchstack warns against those too.

If you think you were hit

These signs are hints, not proof: unusually large or malformed PHPSESSID cookies, memory-limit errors or repeated HTTP 500s after multipart upload requests, and unexplained worker crashes or restarts. Wiz notes that neither their presence nor their absence proves anything. The more concrete monitoring suggested by CISA and Huntress is PHP worker processes launching shells or download tools. If you suspect a compromise, isolate the server, preserve web server and PHP logs, look for new files in the web root, scheduled tasks, new user accounts and web shells, and rotate the passwords and keys on that server.

Where could this go?

This section is interpretation and speculation, not established fact.

In the short term, the most likely picture is more automated scanning of visible servers that have not been patched. Fastly's Kelly Shortridge says that if widespread exploitation comes, it could arrive within hours to days (as relayed by CyberScoop). At that pace, some servers that do not update could be taken over quickly. The ones hurt first are likely to be sites on unsupported PHP versions that nobody looks after. By the VirusTotal count above, most servers that reveal their version are already on old series.

In the medium term, two things look likely. The first is new variants. PHP's interim measures close only confirmed paths and say nothing about other variants. Wiz writes that PHP's patch addresses the underlying problem and other variants too, so the patched release is a far sturdier option than interim settings. The second is old versions. Unpatched, unsupported PHP installs may turn out to be the most lasting effect of this event. PHP 8.2 losing support at the end of December already puts the next urgent-update pressure on the calendar.

In the long term, the real debate is how the speed of AI-assisted discovery will change the rhythm of defence. As things stand, the secrecy window between finding a flaw and announcing it is very open to leaks. In this case the window shrank by a day because of a leak. I think the most likely lesson is that patching processes, automatic updates and retiring old versions will have to be taken more seriously.

Short checklist

• Find out your PHP version and your hosting provider's patch status.
• Patch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package.
• Restart all PHP and web server services after updating.
• On 8.1 and older: a patched vendor package or an upgrade; until then, take the server off the internet.
• Interim settings are not a patch; undo the memory_limit change after patching.
• Beware of fake fix plugins, fake exploit code and fake security emails.
• Do not reuse passwords, and turn on two-step verification.

Sources

1. PHP.net: Security advisory, 21 October 2026 (accessed: 2026-10-22)
2. PHP.net: Upcoming Critical PHP Security Release, 20 October 2026 (accessed: 2026-10-22)
3. CERT-EU: Critical Vulnerabilities in PHP (2026-018) (accessed: 2026-10-22)
4. CISA: Critical Vulnerabilities in PHP Require Immediate Patching (accessed: 2026-10-22)
5. Qualys: PHP2Shell, PHP Patches Two Critical RCE Vulnerabilities (accessed: 2026-10-22)
6. Huntress: Rapid Response, php2shell (accessed: 2026-10-22)
7. Patchstack: Major security alert, PHP vulnerable to critical RCE (accessed: 2026-10-22)
8. JFrog Security Research: PHP2Shell, all you need to know (accessed: 2026-10-22)
9. Wiz Research: PHP2Shell (accessed: 2026-10-22)
10. watchTowr: PHP Remote Code Execution FAQ (accessed: 2026-10-22)
11. CyberScoop: PHP releases emergency fixes for 2 critical vulnerabilities (accessed: 2026-10-22)
12. Reuters (via US News): Explainer, What Is PHP and Why Did It Take Government Websites Offline? (accessed: 2026-10-22)
13. W3Techs: Usage statistics of PHP (accessed: 2026-10-22)
14. DonanımHaber (Turkish): What is PHP and why is it threatening the whole internet? (accessed: 2026-10-22)

Images: Original graphics made for this article; they contain no photographs or third-party logos.