CVE-2026-109618 isn't a code for programmers. It's an alarm for anyone with a PHP website

What happened on 21 October 2026

On 20 October 2026, an advance notice appeared on php.net, PHP's official site: the next day at 14:00 UTC, a security release would fix two critical vulnerabilities, both scored 9.2 out of 10. No details yet. All PHP users were urged to prepare.

The secrecy didn't quite hold. Details of the two flaws reached the internet ahead of time, and Amazon later reported that one of its decoy servers had logged an exploitation attempt, meaning an attempt to actually use the flaw, as early as 17 October. On 21 October, around the scheduled time, PHP published the fixed versions.

The same day, the European Commission, ENISA, CERT-EU, Europol's EC3 and the EU network of national incident response teams issued a joint statement, and CISA, the US Cybersecurity and Infrastructure Security Agency, told organisations to inventory every system running PHP, including PHP embedded in other software, to patch internet-facing systems first, and to take systems offline if they cannot be updated promptly or still run PHP 8.1 or older.

The two vulnerabilities have official IDs, CVE-2026-109618 and CVE-2026-109619, and a nickname, PHP2Shell. If your site runs on WordPress, WooCommerce, Magento, Drupal or Laravel, they concern you directly, because all of these run on PHP. The awkward part: the fix does not install itself, and on shared hosting you do not install it either. Whoever runs the server does.

To know what to do, you need three things: to know what PHP2Shell is, to understand what a CVE tells you, and to find out which PHP version you run and who manages it. We take them in that order.

Two doors left open in the engine — what PHP2Shell is, the critical PHP vulnerability

PHP2Shell is the public name of two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, which can let an attacker with no account run code on a website's server.

PHP is the programming language that runs on the server and builds each page before it reaches the visitor's browser. WordPress, WooCommerce, Magento and Drupal are built on it. According to W3Techs, on 23 October 2026 PHP was used by 69.3% of websites whose server-side language can be identified.

A shell is a server's command line, where the administrator types instructions. In security jargon, “getting a shell” means being able to give the server orders as if you were its administrator. The name echoes Log4Shell (2021) and React2Shell (2025), other vulnerabilities with “shell” in the name that also gave attackers access to the server. In July 2026 we wrote about the wp2shell alert, a WordPress flaw with a similar name.

In practice, these are two different mistakes in the way PHP manages memory.

• CVE-2026-109618, code execution through memory corruption. When PHP runs out of memory in the middle of a request, it abandons the request abruptly. Some data is left half-prepared, and the clean-up at the end may treat it as valid. An attacker who deliberately exhausts the memory, for instance with a specially crafted file-upload request, can slip their own instructions in. Picture a waiter who runs out of trays mid-order and leaves the ticket half-written; at closing time, the till reads it as a complete order.
• CVE-2026-109619, code execution through leftover state. PHP keeps a few pieces of information from one request to the next. Sometimes they point to memory that has already been freed, and the next request handled by the same process may use them before they are reset. It is like a hotel room handed to the next guest with the previous guest's notes still on the bedside table.

Two details make PHP2Shell more serious than most. First, it has nothing to do with your site's own code. Wiz, one of the companies that found the vulnerabilities, writes that even a “Hello World” app, the simplest page possible, can be vulnerable on an affected version. Second, on Apache servers with mod_php, the PHP team demonstrated an attack that starts before a single line of the application runs, which is why it considers the risk highest there.

According to the official advisory, every PHP installation serving web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. You don't need to know which one you have; they are all affected. The confirmed impact is code execution with the web worker's privileges, which means access to the site's files, usually including the ones that hold the database passwords. That is what RCE, remote code execution, means: the attacker doesn't guess your password, they make the server run their commands.

A recall number for software — what a CVE is

A CVE is a unique public identifier, in the form CVE-YEAR-NUMBER, assigned to a known security vulnerability so that anyone in the world can refer to exactly the same problem.

