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

> PHP2Shell: two CVEs scored 9.2 out of 10 in PHP. What a CVE is, how to read a CVSS score, which PHP versions fix it and what to check on your site today.

Source: https://cittago.com/blog/what-is-a-cve-php2shell/  
Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011  
Published: 2026-10-23  
Language: en

---

**What we verified** — Checked 23 October 2026

- PHP2Shell is the name of two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both scored 9.2 out of 10 on CVSS 4.0.
- The PHP team fixed them on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and says updating is the only safe choice.
- PHP 8.1 and older no longer get official releases; for 7.4, 8.0 and 8.1 there are only minimal source patches and packages from some Linux distributions.
- A CVE is a unique public identifier for a known vulnerability; 48,244 CVE Records were published in 2025, according to cve.org metrics.
- On 23 October 2026 PHP2Shell was not in CISA's Known Exploited Vulnerabilities catalog; Amazon had reported an exploitation attempt on 17 October.
- According to W3Techs, on 23 October 2026 PHP was used by 69.3% of websites whose server-side language can be identified.

**A CVE is the public number of a security vulnerability. PHP2Shell is the name of two such numbers, CVE-2026-109618 and CVE-2026-109619, fixed in PHP on 21 October 2026, the language that runs WordPress, WooCommerce and Magento.** We explain, with examples, what the code and the score mean, who is affected and what to check on your own site, in the order it matters.

On 21 October 2026, the team that develops PHP released four new versions, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to fix two critical vulnerabilities publicly nicknamed PHP2Shell. Both score 9.2 out of 10 and can let someone with no account and no password run code on a website's server. The PHP team says updating is the only safe choice.

Not everyone has something to do. If your site sits on managed hosting, meaning the provider looks after the server and its updates, the fix is their job and you only check that it was done. If you run your own server, or a site on PHP 8.1 or older, the job is yours, and those branches no longer get official releases.

What you take away: what a CVE ID and a CVSS score mean, explained with PHP2Shell, a dated timeline, the table of fixed versions, two real messages from hosting companies and the steps to take, by you or your provider.

- You can read an ID like CVE-2026-109618 yourself and know what it does and doesn't tell you.
- You find out in a few minutes which PHP version your site runs.
- You know what to ask your host, with a message ready to send.
- The next CVE won't scare you: you'll know where to look.

