On 21 October 2026 PHP released four emergency versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This was not routine housekeeping. They close two vulnerabilities named php2shell, tracked as CVE-2026-109618 and CVE-2026-109619, which allow code execution on the server without prior authentication. The US Cybersecurity and Infrastructure Security Agency asked that same day to apply the patch without delay (CISA, 2026).
Unauthenticated remote code execution sits at the very top of the list of things that can happen to a website. No stolen credentials. No hijacked session. No insider knowledge of the application. If the server exposes an affected version, the attacker sends instructions and the server runs them. Nothing to steal. Nothing to break.
This piece does not repeat the news. It answers what the news does not: how to find out whether you are exposed, what to do this week, and who owns each part of the work. If you run a technical team with websites on PHP, yours, your clients' or inherited ones, that is what sits in front of you, except that this time the calendar was not set by your quarterly plan but by someone publishing two CVEs on a Tuesday morning.
php2shell is a pair of PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that allow code execution on the server without authentication. They were disclosed on 20 and 21 October 2026 and the patch shipped on day 21 itself: the safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 in each branch (Huntress, 2026). CISA asked for immediate deployment because exploitation started within hours, not weeks. Below: how to audit which surfaces run PHP, in what order to patch, what to review afterwards (credentials, logs, webshells) and what NIS2 has to do with it if you operate inside the EU.
What php2shell is and why it was patched within 24 hours
The sequence was fast even by the standards of this kind of flaw. On 20 October the PHP project announced an out-of-band release for the following day; on the 21st, at 14:00 UTC, the technical details and the fixed versions came out almost together (Huntress, 2026). The window to inventory what was exposed before a public exploit existed was practically nil, and not because the PHP project did anything wrong, but because the surface inventory of an average organisation, split across platform teams, developers and a couple of external suppliers, does not happen in an afternoon or on good intentions.
The affected branches are the ones under active support: 8.2, 8.3, 8.4 and 8.5. The versions that close both CVEs are the four in the table. If any environment runs an 8.2 to 8.5 older than its own fixed version, that environment is in the risk zone, and it is so even if nobody has documented it, because the map of what runs in production and the map the team believes runs in production have been diverging for years in any company that has inherited systems, absorbed projects or integrated other people's teams.
| PHP branch | Fixed version (21 October 2026) |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
The difference between code execution that requires credentials and one that does not is the difference between an incident and a campaign. The first is exploited by whoever already broke in. The second is exploited by anyone. A script and a list of addresses are enough. Same day, at scale. That is why the CISA alert (2026) does not talk about potential risk, and why massive exploitation attempts against unpatched sites were being recorded within hours of the details going public (Help Net Security, 2026).
Why an AI found it, and what that means
The vulnerabilities were located in August 2026 with the help of AI-based analysis tools, as the incident chronicle records (Wikipedia, 2026). They had been there for years. Nobody had seen them. Nobody had looked at that scale.
A week before the patch, CNBC (2026) reported the other half of the same pattern: Mythos, the Anthropic model built to locate and demonstrate software weaknesses, had exposed enough flaws in Bank of America for the bank to announce the hiring of 1,000 external professionals supporting the internal patching team. A thousand people to remediate what one model found. The scale of the remedy, with heterogeneous environments, maintenance windows that do not belong to the security team and hosting providers with calendars of their own, is what turns a twenty-four hour notice into a multi-week problem for an average organisation.
The operational reading is not that AI will solve security. It is that AI has made finding flaws cheap, and the work that barely existed before, remediating them in time, now decides whether a company ends up on the victim list. Black Kite (2026) counted 7,551 organisations published as ransomware victims in 2026, 24.9% more than the previous year. Every exposed flaw feeds that machine, and the machine does not distinguish between those who patched on time and those who intended to patch once the sprint ended.
How to tell whether your site is exposed
The inventory is half the work. Five questions put it in order.
- Which PHP version each environment serves. Not the one the documentation claims: the one the server answers with. Public environments, forgotten staging boxes, old containers and that CMS nobody has touched since 2023.
- Whether any of them sits between 8.2 and 8.5 below the fixed version of its branch. 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are the cut-off (Huntress, 2026). Anything below that, exposed.
- What the hosting manages and what you manage. On shared or managed hosting the PHP engine is updated by the provider. The question is not whether the patch exists but when they apply it and whether they tell customers, because the provider's calendar and its notification policy decide more here than your own infrastructure documentation.
- What happens with WordPress and other CMSs. The vulnerability lives in the PHP engine, not in the CMS or its plugins: updating plugins does not patch php2shell. The site is covered when the server serves a fixed version, and not a minute earlier, and it is worth asking the provider in writing for the version served today and a committed update date.
- What runs on unsupported branches, such as PHP 7. Those versions will never receive this patch. The accumulated risk has no expiry date, and the reasonable way out is planning the migration.
What to do this week
- Update to the fixed versions across every inventoried surface, starting with the ones exposed to the internet. CISA (2026) does not soften the order: it asks for immediacy. No grace window.
- If some surface cannot be touched yet, shrink it or isolate it while the patch arrives, and watch what reaches it.
- Once patched, rotate credentials, API keys and secrets that lived on the server, and review access and execution logs for webshells: when execution has been possible without authentication, the patch closes the door but does not check who came in earlier. It is the part most teams skip, and the one that separates a clean closure from a latent incident that resurfaces in January.
- Verify with an external test. An applied patch is a claim; a test that tries to exploit the surface and fails is a fact, and it should be run by someone other than whoever applied the patch, because auditing your own work with your own hands is the most comfortable way of finding nothing.
And if your organisation delivers services inside the EU, vulnerability management of this kind is not a voluntary good practice: NIS2 treats it as a named obligation for a growing list of sectors, with deadlines that a bad week like this one can turn into a reportable incident.
The bottleneck is not the patch, it is who applies it
The patch is free. The time is not. It has been out for days, and what is scarce is the time of people able to inventory environments, update engines, review logs and sign off that the surface is closed. When that work piles up, the bill nobody budgeted appears: platform hours, development hours and review hours, all competing with the roadmap that was already committed before Tuesday.
The UK market was already tight before the event. According to Shakers market analysis, 1,929 of the 55,979 active technology job postings in the UK on 26 October 2026 mention cybersecurity, and not as a side duty of neighbouring roles but as an explicit requirement in the description. When two CVEs with an urgent patch land on a Tuesday, that demand does not wait for the annual hiring cycle: it gets covered with capacity that starts this week, not with a vacancy approved for next quarter.
For the inventory and the patching, teaming up with a senior PHP developer who has been through bulk version upgrades is the fast route. For what comes after, working with a cybersecurity expert who audits the surface and signs off what stayed closed. Integrating this capacity through a solid hiring infrastructure, with validated terms and no permanent headcount added, is the difference between covering a two-week emergency and carrying a fixed cost from January to December.
Frequently asked questions about php2shell
- Which PHP versions are safe after php2shell?
The ones released on 21 October 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, each in its own branch. Any environment running an earlier version of PHP 8.2 to 8.5 remains exposed to both CVEs, and unsupported branches such as PHP 7 have no patch.
- Is WordPress affected by php2shell?
The vulnerability is in the PHP engine, not in WordPress or its plugins. A WordPress site is covered when the hosting or the server serves a fixed version of PHP. Updating plugins and themes does not replace that patch.
- What does unauthenticated RCE mean?
That an attacker can get the server to run their code without a user, a password or a prior session. It requires no stolen credentials and no initial access: reaching the exposed URL is enough, which is why it lends itself to automated, mass campaigns.
- Is it being exploited already?
Yes. CISA asked for the patch to be applied immediately on 21 October 2026, and massive exploitation attempts against unpatched sites were being recorded in the hours after the details were published (Help Net Security, 2026).
- What if I cannot update this week?
Shrink the exposed surface in the meantime: restrict access to the affected endpoints, watch what reaches them and put a firm date on the patch. And if the system runs an unsupported branch, the patch will never arrive: the way out is planning the version migration.