CVE stands for Common Vulnerabilities and Exposures. A vulnerability is a mistake in a piece of software that someone can use to do something they shouldn't: read data, get in without a password, take control.

The easiest way to picture it is a car recall. When a manufacturer finds a brake defect, the recall campaign gets a number, and the manufacturer, the garage, the insurer and the owner all talk about that number without describing the defect every time. A CVE does the same for software: your host, the vendor, a security scanner and a national cyber security agency all say “CVE-2026-109618” and know exactly what is meant.

The CVE Program has existed since 1999. It is operated by MITRE, a US non-profit, and sponsored by CISA. The IDs, though, are not handed out by a single body. On 23 October 2026, according to cve.org metrics, 559 organisations from 43 countries assigned them. They are called CNAs (CVE Numbering Authorities) and include software vendors, security firms and national incident response teams.

One thing cve.org states plainly: CVE is not a database, it is a naming system. Technical details, scores and fixes live elsewhere: in the vendor's advisory and in two public databases, the US NVD (National Vulnerability Database) and the European EUVD (European Vulnerability Database), run by ENISA, the EU's cybersecurity agency. In the EUVD, the two PHP2Shell IDs appear as EUVD-2026-107260 and EUVD-2026-107265.

The volume tells its own story. 48,244 CVE Records were published in 2025, more than 130 a day on average. In the first six months of 2026 there were 35,872, almost 200 a day. A business owner cannot read 200 alerts a day, and doesn't need to: what they need is to hear quickly about the ones that concern them.

What the year and the number tell you — how to read a CVE ID

Take CVE-2026-109618, the first PHP2Shell vulnerability. It has three parts.

• CVE is the fixed prefix. It only says this is an identifier from the CVE Program.
• 2026 is the year in the ID. It reflects when the ID was reserved or made public, not when the problem was discovered. With PHP2Shell the two happen to fall in the same year: the flaw was found in August 2026 and published in October.
• 109618 is the sequence number, at least four digits long. It is not a ranking, nor the number of vulnerabilities that year; it is simply the number reserved for this ID.

Next to the ID, a CVE Record carries a description, the affected products and links to the official advisories. It can also carry a status: RESERVED (details not public yet), DISPUTED (someone disagrees that it is a vulnerability) or REJECTED (to be ignored). And it leaves out two things: how severe the problem is, and whether it concerns you. The first is what the CVSS score is for. For the second, you need to know which version you run.

How bad is it? — the CVSS score, explained with PHP2Shell

CVSS stands for Common Vulnerability Scoring System. It is maintained by FIRST, the global forum of incident response teams, and gives each vulnerability a score from 0 to 10. PHP2Shell's scores use version 4.0 of the system. Think of it as triage in an emergency room: it tells you how serious the case is, not whether you are the patient.

The score comes from a string describing the attack. For both PHP2Shell vulnerabilities the official PHP advisories give the same one: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. It looks like a password, but it reads piece by piece. AV:N: the attack comes over the network, from anywhere on the internet. PR:N and UI:N: no account needed and no click from you. VC:H, VI:H, VA:H: if it succeeds, the impact on the server is high: an attacker can read data, change it and stop the service.

That leaves AC:H, a hard attack, because FIRST's specification says success depends on evading or circumventing protections already in place, and AT:P, because it needs deployment and execution conditions that are not present everywhere. They say the attack isn't trivial to pull off, yet the score stays in the critical band. And hard is not impossible. According to The Register, on 22 October 2026 the security firm VulnCheck said it had built a working exploit for CVE-2026-109618 overnight. An exploit is a program that actually takes advantage of a vulnerability.

This one works on PHP 8.4.26, an unpatched version, with PHP's recommended production settings, and it bypasses ASLR, a standard protection that randomly shuffles memory addresses. It is not public, and VulnCheck itself warns against confusing technical difficulty with protection. If you want to see a CVSS 3.1 string decoded on a different case, we did it for a WooCommerce plugin flaw in August 2026.