1. [What happened on 21 October 2026](#what-happened)
2. [Two doors left open in the engine — what PHP2Shell is, the critical PHP vulnerability](#what-is-php2shell)
3. [A recall number for software — what a CVE is](#what-is-a-cve)
4. [What the year and the number tell you — how to read a CVE ID](#reading-a-cve-id)
5. [How bad is it? — the CVSS score, explained with PHP2Shell](#cvss-score)
6. [Severe doesn't mean attacked — EPSS and the CISA KEV catalog](#epss-and-kev)
7. [From August to 23 October — the PHP2Shell timeline](#timeline)
8. [Are you affected? — vulnerable and fixed PHP versions, WordPress included](#are-you-affected)
9. [Two messages from hosting companies — what a managed host that keeps up looks like](#hosting-messages)
10. [What to do today, in this order — how to check your PHP version and what to ask your host](#what-to-do-today)
11. [What each term is and isn't — a CVE, CVSS, EPSS, KEV and RCE glossary](#glossary)
12. [AI found the flaw. What it means for you — more CVEs, more often](#ai-found-it)
13. [Three thresholds, in this order](#three-thresholds)

1) Send your host the ready-made message from the “What to do today” section. 2) If your site runs PHP 8.1 or older, ask for a move to a supported version, or for written confirmation that the installed package includes the fix. 3) If you run your own server, update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP process.

## What happened on 21 October 2026

On 20 October 2026, an [advance notice](https://www.php.net/archive/2026.php) 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](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) 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](https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities), and CISA, the US Cybersecurity and Infrastructure Security Agency, [told organisations](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) 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](https://w3techs.com/technologies/details/pl-php), 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](https://cittago.com/blog/wp2shell-securitate-site-2026/), 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](https://wiz.io/blog/php2shell-php-rce) 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](https://www.php.net/archive/2026.php#2026-10-21-5), 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.

*One server can host dozens or hundreds of websites. When its PHP is updated, every site using it is fixed; if the server offers several PHP versions, each one has to be patched.*

## 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](https://www.cve.org/About/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](https://www.cve.org/ResourcesSupport/FAQs): 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](https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-107260) and EUVD-2026-107265.

### Figure: Almost 200 CVEs a day in the first half of 2026

The number of CVE Records published each year, according to the programme's official metrics. For 2026, the first half (H1) only, January to June.

*Almost 200 CVEs a day in the first half of 2026*

|   | CVE Records published |
| --- | --- |
| 2019 | 17,308 |
| 2020 | 18,375 |
| 2021 | 20,161 |
| 2022 | 25,059 |
| 2023 | 28,961 |
| 2024 | 40,077 |
| 2025 | 48,244 |
| 2026 H1 | 35,872 |

Source: Source: cve.org, published CVE Record metrics, read on 23 October 2026 · 2026 = January–June · cittago.com

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.

*CVSS severity bands, per FIRST's 4.0 specification — the third column is our reading for a website*

| Score | Band | What it means in practice |
| --- | --- | --- |
|   | None | No impact |
| 0.1–3.9 | Low | Goes into the next routine update |
| 4.0–6.9 | Medium | Schedule it, no panic |
| 7.0–8.9 | High | Fix it soon |
| 9.0–10 | Critical | Fix it now; PHP2Shell scores 9.2 |

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](https://www.theregister.com/security/2026/10/22/php2shell-exploit-bypasses-protections-designed-to-stop-remote-code-execution/5304883), 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](https://cittago.com/blog/woocommerce-social-login-cve-2026-8457/).

*A 9.2 out of 10 is a serious problem, to fix now. It does not say whether anyone is actually attacking: for that there are two other signals.*

## 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](https://www.first.org/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](https://www.cisa.gov/known-exploited-vulnerabilities-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](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/) 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](https://sansec.io/research/php2shell) 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.

*PHP2Shell, step by step — times in UTC*

| Date | What happened | Source |
| --- | --- | --- |
| 1 August 2026 | Calif finds the first code execution paths | Sansec |
| 11 August 2026 | Calif reports the first bug to the PHP team | Sansec |
| 24 August 2026 | Wiz reports the vulnerabilities to the PHP team | Wiz |
| 21 September 2026 | The PHP team acknowledges the reports and starts a coordinated fix | Wiz |
| 17 October 2026 | An exploitation attempt, seen on an Amazon decoy server | Amazon |
| 20 October 2026 | php.net announces the critical release; details leak | php.net, Sansec |
| 21 October, 03:02 | Cloudflare switches on firewall rules for PHP2Shell, Free plan included | Cloudflare |
| 21 October, 13:30–14:00 | PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | php.net, ENISA |
| 21 October 2026 | CISA alert; EU joint statement (European Commission, ENISA, CERT-EU, Europol EC3, CSIRTs Network); watchTowr reports exploitation on its decoy servers; Ubuntu publishes fixed packages | CISA, ENISA, watchTowr, Ubuntu |
| 22 October 2026 | Sansec: public exploits fail on a default installation | Sansec |
| 23 October 2026 | PHP2Shell still not in the KEV catalog | CISA |

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.

*Which release fixes PHP2Shell, branch by branch — per php.net, read on 23 October 2026*

| PHP branch | Fixed release | Official security support |
| --- | --- | --- |
| 8.5 | 8.5.12 | until 31 December 2029 |
| 8.4 | 8.4.27 | until 31 December 2028 |
| 8.3 | 8.3.36 | until 31 December 2027 |
| 8.2 | 8.2.35 | until 31 December 2026 |
| 8.1, 8.0, 7.4 | no official release; minimal source patches only | ended |
| 7.3 and older | nothing from the PHP team | ended |

Old branches are the big problem. For PHP 8.1 and older, the [PHP project no longer publishes releases](https://www.php.net/archive/2026.php#2026-10-21-5). 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.

### Figure: Almost half run branches with no official fixed release

The PHP branch run by the websites whose version W3Techs can see. Branches 8.2–8.5 got releases fixing PHP2Shell on 21 October 2026; 8.1 and older did not.

*Almost half run branches with no official fixed release*

|   | % of PHP sites with a visible version |
| --- | --- |
| PHP 7.x | 26.9% |
| PHP 8.3 | 22.8% |
| PHP 8.2 | 18.0% |
| PHP 8.1 | 9.9% |
| PHP 8.4 | 7.9% |
| PHP 5.x | 7.7% |
| PHP 8.0 | 3.8% |
| PHP 8.5 | 2.9% |

Source: Source: W3Techs, 23 October 2026, PHP sites with a visible version · PHP 8 sub-versions, Cittago calculation · cittago.com

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](https://ubuntu.com/security/CVE-2026-109618) 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](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/): 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](https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities) 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](https://github.com/NCSC-NL/php2shell) 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.

*With good hosting, they ring the bell before you have to.*

## 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.

“Hello, could you please confirm in writing whether the server hosting [your domain] has the fixes for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) applied, since when, and which PHP version my site runs now? Thank you!”

## 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.

*The glossary of a security alert, using PHP2Shell as the example*

| Term | What it is | What it is NOT |
| --- | --- | --- |
| CVE | The unique public ID of a vulnerability, such as CVE-2026-109618 | It doesn't say how severe it is or whether it concerns you |
| CVSS | The severity score, from 0 to 10; PHP2Shell scores 9.2 | It isn't the probability of an attack |
| EPSS | The probability of exploitation in the next 30 days | It isn't a guarantee, it's a statistical estimate |
| KEV | CISA's catalog of vulnerabilities with evidence of exploitation | Not being listed doesn't mean there are no attack attempts |
| RCE | Remote code execution: the server runs the attacker's commands | It isn't password guessing: the attacker doesn't need yours |
| Exploit | A program or method that actually takes advantage of a vulnerability | Not every published exploit works; Sansec says the public ones for PHP2Shell fail on a default installation |
| Zero-day | A vulnerability exploited before a fix exists | Not every critical flaw is a zero-day; PHP2Shell saw attempts before the fix, but it isn't known whether any succeeded |
| Patch | The official fix; here, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | It doesn't apply itself, and it doesn't clean a server that is already compromised |
| WAF | A web application firewall, filtering dangerous requests before they reach the site | It doesn't replace the patch: it blocks known patterns, not the vulnerability |
| Temporary settings | memory_limit=-1 (no memory limit), a low post_max_size, session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0 | The PHP team says they reduce exposure but do not make an installation safe |

One WAF that made a difference: [Cloudflare switched on PHP2Shell rules](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) 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](https://cittago.com/blog/cloudflare-cdn-firewall-2026/).

## 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](https://cittago.com/services/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](https://www.php.net/archive/2026.php#2026-10-21-5) · [GitHub · GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) · [GitHub · GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) · [PHP · Supported versions](https://www.php.net/supported-versions.php) · [CISA · 21 October alert](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) · [CISA · KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) · [ENISA · EU joint statement](https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities) · [NCSC-NL · Products that contain PHP](https://github.com/NCSC-NL/php2shell) · [cve.org · FAQs](https://www.cve.org/ResourcesSupport/FAQs) · [cve.org · Metrics](https://www.cve.org/About/Metrics) · [FIRST · CVSS 4.0](https://www.first.org/cvss/v4.0/specification-document) · [FIRST · EPSS](https://www.first.org/epss/) · [ENISA · EUVD-2026-107260](https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-107260) · [Amazon · MadPot](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) · [watchTowr · PHP2Shell](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/) · [Cloudflare · WAF rules](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) · [Sansec · PHP2Shell](https://sansec.io/research/php2shell) · [Wiz · PHP2Shell](https://wiz.io/blog/php2shell-php-rce) · [The Next Web · Calif and OpenAI](https://thenextweb.com/news/php2shell-php-rce-ai-openai-wiz) · [The Register · VulnCheck](https://www.theregister.com/security/2026/10/22/php2shell-exploit-bypasses-protections-designed-to-stop-remote-code-execution/5304883) · [Ubuntu · CVE-2026-109618](https://ubuntu.com/security/CVE-2026-109618) · [W3Techs · PHP](https://w3techs.com/technologies/details/pl-php) · [W3Techs · PHP 8](https://w3techs.com/technologies/details/pl-php/8)

## Questions and answers

**What does CVE stand for?**

CVE stands for Common Vulnerabilities and Exposures. It is a naming system, not a database: it gives each known security problem a unique public ID that vendors, security firms, hosting companies and government agencies then use to refer to exactly the same issue.

**What is a CVE?**

A CVE is a unique public identifier, in the form CVE-YEAR-NUMBER, assigned to a known security vulnerability so everyone talks about the same problem. The programme has run since 1999, operated by MITRE and sponsored by CISA. The ID doesn't say how severe the vulnerability is; the CVSS score does.

**What is PHP2Shell?**

PHP2Shell is the public name of two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both score 9.2 out of 10 on CVSS 4.0 and can let an attacker with no account run code on a website's server. The PHP team says updating is the only safe choice.

**Which PHP versions fix PHP2Shell?**

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 8.1 and older get no official release; there are minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions ship fixed packages under a different version number.

**Is WordPress affected by PHP2Shell?**

Yes, indirectly: WordPress runs on PHP, and the vulnerability is in PHP, not in WordPress. Updating WordPress, your theme or your plugins doesn't fix it. The PHP on the server has to be updated, by you or by your hosting company.

**How do I check my PHP version?**

In WordPress, on the Site Health page, Info tab, Server section, you see the full version. In cPanel or Plesk you usually see only the branch, such as 8.3. If the number is below the fixed release, ask your host: some packages include the fix without changing the version number.

**Is PHP2Shell a zero-day?**

Not clearly. Amazon saw an exploitation attempt on 17 October 2026, four days before the fixes, but said it was unclear whether such attempts would succeed on real systems. On 23 October 2026, PHP2Shell was not in CISA's Known Exploited Vulnerabilities catalog.

**Is PHP2Shell being exploited?**

There are signals: Amazon saw an exploitation attempt on 17 October 2026, watchTowr says it has observed exploitation since 21 October on its decoy servers, and VulnCheck says it has a working exploit that it hasn't made public. On 23 October 2026, CISA had not added PHP2Shell to its KEV catalog, and Sansec wrote that the public exploits do not work against a default installation. The advice remains to update.

**Why is it called PHP2Shell?**

A shell is a server's command line. “Getting a shell” means being able to run commands on the server as if you were its administrator, which is what a successful attack on these two flaws can allow. The name echoes earlier vulnerabilities such as Log4Shell (2021) and React2Shell (2025).

**What is the difference between CVE, CVSS and KEV?**

The CVE is the name of the problem, CVSS is its severity score and KEV is CISA's list of vulnerabilities with evidence of exploitation. A CVE can have a critical score without being in the KEV catalog, as PHP2Shell was on 23 October 2026.

---

Cittago · https://cittago.com · digital marketing, SEO, AI search, Google Ads and web development for small and medium companies in Romania, Italy and the EU.