PHP2Shell Explained: Critical Cybersecurity Flaw Putting Websites at Risk

PHP2Shell Explained: Critical Cybersecurity Flaw Putting Websites at Risk

A serious cybersecurity issue affecting PHP, one of the most widely used programming languages for building websites, has triggered an urgent response from technology companies, hosting providers and organisations around the world.

The vulnerabilities, commonly referred to as PHP2Shell, were disclosed on October 21, 2026. Security researchers warned that attackers could potentially exploit vulnerable PHP installations to execute malicious code on affected servers, access sensitive information or disrupt online services.

The discovery prompted organisations to investigate their systems, apply security updates and, in some cases, temporarily take services offline while checking for potential exposure.

But what exactly happened, why does it matter, and what should website owners do to protect themselves?

Let's break it down.

What is PHP, and why does this vulnerability matter?

PHP is a server-side programming language used to build and operate dynamic websites and web applications. Unlike HTML, which structures the content displayed in a browser, PHP can process information on a server, communicate with databases, handle forms, manage user sessions and generate the pages visitors see.

It powers popular platforms and applications, including WordPress websites, online stores and applications built with frameworks such as Laravel and Symfony.

For example, when you log in to an online shopping website, PHP might help verify your account, retrieve your order history and display your personal dashboard.

Because PHP runs behind the scenes on so many websites, a serious flaw in the language itself can have consequences far beyond one website or one company.

The important point is that PHP2Shell affects the underlying PHP runtime, not simply a particular WordPress plugin or website theme.

What is PHP2Shell?

PHP2Shell is the name used for two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619.

Both received severity scores of 9.2 out of 10 under the Common Vulnerability Scoring System (CVSS), indicating a critical security risk.

In simple terms, the flaws involve how PHP handles memory when certain errors occur while processing requests.

A computer program temporarily uses memory to store and process information. If an error interrupts that process and the program handles the affected memory incorrectly, it can leave behind an unsafe state.

Under certain conditions, an attacker could take advantage of these mistakes to execute code remotely on a vulnerable server without first logging in.

Here's a simplified explanation of the two original vulnerabilities.

1. CVE-2026-109618: A memory-handling failure

The first vulnerability involves PHP encountering an out-of-memory condition while processing a request.

In certain circumstances, PHP may be interrupted before internal data has been fully prepared. Subsequent cleanup operations can then handle that incomplete data incorrectly.

An attacker who successfully exploits the flaw could potentially gain the ability to execute malicious code on the affected server.

2. CVE-2026-109619: Memory that should no longer be used

The second vulnerability involves a problem commonly known as a use-after-free error.

Imagine a computer program using a temporary storage space and then releasing it when the information is no longer needed. If part of the program continues to refer to that released memory, it may end up using information that is no longer valid.

Under the right conditions, this can create a security weakness that attackers may exploit.

These descriptions simplify complex programming errors, but the central issue is straightforward: mistakes in PHP's internal memory management could potentially allow an unauthorised person to interfere with a server.

What could happen if a website remains vulnerable?

The consequences depend on the server configuration, the vulnerable PHP component and the attacker's ability to exploit the flaw.

Potential impacts include:

• Unauthorised code execution: An attacker may be able to run malicious instructions on the server.

• Exposure of sensitive information: Information stored in server memory or accessible to the compromised process could be at risk.

• Website disruption: A successful attack could crash services, damage application availability or interrupt business operations.

• Further compromise: Depending on the server's permissions and security controls, an attacker may attempt to install malicious files, establish persistence or reach other resources.

For businesses, the consequences can extend beyond a website going offline. A compromised server may expose customer information, interrupt online sales, damage trust and create costly recovery work.

However, it is important to distinguish between a vulnerability and a confirmed breach. A vulnerable website is at risk, but that does not automatically mean it has been hacked.

Why did the issue trigger such an urgent response?

One of the main concerns was that the vulnerabilities existed in PHP itself and could potentially be triggered before an application had a chance to apply its own security checks.

That makes the issue particularly important for organisations running internet-facing PHP services.

The UK's National Cyber Security Centre urged organisations to identify systems running PHP, prioritise exposed systems and install the appropriate security updates.

Reports also described organisations temporarily restricting access to certain services while assessing and addressing their exposure.

This type of precaution does not necessarily indicate a successful cyberattack. Sometimes, temporarily limiting access is a responsible way to reduce risk while a security team verifies that systems are safe to operate.

Another concern was the speed at which attackers can respond to publicly disclosed vulnerabilities. Once technical details and proof-of-concept demonstrations become available, organisations may have only a limited period to secure exposed systems before attack attempts increase.

That is why applying security patches promptly is so important.

How did hosting providers respond?

The incident also highlighted the role hosting providers play in protecting websites.

A hosting provider operates the infrastructure on which websites run. Depending on the hosting arrangement, it may be responsible for maintaining PHP, updating server software, filtering malicious traffic and managing other security controls.

Hostinger reported that it deployed protections against the PHP2Shell vulnerabilities, including firewall rules intended to block known attack patterns and patched PHP builds across its managed hosting infrastructure.

According to Hostinger's October 23 update, its managed hosting plans, excluding VPS, had received the relevant protections. Customers managing their own PHP environments on VPS servers were instructed to take action themselves.

Hostinger also reported addressing a third PHP vulnerability, CVE-2026-115560, disclosed on October 23. This additional issue requires separate consideration from the original two vulnerabilities.

These measures illustrate an important principle: effective security often requires several layers of protection.

A firewall may block known malicious requests, while a patched PHP runtime addresses the underlying software defect. Neither should automatically be treated as a substitute for the other.