Severe doesn't mean attacked — EPSS and the CISA KEV catalog

CVSS measures how much damage a vulnerability can do. It doesn't measure how likely it is to be used. Two other tools do that, and both are free.

EPSS (Exploit Prediction Scoring System) is another FIRST project. It estimates the probability that a vulnerability will be exploited in the next 30 days. On 22 October 2026, CVE-2026-109618 stood at 5.3% and CVE-2026-109619 at 5.8%. That looks low, but it placed them above 92–93% of all vulnerabilities EPSS scores.

KEV (Known Exploited Vulnerabilities) is CISA's catalog of vulnerabilities with evidence of exploitation in the real world. On 23 October 2026 it held 1,754 entries, and PHP2Shell was not among them. In its 21 October alert, CISA wrote that it had not observed exploitation at the time of publication.

The nuance that matters: an attack attempt is not a successful attack. Amazon saw an attempt on 17 October on a honeypot, a server deliberately left in plain sight to attract attackers and study their methods. watchTowr says it has observed exploitation of both vulnerabilities since 21 October, again on its own network of decoy servers, without saying whether any compromise followed. And Sansec wrote on 22 October that the public exploits do not work against a default PHP installation, and that mass exploitation now looks less likely than it did on release day. All three can be true at once. The practical conclusion stays the same: you update.

From August to 23 October — the PHP2Shell timeline

The timeline shows how a CVE usually lives: discovery, a quiet report to the vendor, a fix under embargo, meaning a period when details stay secret until the fix exists, then simultaneous publication. With PHP2Shell, the secrecy didn't fully hold: details leaked on 20 October, the day before publication.

One date worth remembering: 17 October. Amazon recommends starting investigations from there, not from the disclosure date. If you run your own server, that is where you start reading the logs.

Are you affected? — vulnerable and fixed PHP versions, WordPress included

The short answer: yes, if your site runs PHP, which is almost certain if it is built on WordPress or a similar platform (a CMS, or content management system). The long answer depends on the version.

Old branches are the big problem. For PHP 8.1 and older, the PHP project no longer publishes releases. For 7.4, 8.0 and 8.1 its security team still made minimal source patches available for people who build PHP themselves, and some Linux distributions and extended-support vendors ship fixed packages. For 7.3 and below, the PHP team published nothing, although Wiz says the vulnerabilities go back as far as PHP 5.4, from 2012.

Watch 8.2 as well: it has a fixed release, 8.2.35, but its security support ends on 31 December 2026. A move to 8.3 or later is worth planning now.

The figures come from W3Techs, which can only count sites whose version is visible from outside, so they are not a census. They do point clearly in one direction: 48.3% of the PHP websites measured run a branch for which the PHP project published no fixed release. That doesn't automatically make them vulnerable, since some got fixes through their distribution or their host. It means you can't know without asking.

A common trap is the version number. On Ubuntu 24.04, for example, the fixed PHP doesn't show up as 8.3.36 but as package 8.3.6-0ubuntu0.24.04.13, the one Ubuntu lists for CVE-2026-109618: the distribution backported the fix into its own version without changing the main number. On Ubuntu 22.04, PHP 8.1 got the fixed package 8.1.2-1ubuntu2.28, even though the PHP project no longer publishes releases for 8.1. So an “8.3.6” on your server isn't necessarily bad news, and “8.3.36” is not the only good number.

And for WordPress and WooCommerce: updating your theme or plugins does not fix PHP2Shell. Cloudflare says so directly in its write-up: the flaw is in the PHP runtime, so the PHP running the application has to be updated.

PHP doesn't only live in websites, either. The EU joint statement of 21 October warns that many commercial and open-source products use PHP under the hood and may be affected even if they don't appear to use it. The Dutch National Cyber Security Centre (NCSC-NL) keeps a public list of such products. The statement advises patching internet-facing systems first and, where that can't happen right away, isolating exposed applications from public networks.

