Millions of websites rely on PHP to operate. From small business websites and online shops to customer portals and enterprise applications, PHP powers some of the most widely used systems on the internet.
On 21 October 2026, security researchers disclosed two critical vulnerabilities in PHP that raised serious concerns across the global cybersecurity community.
The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell.
Both vulnerabilities have received a critical severity rating of 9.2 under the Common Vulnerability Scoring System (CVSS 4.0).
More importantly, successful exploitation could allow an attacker to execute malicious code on a vulnerable web server without needing a username or password.
The UK’s National Cyber Security Centre (NCSC) has issued an official security alert urging organisations to take immediate action.
For businesses running websites built with WordPress, WooCommerce, Laravel, Joomla, Drupal or other PHP-based technologies, this is a security issue that deserves immediate attention.
However, it is important to distinguish between a website being potentially vulnerable and a website actually being compromised.
In this guide, we explain what happened, which websites may be affected, how to identify your PHP version, what you should do to protect your website and how to recognise potential signs of an attack.
What Is PHP2Shell?
PHP2Shell is the name used to describe two critical security vulnerabilities discovered in the core PHP runtime.
PHP is a server-side programming language used to build dynamic websites and web applications.
When you visit a WordPress website, for example, PHP processes information on the server, retrieves content from a database and generates the page displayed in your browser.
The vulnerabilities affect how PHP handles certain memory-related conditions during request processing.
Under specific circumstances, an attacker can exploit these weaknesses to interfere with the execution of PHP processes.
In a successful attack, this could allow malicious commands to run on the affected server.
The two vulnerabilities are:
CVE-2026-109618: Memory Corruption During Out-of-Memory Handling
This vulnerability involves the way PHP handles a situation where a process encounters an out-of-memory condition.
Normally, PHP should terminate the affected operation safely.
However, researchers discovered that certain error-handling conditions could leave internal request data partially initialised.
When PHP subsequently attempts to clean up that request, it may access invalid memory.
An attacker who can deliberately trigger these conditions may be able to manipulate the resulting memory corruption and achieve remote code execution.
CVE-2026-109619: Stale Memory References
The second vulnerability involves internal PHP state that can retain references to memory after that memory has already been released.
A later request processed by the same PHP worker may access this stale information before the internal state is properly reset.
This can also create conditions that allow memory corruption and potentially remote code execution.
Although these technical details are important for developers and system administrators, business owners should understand one essential point:
A vulnerable PHP installation may expose a website to attacks that do not require the attacker to know any login credentials.
That makes prompt remediation especially important.
Why Is This Cybersecurity Issue So Serious?
Cybersecurity vulnerabilities are discovered regularly.
Some affect individual plugins, specific applications or unusual server configurations.
PHP2Shell is particularly significant because it affects the PHP runtime itself rather than only a single website plugin or application.
PHP is used by a substantial part of the web ecosystem.
A vulnerability at this level can potentially affect many different applications that depend on the same underlying technology.
Attackers May Not Need to Log In
Many traditional website attacks involve stolen passwords, compromised administrator accounts or vulnerable plugins.
PHP2Shell introduces a different concern.
Depending on the server configuration and the conditions required for exploitation, an attacker may be able to target the PHP runtime directly through specially crafted web requests.
This means a strong administrator password alone cannot eliminate the vulnerability.
Two-factor authentication remains essential, but it does not replace security updates.
A Successful Attack Could Affect More Than Your Website
If an attacker manages to execute code through a vulnerable PHP process, the consequences depend on the permissions available to that process and the server’s security configuration.
Possible consequences include:
- Unauthorised modification of website files.
- Theft of accessible customer or business information.
- Installation of malicious scripts or backdoors.
- Website defacement or malicious redirects.
- Disruption of services.
- Compromise of accessible credentials and configuration files.
- Attempts to gain further access to connected systems.
These are potential outcomes, not evidence that every vulnerable website has experienced them.
The actual impact depends on the attack, server configuration, access restrictions and additional security controls.
Which PHP Versions Are Affected?
The vulnerabilities affect PHP releases preceding the emergency security updates published on 21 October 2026.
The following versions contain the relevant security fixes.
| PHP branch | First fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Older PHP versions, including PHP 8.1 and earlier, are outside the PHP project’s normal security support lifecycle.
Organisations using older branches should migrate to a supported version or obtain verified vendor-supported security backports where available.
Important: A PHP version that was considered recent or secure before 21 October 2026 may still be vulnerable.
For example, PHP 8.3.30 is an earlier release than the corrected PHP 8.3.36.
Website administrators should verify their installed PHP build and applicable vendor patches rather than assuming a server is protected because it received updates earlier in the year.
Some Linux distributions and hosting providers may apply security backports without changing the main version number. In these cases, check the vendor’s security advisory and installed package release before deciding whether the system remains vulnerable.
Source: CERT Coordination Center — PHP Memory Corruption Vulnerabilities.
Does PHP2Shell Affect WordPress Websites?
Yes. WordPress websites running on vulnerable PHP installations may be exposed.
However, there is an important distinction.
PHP2Shell is not fundamentally a WordPress vulnerability.
It affects PHP, the underlying technology used to execute WordPress.
This means updating WordPress itself does not necessarily resolve the issue.
A website could have:
- The latest WordPress version.
- Fully updated plugins.
- A modern security plugin.
- Strong administrator passwords.
- Two-factor authentication.
- A valid SSL certificate.
And still run on a vulnerable version of PHP.
This is why website security must extend beyond the WordPress dashboard.
The hosting environment, PHP runtime, web server, database access controls and operating system all form part of a website’s security infrastructure.
What About WooCommerce?
WooCommerce operates within WordPress and therefore relies on the PHP environment hosting the website.
A vulnerable PHP installation could potentially expose the underlying server.
For ecommerce businesses, the consequences of a serious server compromise may be particularly disruptive because the website often handles customer accounts, orders, business information and integrations with payment providers.
Using an established payment gateway reduces the need to store sensitive card details directly, but it does not eliminate the need to secure the website and hosting environment.
If you operate a WooCommerce store, verify the server’s PHP security status with your hosting provider or technical administrator.
Are Laravel Websites Vulnerable?
Laravel applications also rely on PHP.
Therefore, a Laravel application running on an affected PHP runtime may be exposed even when the Laravel framework and application dependencies are fully updated.
Updating Composer packages alone will not fix a vulnerability in the PHP runtime.
The appropriate remediation requires updating or patching PHP within the actual environment executing the application.
This distinction is especially important for businesses operating custom portals, SaaS platforms and bespoke applications.
How to Check Whether Your Website Uses an Affected PHP Version
You do not need to be an experienced developer to begin checking your website.
The appropriate method depends on the platform and hosting service you use.
Method 1: Check PHP in WordPress
If your website uses WordPress:
- Log in to your WordPress dashboard.
- Open Tools → Site Health.
- Select the Info tab.
- Expand the Server section.
- Locate the PHP version.
You should see a version number such as PHP 8.2, 8.3, 8.4 or 8.5.
Compare this with the fixed versions listed earlier.
For example, if your website reports PHP 8.3.30, you should contact your hosting provider to determine whether security patches have been applied.
Do not assume the version number alone proves whether vendor backports are present.
Method 2: Check Through cPanel
Many shared hosting providers use cPanel.
If your hosting account includes PHP management tools:
- Log in to cPanel.
- Look for MultiPHP Manager or Select PHP Version.
- Find the domain you want to inspect.
- Check which PHP version is assigned to it.
The available PHP versions depend on your hosting provider.
Some providers display only the major and minor PHP branches rather than the complete installed patch version.
If the interface shows only PHP 8.3, for example, ask your hosting provider to confirm the exact patched runtime version.
Method 3: Ask Your Hosting Provider
If you cannot identify the PHP version yourself, contact your hosting provider.
You can send the following message:
Subject: Urgent PHP2Shell Security Patch Confirmation
Hello,
Following the disclosure of CVE-2026-109618 and CVE-2026-109619 on 21 October 2026, could you please confirm whether the PHP runtime used by my website has been patched against both vulnerabilities?
Please also confirm the installed PHP version or applicable vendor backport, and whether any action is required from my side.
Thank you.
A reliable hosting provider should be able to explain the patch status of the environment running your website.
If they cannot confirm whether the relevant security fixes have been applied, the issue should be escalated.
Method 4: Check a Dedicated Server or VPS
If you manage your own server, your system administrator should identify every PHP runtime used by your websites and applications.
A basic command such as:
php -v
can display the PHP version available through the server’s command-line interface.
However, the command-line version is not necessarily the version serving your website.
A server may contain multiple PHP installations, different PHP-FPM pools, separate virtual hosts or custom application runtimes.
An administrator should verify the actual runtime serving each website and review the relevant distribution or hosting-vendor security advisories.
Avoid creating publicly accessible PHP information pages solely to check versions, as these can reveal sensitive server configuration details.
What Should Website Owners Do Right Now?
If your website uses PHP, the following actions provide a practical starting point.
1. Confirm the PHP Patch Status
Find out which PHP runtime your website uses.
Check whether the installation includes the corrections for both disclosed vulnerabilities.
Do not rely entirely on the WordPress update screen or the version shown in a hosting dashboard.
Where vendor backports are used, request confirmation from the provider.
2. Apply the Official Security Updates
If your PHP installation is affected, arrange for the relevant security update to be installed as soon as possible.
The patched PHP versions announced on 21 October 2026 include:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
Use a supported branch compatible with your application and obtain packages through trusted official or vendor-maintained channels.
Do not switch major PHP versions blindly on a production website.
A PHP upgrade can expose compatibility problems in older WordPress plugins, themes or custom application code.
Where possible, take a verified backup, test application compatibility and complete the upgrade through a controlled process.
For a critical vulnerability affecting an internet-facing system, avoid unnecessary delays.
3. Check for Evidence of Compromise
Applying a security patch addresses the underlying vulnerability.
It does not automatically remove malicious files or backdoors that may have been installed before patching.
If your website was exposed, your administrator should assess whether there are signs of unauthorised access.
Depending on the environment, this may involve examining:
- Web server and application logs.
- Unexpected changes to website files.
- New administrator accounts.
- Unrecognised scheduled tasks.
- Suspicious outbound network connections.
- Unusual server processes.
- Modified configuration files.
- Security alerts from monitoring tools.
Absence of obvious symptoms does not guarantee that a server has not been compromised.
If there are credible indications of a breach, preserve relevant evidence and seek qualified incident-response assistance.
4. Verify Your Website Backups
Every business website should have reliable backups.
For a WordPress website, a useful backup generally includes the database, uploaded media, themes, plugins and important configuration files.
For bespoke applications, recovery may also depend on deployment configuration, storage, databases, application secrets and external services.
A backup is only useful if it can be restored successfully.
Make sure your business has:
- Regular automated backups.
- Copies protected from unauthorised alteration or deletion.
- Suitable off-server or independently protected storage.
- A documented restoration process.
- Periodic restoration tests.
If your server has already been compromised, do not assume the newest backup is clean.
Backups should be assessed before restoration.
5. Review Access to Your Hosting Environment
Although PHP2Shell is not primarily a password-related issue, compromised credentials can make an attack more damaging.
Review access to:
- Your hosting control panel.
- Website administrator accounts.
- SSH and SFTP services.
- Database administration tools.
- Domain registrar accounts.
- Cloud infrastructure dashboards.
Remove accounts that are no longer required and enforce multifactor authentication wherever it is supported.
Use separate accounts rather than sharing administrator credentials.
6. Do Not Rely on a Firewall Alone
A web application firewall can be an important additional defence.
It may help block malicious requests, reduce automated attacks and provide useful monitoring information.
However, a firewall does not repair vulnerable PHP code.
Attack techniques and filtering rules can change, and a firewall may not detect every exploit attempt.
The primary solution remains applying the appropriate PHP security patches.
Where patching is temporarily impossible, system administrators should follow the official PHP Foundation mitigation guidance and assess whether the affected system must be isolated or taken offline.
What If You Cannot Update PHP Immediately?
Some businesses depend on older websites or applications that cannot easily run on newer PHP releases.
This is particularly common with legacy custom software, old WordPress plugins and applications that have not been maintained for several years.
If your website cannot be upgraded immediately, simply leaving it online and hoping that attackers will ignore it is not a responsible security strategy.
You should involve your hosting provider or a qualified system administrator.
Temporary mitigations have been published by the PHP security team, but they involve technical changes to runtime configuration and request processing.
These mitigations may reduce exposure without providing complete protection.
They can also affect application functionality or server stability if implemented incorrectly.
The UK NCSC advises organisations that cannot patch or apply suitable mitigations to consider taking vulnerable systems offline until they can be secured.
For business-critical software, it may be necessary to create a short-term isolation plan while preparing a supported upgrade.
Official guidance: UK NCSC — Critical Security Issue Affecting PHP.
How Can You Tell If Your Website Has Been Hacked?
A compromised website does not always display an obvious warning.
Sometimes an attacker wants the website to keep operating normally while malicious activity remains hidden.
Nevertheless, some symptoms deserve investigation.
Unexpected Website Redirects
Visitors may be sent to unfamiliar websites, suspicious advertisements or fraudulent pages.
These redirects can sometimes affect only certain visitors or search engine traffic, making them difficult for the website owner to reproduce.
Unknown Administrator Accounts
A newly created WordPress administrator account that nobody recognises should be investigated.
Attackers sometimes create additional accounts to maintain access.
Modified Website Files
Unexpected changes to application files or unknown PHP scripts may indicate a compromise.
Not every unfamiliar file is malicious, so suspicious files should be investigated before deletion.
Unusual Server Activity
Repeated process crashes, unexpected network activity, unexplained resource consumption or abnormal application errors can indicate several different problems, including security incidents.
These symptoms are not proof of exploitation, but they may justify a closer examination.
Search Engine Security Warnings
Google and browser security services may sometimes identify hacked pages, malicious downloads or deceptive content.
For website owners, Google Search Console can provide useful security notifications.
However, a website can still be compromised without receiving a Google warning.
What Should You Do If Your Website Has Already Been Compromised?
The first priority is to prevent additional damage while preserving information needed to investigate the incident.
Avoid immediately deleting suspicious files or repeatedly reinstalling the website without understanding what happened.
Doing so may destroy evidence and leave the original entry point unresolved.
A structured response usually involves the following stages.
Containment: Restrict the attacker’s access and isolate affected systems where appropriate.
Investigation: Identify the likely entry point, affected components, persistence mechanisms and possible data exposure.
Eradication: Remove malicious components, correct vulnerabilities and close unauthorised access paths.
Recovery: Restore or rebuild systems from trusted sources, validate their integrity and monitor for further suspicious activity.
Post-incident review: Understand why the incident occurred and implement measures to reduce the likelihood of recurrence.
If customer or employee personal data may have been exposed, the organisation should also assess its obligations under applicable data protection legislation.
In the UK, certain personal data breaches must be reported to the Information Commissioner’s Office (ICO) within 72 hours of becoming aware of the breach, where the legal reporting threshold is met.
Not every cybersecurity incident requires notification, and the legal obligations depend on the nature of the incident and the information involved.
For guidance, consult the Information Commissioner’s Office and the National Cyber Security Centre.
Why Website Security Requires More Than Installing Updates
PHP2Shell highlights a wider problem with website security.
Many organisations think of website maintenance as updating plugins, changing content and checking that their website is online.
These activities matter, but they represent only part of the security picture.
A modern business website depends on several connected components.
These may include:
- Operating system packages.
- Web server software.
- PHP or other application runtimes.
- Application frameworks.
- CMS platforms and plugins.
- Databases.
- External APIs.
- Cloud infrastructure.
- DNS and domain management.
- Authentication and access controls.
- Backup and recovery systems.
Weaknesses in any of these areas can affect the security of the overall service.
For example, updating WordPress does not guarantee that PHP is secure.
Similarly, applying a PHP security patch does not automatically resolve vulnerabilities in an outdated plugin or exposed administrative interface.
Effective security requires continuous attention to the complete environment.
This is why professional website maintenance should include server-level security considerations rather than focusing exclusively on visible website updates.
How to Build a More Secure Website for the Long Term
Responding to an urgent vulnerability is important, but businesses also need a sustainable approach to security.
Maintain a Complete Software Inventory
Know which technologies your website uses.
At a minimum, document the operating system, web server, PHP version, CMS or framework, major plugins, application dependencies and hosting provider.
For larger organisations, this inventory should cover every production application and server.
Without a reliable inventory, it becomes difficult to determine which systems are affected when a new vulnerability is announced.
Establish a Security Update Process
Security updates should follow a defined process.
This includes identifying relevant advisories, assessing their severity, prioritising exposed systems, testing changes where practical and verifying successful deployment.
Critical vulnerabilities may require emergency changes outside the normal maintenance schedule.
Protect Backups Against Ransomware and Server Compromise
Backups should not depend entirely on the same server that hosts the production website.
Where practical, maintain independently protected or immutable copies that cannot easily be deleted by someone who compromises the production environment.
Test restoration regularly.
Use the Principle of Least Privilege
Accounts and applications should receive only the permissions required to perform their responsibilities.
For example, a PHP web process should not normally require unrestricted administrative access to the entire server.
Appropriate separation of permissions can help limit the damage caused by an exploited application.
Monitor Important Security Events
Businesses should collect and review relevant security information.
Depending on the system, this may include login events, unexpected administrator changes, file integrity alerts, abnormal server activity and failed authentication attempts.
Monitoring should support timely investigation rather than simply generating large volumes of notifications nobody reviews.
Choose Hosting Based on Security and Support
Hosting decisions should consider more than storage capacity, advertised speed and price.
Important questions include:
- Does the provider maintain supported server software?
- How quickly are critical security patches applied?
- Are backups included, protected and tested?
- What happens when a security incident occurs?
- Are security responsibilities clearly documented?
- Is technical assistance available for urgent problems?
A hosting package that is inexpensive but poorly maintained can create significant business risk.
Businesses planning to move away from ageing infrastructure can explore NetPear’s cloud server services and hosting solutions.
Is It Safe to Continue Using PHP?
Yes.
The existence of a serious vulnerability does not mean PHP should automatically be abandoned.
Security vulnerabilities have been discovered in many widely used programming languages, operating systems, browsers and frameworks.
What matters is how quickly vulnerabilities are discovered, disclosed, corrected and addressed by the organisations using the affected technology.
PHP remains a widely used platform for websites and web applications.
However, businesses should operate supported PHP versions, apply security updates promptly and maintain appropriate security controls around their applications.
Changing programming languages does not remove the need for security maintenance.
A poorly maintained application written in another language can also expose a business to serious security risks.
PHP2Shell: Frequently Asked Questions
Is PHP2Shell a real security vulnerability?
Yes. PHP2Shell refers to two documented vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026.
Security updates and official advisories have been published.
Does PHP2Shell affect every WordPress website?
Not necessarily.
The risk depends on the PHP runtime, applicable security patches, hosting environment and server configuration.
Website owners should verify the patch status of their actual hosting environment.
Can hackers exploit PHP2Shell without a password?
Under affected conditions, successful exploitation may allow unauthenticated remote code execution.
This means an attacker would not necessarily need an existing administrator account.
Does updating WordPress fix PHP2Shell?
No.
Updating WordPress does not automatically update the underlying PHP runtime.
Both WordPress and PHP should be maintained, but they are separate components.
Is PHP 8.3 safe?
PHP 8.3.36 includes the security corrections announced for these vulnerabilities.
Earlier PHP 8.3 releases require an applicable security fix.
Some hosting providers may distribute backported patches, so the provider’s security information should also be checked.
Is PHP 7.4 affected?
Yes. Older PHP releases are included in the affected range.
PHP 7.4 is outside the PHP project’s normal security support lifecycle, so organisations should migrate to a supported branch or obtain a verified, supported vendor security fix.
Can a website firewall prevent PHP2Shell attacks?
A web application firewall may reduce exposure, but it should not be considered a substitute for correcting the PHP vulnerabilities.
Will installing the latest PHP version automatically remove malware?
No.
Security updates correct vulnerabilities, but existing compromises may require a separate investigation and recovery process.
Can PHP2Shell affect a Laravel application?
Yes.
Laravel applications depend on PHP, so their hosting runtimes should be assessed and patched where necessary.
What should I do if my hosting provider has not patched PHP?
Request urgent confirmation of the patch status and ask what remediation is planned.
If the environment remains vulnerable, consult a qualified administrator about appropriate mitigation, isolation or migration options.
Final Thoughts: Website Security Is an Ongoing Responsibility
The PHP2Shell vulnerabilities are another reminder that a business website can become exposed to serious security risks even when nothing appears to have changed on the website itself.
A site may look normal, load quickly and continue accepting customer enquiries while its underlying software requires an urgent security update.
For website owners, the immediate priority is clear: verify the PHP environment, ensure the relevant fixes have been applied and investigate any credible signs of compromise.
For businesses, the longer-term lesson is equally important.
Security cannot be treated as a one-off task completed when a website launches.
It requires maintained software, appropriate access controls, dependable backups, monitoring and a clear response process when new threats appear.
At NetPear, we develop, host and maintain business websites and bespoke web applications.
Our website maintenance services cover ongoing technical maintenance, software updates, backups and security-related support.
If you are unsure whether your website uses an affected PHP version, or need professional assistance reviewing its hosting environment, you can contact NetPear to discuss your requirements.
Official Sources and Further Reading
This article is based on publicly available technical advisories and security guidance.
UK National Cyber Security Centre (NCSC)
Critical Security Issue Affecting PHP — 21 October 2026
CERT Coordination Center
Memory Corruption Vulnerabilities in PHP — VU#763488
Google Cloud Security
Responding to Core PHP Vulnerabilities CVE-2026-109618 and CVE-2026-109619
NHS England Cyber Alerts
Critical Vulnerabilities in PHP — PHP2Shell
National Cyber Security Centre
Small Organisations Guide to Cyber Security
PHP Project
Official PHP Downloads and Updates
Security information is current as of 23 October 2026. Vulnerability advisories and vendor guidance may change as further research becomes available.