Hosting arrangements differ, however, so website owners should confirm their provider's current security advisory and the status of their own server rather than assuming every hosting account has been updated.

What should website owners do now?

If you own a website, the most important step is to establish which PHP environment your site uses and whether it has received the relevant security fixes.

1. Check your PHP version and hosting environment

Contact your hosting provider or open your hosting control panel to identify the PHP version running your website.

Do not assume that a website is safe simply because it loads normally or displays the correct PHP version number. Some providers apply security patches to their managed builds without changing the displayed version in the way you might expect.

Ask your provider to confirm that the relevant PHP2Shell fixes have been applied.

2. Update PHP to a fixed version

For the original vulnerabilities, the PHP project released fixed versions including:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

Choose an appropriate patched version supported by your application and hosting environment. Check your application's compatibility before upgrading, and back up important files and databases.

These versions address the original two vulnerabilities. Because an additional issue was disclosed on October 23, administrators should also check the latest PHP security advisories and confirm that their chosen build addresses all relevant issues.

3. If you manage a VPS, do not assume the provider has updated PHP for you

A virtual private server gives you greater control over the operating system and software, but it also places more responsibility on you or your system administrator.

If you manage PHP yourself, install the appropriate security updates and restart the relevant PHP workers or services as required.

For the additional vulnerability CVE-2026-115560, PHP's published guidance included temporarily disabling session upload progress:

session.upload_progress.enabled = Off

This setting must be applied in the appropriate PHP configuration, such as php.ini or the relevant PHP-FPM pool configuration, followed by restarting the affected PHP workers. Setting it with ini_set() in application code is not an equivalent mitigation.

This is a temporary mitigation for the relevant attack path, not a replacement for installing the appropriate security fix.

If you are not comfortable managing a server, contact a qualified administrator or your hosting provider before changing production configuration.

4. Keep WordPress, plugins and themes updated

Updating WordPress, its plugins and its themes is essential for overall website security. However, updating WordPress alone does not fix a vulnerability in the PHP runtime.

Both layers need attention: the server software and the application running on it.

Remove plugins and themes you no longer use, obtain updates from trusted sources and investigate any unexpected changes to your website.

5. Review logs and investigate suspicious activity

If your website was running an exposed PHP installation, ask your hosting provider or security administrator to review relevant server logs and investigate indicators of compromise.

Look for unusual processes, unexpected PHP files, unfamiliar administrator accounts, suspicious outbound connections or changes to important website files.

Do not assume that updating PHP automatically removes malware if an attacker had already compromised the server.

If you discover signs of a breach, preserve relevant logs, isolate affected systems where appropriate and seek professional incident-response assistance.

6. Maintain reliable backups

Keep recent backups of your website files, databases and essential configuration, preferably with copies stored separately from your production server.

Test that your backups can be restored. A backup that has never been tested may not be useful when you need it most.

Backups will not prevent an attack, but they can help reduce downtime and support recovery after an incident.

What about the third vulnerability disclosed on October 23?

The initial PHP2Shell disclosure concerned CVE-2026-109618 and CVE-2026-109619. On October 23, the PHP project disclosed an additional vulnerability, CVE-2026-115560.

This distinction matters because a security update addressing the original vulnerabilities should not automatically be assumed to resolve a subsequently disclosed issue.

The additional vulnerability involves a particular combination of PHP configuration and application behaviour. The PHP project's interim guidance included disabling session upload progress while a complete fix was being addressed.

Administrators should therefore review the latest official PHP security announcements and applicable vendor advisories, rather than relying solely on an article or announcement published earlier in the incident.

For the latest technical information, consult the official PHP security announcements and the UK National Cyber Security Centre's advisory.

Does this mean every PHP website has been hacked?

No. This is an important distinction.

The existence of a critical vulnerability does not mean every affected website has been compromised. It means the affected software may contain a weakness that an attacker could exploit under the relevant conditions.

Similarly, reports of attempted exploitation do not establish that every attempt was successful.

Nevertheless, organisations should not wait for evidence of a successful attack before applying the appropriate security updates. Preventive action is generally safer and less expensive than responding after a compromise.

What this incident means for developers and businesses

The PHP2Shell incident is a reminder that website security extends beyond the code a developer writes.

A website may have well-designed forms, secure authentication, carefully implemented permissions and regularly updated plugins, yet still depend on vulnerable server software.

Developers should understand their application's runtime requirements, test security updates, remove unnecessary components and coordinate with whoever manages the hosting infrastructure.

Businesses should know who is responsible for patching their servers, how quickly critical updates are applied and how suspicious activity is investigated.

For organisations running multiple websites, it is also important to maintain an inventory of applications and server environments. You cannot reliably secure systems you do not know exist.

These practices are valuable well beyond PHP2Shell. They form part of a consistent approach to vulnerability management and operational security.

Final thoughts

The PHP2Shell vulnerabilities demonstrate how a flaw deep inside a widely used programming language can create security concerns for businesses, developers and website owners around the world.

The good news is that security updates and other protective measures have been made available for the original vulnerabilities. The next step is ensuring that the appropriate fixes have actually been applied to every relevant environment, including servers managed independently by their owners.

If your website runs PHP, verify your hosting provider's response, apply the appropriate updates, maintain reliable backups and investigate any suspicious activity.

The key lesson is simple: keeping a website secure means protecting not only the application visitors see, but also the software and infrastructure running behind it.

This article is for general information and cybersecurity awareness. Security advisories and affected configurations can change as new information becomes available. Consult official PHP and hosting-provider guidance before making production server changes.

Sources and further reading

• PHP official security announcements

• UK National Cyber Security Centre: Critical security issue affecting PHP

• Hostinger: Protecting against PHP2Shell