Two messages from hosting companies — what a managed host that keeps up looks like

The good thing about a CVE is that anyone can track it. A serious hosting company does it for you: it has people reading the alerts, knows which versions run on its servers and tells you, before you ask, whether you have anything to do. After the PHP2Shell fixes came out we received two messages of this kind, in Romanian, which we translate here. We don't name the companies; what interests us is the kind of message.

The first appeared as a pop-up in the customer panel. It named both IDs, CVE-2026-109618 and CVE-2026-109619, said the company had updated every server with an active technical support and administration option to the PHP versions that include the fixes, and ended with the sentence every customer wants to read:

“No action is required on your part.”

It is short and has everything it needs: it names the problem, says what was done and who has nothing to do. It also has a detail that is easy to miss: the automatic update covered servers with administration. Someone with an unmanaged server, usually a VPS (virtual private server) they run themselves, gets only the infrastructure from the same company. There, updating PHP is their job.

The second was an announcement in the customer portal, dated Wednesday, 21 October 2026. The company wrote that it was aware of the vulnerabilities identified in PHP and was constantly monitoring the release of relevant updates. It then described two stages: the necessary security measures had been implemented at server level and the available patches applied; patches specific to each PHP version in use would follow as they became available.

Less spectacular, but honest: it says openly that the fix comes in stages and that some PHP versions would get their patch after 21 October. On a server offering several PHP versions, fixes can arrive one by one, some straight from PHP, others from Linux distributions or the makers of hosting control panels. The message doesn't describe the server-level measures, so a customer on a version not yet patched would do well to ask when their turn comes.

From the two, you can draw a short checklist. Faced with a critical CVE, a good message from your host:

• names the problem, ideally with the CVE IDs, not just “a security issue”;
• says what has already been done, and when;
• says what comes next, if the fix has stages;
• says clearly who has to do something and who doesn't.

That is the practical difference between managed hosting and hosting you run yourself. It is not that a good host never has vulnerabilities; everyone does, because PHP does. It is that someone keeps up with them for you, and you find out from a three-line message, not from a headline. If by 23 October 2026 you have heard nothing from your host, the message in the next section takes a minute to send.

What to do today, in this order — how to check your PHP version and what to ask your host

The first three steps and the last one are for you. Steps 4–6 are for whoever runs the server: you, if you have your own, or your hosting company.

1. Find out which PHP version the site runs. In cPanel or Plesk you usually see only the branch, such as 8.3, not the last digits. You see the full version in WordPress, on the Site Health page, Info tab, Server section, or you ask your host.
2. Compare it with the table above. 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later means a fixed release. A lower number isn't automatically a problem if your host confirms a package with the fix included.
3. On managed or shared hosting, read your host's messages. If you have received nothing, ask for written confirmation using the message below.
4. On a server you run yourself, the PHP packages get updated and every PHP process restarted. A process that hasn't been restarted keeps running the old code from memory.
5. If updating has to wait, the temporary measures from the php.net advisory get applied and a web application firewall (WAF, a filter in front of the site) goes in front. The temporary measures reduce the risk, they don't remove it; the exact list is in the official advisory. CISA notes that a WAF may offer partial protection until patching is complete.
6. The server logs get checked, starting from 17 October. The signs described by Wiz and Amazon: unusual file-upload requests followed by memory errors or repeated 500 errors, unexpectedly large session cookies (PHPSESSID), and requests containing the string PHP_SESSION_UPLOAD_PROGRESS. If they show up, tell your host or administrator straight away and keep the logs.
7. Check your backup. It is not a defence against PHP2Shell. It is the plan for the case where something already got through.

What each term is and isn't — a CVE, CVSS, EPSS, KEV and RCE glossary

Security alerts mix their terms easily. The table puts them side by side, with what each one does and, above all, what it doesn't.

