The current security situation
On 21 October 2026, the PHP project released security updates for two critical vulnerabilities. Collectively known as PHP2Shell, they can, under certain conditions, allow an unauthenticated attacker to execute their own code on a server. Both carry a CVSS 4.0 score of 9.2 out of 10: critical severity. [1]
This warning is not about a single add-on or a particular online shop. The flaws are in PHP itself, a foundation shared by many different applications. [2]
The most important news for operators is that fixes are already available. The task is no longer to wait for an announced patch, but to update affected installations. [1][2]
What PHP has to do with a website
PHP is a programming language commonly used on web servers. It processes forms, queries databases and generates page content before that content reaches the browser. Other products may also include PHP. The UK's National Cyber Security Centre explains this role in its warning of 21 October 2026. [3]
Visitors normally never see this machinery. They see a shop, a blog or a customer portal. They do not need to know whether PHP is running underneath.
For operators, that information is essential. Looking after the visible website alone can leave a vulnerable runtime underneath it unnoticed.
The two flaws
The official identifiers are CVE-2026-109618 and CVE-2026-109619. CVE identifiers let administrators match a vulnerability to the right vendor information and updates.
Both problems concern memory handling and internal state. This is not simply a slow page or an ordinary crash. The official advisories describe the potential for executing an attacker's code. [4]
Operators do not need a detailed exploitation guide. The important point is that the fault sits below the website application itself.
| Vulnerability | A simplified explanation |
|---|---|
| CVE-2026-109618 | When memory runs out, PHP can interrupt processing before internal data has been fully initialised. Subsequent clean-up may treat that incomplete data as valid. |
| CVE-2026-109619 | Internal references can point to memory that has already been freed. When the same process handles another request, it may access that invalid state. |
What a successful attack could mean
Remote code execution, or RCE, means that an attacker can cause their own code to run from a distance.
That does not automatically give them full operating-system administrator privileges. Canonical describes possible PHP2Shell execution with the permissions of the affected PHP application. Further damage therefore depends on the configuration and the data accessible to that application. [5]
This is not reassurance. Even an application's ordinary permissions may allow it to read important files, use databases or change content.
Wiz's researchers also describe demonstrated ways to extract information from PHP process memory. That may contain passwords, access tokens or API keys. Their demonstrations used test installations of WordPress, Drupal and Joomla. Those applications were examples, not the limits of the vulnerabilities. [6]
An affected organisation could therefore face risks to confidentiality, integrity and availability at the same time: exposed data, altered content and disrupted services.
New websites can be affected too
The warning also covers previously current PHP releases that have not yet received the fixes. The PHP project explicitly includes installations handling web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
It identifies Apache with mod_php as particularly exposed. A demonstrated attack there can begin before application code runs. That does not make other deployment modes automatically safe. [2]
“Our website is new” does not answer the security question. Neither does using a well-known hosting control panel.
What matters is the PHP installation actually running the application, and whether that installation contains the fix.
Why updating WordPress alone is not enough
These vulnerabilities do not sit exclusively in WordPress, a theme or a plugin. Updating those components will not automatically fix PHP.
Cloudflare makes this distinction explicitly in its publication of 21 October 2026: the PHP software running the application must be updated. Where a hosting provider manages that software, the provider must supply the corrected version. [7]
Think of a building with a damaged load-bearing structure. New furniture may improve a room, but it does not repair the structure underneath.
Website maintenance therefore needs separate update processes for the application, its extensions and the server environment.
Public disclosure is not the date a flaw was introduced
The PHP project's public advance notice appeared on 20 October 2026. The corrected releases followed on 21 October. [1]
It would be inaccurate to describe this as a fault introduced into PHP today. Disclosure and the origin of a technical defect are different events.
The distinction between a vulnerable installation and a confirmed intrusion matters just as much. A vulnerable PHP version does not prove data has been stolen. Equally, a website loading normally does not prove that no attack has taken place.
What operators should establish now
I would start with three questions: Where is PHP running? Who is responsible for updating it? And what evidence confirms that the installation actually in use has been fixed?
For managed hosting, I would ask the provider. On a self-managed server, the responsible administrator needs to act.
A useful request would be:
Please confirm whether the PHP installations serving my websites have been updated against CVE-2026-109618 and CVE-2026-109619. Please identify the corrected package or release version and confirm that the running services are already using it.
That asks for a verifiable result. “We are looking into it” is an understandable first response, but not evidence that the work is complete.
My conclusion: Take it seriously without assuming an intrusion
PHP2Shell is a serious security situation. Its possible consequences go well beyond a temporary website outage.
It does not help to describe every PHP website as already compromised. Exposure, exploitability in a particular setup and confirmed compromise must remain separate.
For operators, the job is clear: identify the PHP environment in use, have the appropriate fix installed and verify that it is actually running. A modern-looking website is no substitute for that evidence.
Scope of this article
This article describes the published security situation at the stated research date. It is not an investigation of a particular website and does not claim that TNSystem has suffered an attack. Findings and vendor guidance may change.
Sources and further reading
Research date: 21 October 2026. Vendor statements and published investigations are not our own technical assessment of the systems described.
[1] CERT-EU: security advisory 2026-018
Read source ↗
[2] PHP project: security alert and corrected releases
Read source ↗
[3] NCSC: critical PHP security issue
Read source ↗
[4] Official PHP security advisories
Read source ↗
[4] Official PHP security advisories
Read source ↗
[5] Canonical: PHP2Shell and available Ubuntu fixes
Read source ↗
[6] Wiz Research: PHP2Shell investigation (participating company account)
Read source ↗
[7] Cloudflare: protection measures and limitations
Read source ↗
More articles in this series
PHP2Shell · Part 2
Read source ↗
PHP2Shell · Part 3
Read source ↗