One WAF that made a difference: Cloudflare switched on PHP2Shell rules on 21 October at 03:02 UTC, more than 10 hours before the fixed releases came out, Free plan customers included. It helps, but Cloudflare itself writes that PHP must be updated and recommends keeping the firewall on while you patch. If you want to know what a firewall like Cloudflare's actually does, we covered it in Cloudflare explained simply.

AI found the flaw. What it means for you — more CVEs, more often

PHP2Shell also has a new angle. Security firm Calif found the first of the vulnerabilities in August 2026, during an audit of PHP's source code funded by OpenAI through its Patch the Planet programme, working with the GPT-5.6 Sol model. Wiz reached the same problems independently a few weeks later, using GPT-5.6 Sol, Google's Gemini 4 Argon and its own tools. Cloudflare lists those who disclosed them: Calif, Wiz, OpenAI and Quarkslab.

This is not a machine that found the flaw on its own. The people at Calif and Wiz used AI as a tool, and Calif said, quoted by The Next Web, that no model simply unearths “all bugs” with simple prompts. Wiz writes that the models greatly reduced the effort of adapting exploits to different versions, configurations and memory layouts.

We don't know how much of the growth in CVEs comes from AI. We only know the volume has grown: almost 200 a day in the first half of 2026, against roughly 132 a day in 2025. For a business owner, the conclusion is simple: security updates become routine, not events. It matters less to follow every alert and more to have someone, in your team or at your host, following them for you.

Three thresholds, in this order

Not a conclusion, a triage. Stop at the first threshold you fail.

First: do you know which PHP version your site runs? If not, find it in WordPress or ask your host. Without the version, every alert is just noise.

Second: is it a fixed version? 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or a package your provider confirms. If you are on PHP 8.1 or older, this threshold is also a question about migrating: old branches no longer get official releases, for any CVE.

Third: who hears first, next time? If the answer is “me, from the news”, you have a risk that has nothing to do with PHP. Your host, an administrator or a provider should hear before you do and tell you whether you have anything to do.

With Cittago's managed hosting, the servers are looked after by people who keep up with alerts like this one, and server security updates are not the customer's job. If you'd rather it stopped being your concern, that is what our managed hosting is for. You don't need us if your host has already confirmed to you, in writing, that the server is updated: it means they are doing exactly what they should.

Let's talk about this again in 3–6 months 😉

Questions with answers we think are useful

The questions that come naturally to anyone who has seen a CVE ID in an alert and wants to know whether it concerns them.

Last updated: 23 October 2026. The PHP advisories (php.net and GitHub), the CISA alert, cve.org metrics, the KEV catalog, EPSS scores, the EUVD records, Ubuntu's CVE page and W3Techs data were read on 22 and 23 October 2026. The two hosting messages were received by us, in Romanian, and are translated here; we don't name the companies. What changed in the 23 October 2026 update: we added the EU joint statement of 21 October and the NCSC-NL list of products that contain PHP, links to the official sources inside the text, and the release time of the fixes, which differs slightly between sources (13:30–14:00 UTC); we rechecked the KEV catalog, where PHP2Shell still does not appear. The exploitation picture is moving fast. We update this page when new information comes in.

Sources: PHP · Security advisory · GitHub · GHSA-w8hw-w9fx-j79w · GitHub · GHSA-6wmf-4rv5-p3rp · PHP · Supported versions · CISA · 21 October alert · CISA · KEV catalog · ENISA · EU joint statement · NCSC-NL · Products that contain PHP · cve.org · FAQs · cve.org · Metrics · FIRST · CVSS 4.0 · FIRST · EPSS · ENISA · EUVD-2026-107260 · Amazon · MadPot · watchTowr · PHP2Shell · Cloudflare · WAF rules · Sansec · PHP2Shell · Wiz · PHP2Shell · The Next Web · Calif and OpenAI · The Register · VulnCheck · Ubuntu · CVE-2026-109618 · W3Techs · PHP · W3Techs · PHP 8