A newly reported cyberattack has brought fresh attention to the dangers of running vulnerable PHP software on internet-facing servers.

On 26 October 2026, cybersecurity firm Dream Research published findings about an attack in which researchers said a threat actor had compromised 25 servers using a custom PHP2Shell exploit combined with a separate Linux kernel privilege-escalation vulnerability.

According to the report, the affected systems included firewall devices and infrastructure associated with a US government-affiliated environment. The researchers also described activity involving credential extraction and attempts to access Active Directory resources. Dream Research

The PHP2Shell attack is particularly concerning because the underlying vulnerabilities affect the PHP runtime itself, not simply an individual website plugin or content management system.

For UK businesses, this distinction matters. A WordPress, Drupal or custom PHP website can have fully updated application code while still relying on a vulnerable PHP installation.

This article explains what researchers reported, how PHP2Shell works, what the 25-server incident means, and the steps businesses should take to protect their websites and servers.

Last reviewed: 29 October 2026.

What Is PHP2Shell?

PHP2Shell is the name given to two critical vulnerabilities in the PHP programming language runtime: CVE-2026-109618 and CVE-2026-109619. Both can potentially allow an unauthenticated attacker to execute code remotely on affected systems. Security fixes were released on 21 October 2026.

PHP is widely used to power dynamic websites, content management systems and web applications.

When a visitor opens a PHP-based website, the server runs PHP code to generate the appropriate response. That process may involve retrieving information from a database, processing a form or handling a customer login.

PHP2Shell affects how the underlying PHP engine handles certain internal conditions.

The vulnerabilities are significant because attackers may be able to exploit affected configurations without first obtaining a legitimate user account.

The UK’s NHS England cyber alert rates the threat as high and identifies both vulnerabilities as critical, with CVSS v4.0 scores of 9.2. NHS England Digital

The Two PHP2Shell Vulnerabilities

Vulnerability	Technical Issue	Potential Impact
CVE-2026-109618	Memory corruption associated with out-of-memory handling	Unauthenticated remote code execution
CVE-2026-109619	Stale global state referring to memory that has already been freed	Unauthenticated remote code execution

These are separate vulnerabilities, although they were disclosed and patched together.

What Happened in the PHP2Shell Attack Involving 25 Servers?

The most important evidence comes from Dream Research’s report dated 26 October 2026.

The researchers said they uncovered attack artefacts on 25 October that indicated an operation against 25 servers.

According to the report, the attacker combined a custom PHP2Shell exploit with a kernel privilege-escalation exploit to obtain elevated access on affected systems.

The targeted devices reportedly ran particular versions of firewall software from a major vendor.

Dream Research did not publicly identify that vendor or the affected software versions, explaining that the vendor had been notified. Dream Research

What the Researchers Reported

The published account describes several important elements.

Initial exploitation: The attacker used PHP2Shell as part of an exploit chain against vulnerable systems.

Privilege escalation: A separate kernel vulnerability was used to obtain higher privileges after the initial compromise.

Affected systems: Researchers reported 25 compromised servers, including systems in a US government-affiliated environment.

Follow-on activity: The report described credential extraction, directory enumeration and attacks against Active Directory.

Possible AI assistance: The researchers characterised the operation as appearing to involve Chinese AI-assisted activity. That description is an attribution assessment, not independently established proof of the attacker’s identity or the precise role of AI.

What Is Confirmed and What Remains Unclear?

It is important to distinguish the published research findings from details that have not been independently established.

Claim	Evidence Status
PHP2Shell consists of two critical PHP vulnerabilities	Confirmed by official advisories
Security fixes were released on 21 October 2026	Confirmed
Dream Research reported an exploit chain affecting 25 servers	Confirmed as a published research report
All 25 systems were independently verified by a public authority	Not established in the reviewed sources
The affected firewall vendor and versions are publicly identified	No
The attacker was conclusively identified as a Chinese state-backed group	Not established
Every vulnerable PHP website has been compromised	No evidence supports this

The headline figure of 25 servers refers to a specific reported campaign. It should not be confused with the much larger number of potentially exposed PHP installations worldwide.

Why This Incident Matters

A successful attack against a server can create opportunities for further intrusion.

In the reported campaign, the concern extended beyond the PHP application itself because the researchers described attempts to access identity infrastructure.

This illustrates an important cybersecurity principle: compromising an exposed management interface can become the starting point for broader activity within an organisation.

It does not mean that every PHP2Shell exploitation attempt will result in the same level of access.

How Does the PHP2Shell Vulnerability Work?

PHP2Shell involves flaws in the PHP engine’s internal memory handling.

These issues are different from common website vulnerabilities such as weak passwords or an insecure plugin.

CVE-2026-109618: Out-of-Memory Corruption

Software uses memory to process information and execute instructions.

When PHP encounters an out-of-memory condition, it must interrupt processing and clean up internal resources.

The vulnerability arises because certain error-handling paths can leave internal request memory in an invalid or incompletely initialised state.

Subsequent cleanup operations may then access that memory incorrectly.

Under vulnerable conditions, an attacker may be able to exploit this behaviour to execute code.

CVE-2026-109619: Stale Global State

The second vulnerability involves internal PHP state that can continue referring to memory after that memory has been released.

This type of problem is related to a class of memory safety issues commonly described as use-after-free.

If an attacker can influence how the vulnerable state is accessed, the flaw may allow remote code execution.

What Is Remote Code Execution?

Remote code execution, or RCE, means an attacker can cause a vulnerable system to execute instructions that the system owner did not authorise.

Depending on the permissions available and the environment, successful RCE can lead to further actions such as accessing sensitive information, changing files or attempting to establish persistence.

RCE does not automatically mean the attacker has full administrator or root privileges.

That is why the additional privilege-escalation stage described in the 25-server report is significant.

Simplified PHP2Shell attack chain

Internet-facing vulnerable PHP service

Successful PHP2Shell remote code execution

Additional privilege-escalation exploit

Elevated access and possible movement towards other systems

Illustrative sequence based on the reported campaign. Each stage requires suitable conditions and does not occur automatically.

PHP2Shell Timeline: Key Developments in October 2026

1. 17 October 2026 — Early exploitation attempt reportedAWS security researchers observed an attempted PHP2Shell exploit in their MadPot monitoring environment before public disclosure. This observation demonstrates attempted exploitation, not necessarily successful compromise.
2. 21 October 2026 — Vulnerabilities disclosed and patches releasedPHP published fixed releases for supported branches. NHS England issued its security alert the same day.
3. 23–25 October 2026 — Attribution clarificationPalo Alto Networks Unit 42 withdrew an earlier conclusion linking a European government agency compromise to PHP2Shell because it could not confirm that the vulnerabilities were the initial access method.
4. 25 October 2026 — Attack artefacts identifiedDream Research reported uncovering evidence of a campaign involving 25 compromised servers.
5. 26 October 2026 — Research publishedDream Research publicly described the PHP2Shell exploit chain, privilege escalation and follow-on identity-related activity.

The Unit 42 correction is particularly important. Security reporting evolves as investigators gather additional evidence. An early claim of compromise should not be repeated as fact after the original researchers have withdrawn it. Unit 42+2

Which PHP Servers and Websites May Be Vulnerable?

PHP2Shell is a runtime issue.

This means the relevant question is not simply whether a website uses WordPress, Drupal, Joomla or a custom PHP application.

The question is whether the server or product executes an affected PHP runtime in a vulnerable configuration.

Potentially affected environments include PHP-powered websites, web applications, administration panels, hosting platforms and products that embed PHP internally.

Affected PHP Versions and Security Fixes

PHP Branch	Fixed Version	Recommended Action
PHP 8.5	8.5.12	Update to this version or later
PHP 8.4	8.4.27	Update to this version or later
PHP 8.3	8.3.36	Update to this version or later
PHP 8.2	8.2.35	Update and plan for branch end-of-life
PHP 8.1 and older	No new supported upstream release	Migrate to a supported branch or verify a trusted vendor security backport

The PHP project released these fixes on 21 October 2026. Organisations using distribution-maintained packages may receive security backports without an obvious change to the upstream version number, so vendor advisories and package release information should also be checked. NHS England Digital+1

Does Updating WordPress Fix PHP2Shell?

No. Updating WordPress alone does not fix a vulnerable PHP runtime.

WordPress updates are important for addressing vulnerabilities within the application, but PHP2Shell exists in the underlying PHP engine.

A business may need its hosting provider or server administrator to update PHP separately.

The same distinction applies to Drupal, Joomla and custom PHP applications.

Are All PHP Installations Equally Exposed?

No.

Actual risk depends on the PHP version, the server configuration, whether the vulnerable runtime handles web requests, network exposure and available mitigations.

The official advisories identify web-serving PHP configurations as an important concern, including Apache mod_php, PHP-FPM and other execution environments.

Administrators should evaluate their own deployment rather than assuming that using a particular content management system determines exposure.

What Are the Potential Consequences of a Successful PHP2Shell Attack?

The impact of a successful exploit depends on what the affected PHP process can access and whether the attacker can exploit additional weaknesses.

1. Unauthorised Access to Server Resources

Remote code execution may allow an attacker to interact with files and processes accessible to the compromised service account.

Poorly configured permissions can increase the potential damage.

2. Exposure of Sensitive Information

A vulnerable application server may contain configuration files, database credentials, API keys or other sensitive information.

If these resources are accessible to the compromised process, they could be exposed.

However, successful PHP2Shell exploitation does not automatically prove that customer data was accessed or stolen.

3. Website Modification or Service Disruption

Attackers may attempt to modify website files, interfere with normal operations or deploy additional malicious software.

For an ecommerce business, prolonged downtime can interrupt orders and customer enquiries.

4. Privilege Escalation

An attacker who initially gains access through a web application may attempt to obtain greater permissions.

This is especially relevant to the reported 25-server campaign because Dream Research described a separate kernel exploit being used after the PHP2Shell stage.

5. Credential Theft and Further Intrusion

If credentials are exposed, attackers may try to access other systems.

The Dream Research report described activity involving Active Directory, highlighting the risks when server compromise is followed by attacks against an organisation’s identity infrastructure.

6. Financial, Operational and Reputational Damage

A serious incident may require emergency technical work, system restoration, investigation and communication with affected parties.

The costs depend on the scale of the incident and the organisation’s circumstances.

For UK businesses, personal data exposure may also create regulatory obligations.

Warning Signs of a Compromised PHP Server

Not every cyberattack produces visible symptoms.

A server may appear to function normally even when an attacker has obtained access.

Nevertheless, certain changes should trigger investigation.

Warning Sign	Possible Explanation	What to Investigate
Unfamiliar PHP files	Unauthorised file creation or a malicious web shell	File changes, ownership and timestamps
Unexpected administrator accounts	Account compromise or unauthorised access	User creation and authentication logs
Unusual outbound connections	Malicious software or unauthorised communication	Network connections and process activity
Suspicious scheduled tasks	Attempted persistence	Cron jobs and system services
Unexpected privilege changes	Privilege escalation or configuration changes	System and security logs
Modified website content	Unauthorised file or database changes	File integrity and application audit records
Repeated PHP worker failures	Application faults or potentially malicious activity	PHP error logs and request patterns
Security monitoring alerts	Possible exploitation or suspicious behaviour	Alert evidence and correlated events

These indicators are reasons to investigate, not proof that PHP2Shell was exploited.

For example, PHP worker crashes can result from ordinary software defects, resource exhaustion or unrelated configuration problems.

Likewise, a compromised website might have been accessed through stolen credentials or a vulnerable plugin rather than the PHP runtime.

Why Logs Matter

Web server, PHP, authentication, endpoint and network logs can help investigators reconstruct suspicious activity.

For PHP2Shell, administrators should preserve relevant records covering the period before and after public disclosure.

The reported attempted exploitation observed on 17 October 2026 makes it sensible to review activity from at least that date where logs are available. Earlier records may also be relevant depending on the investigation.

How to Protect PHP Servers From PHP2Shell

The most important protection is to update affected PHP runtimes using official security fixes or verified vendor-provided patched packages.

Other controls can reduce exposure, but they should not be presented as substitutes for patching.

Step 1: Identify Every PHP Installation

Create an inventory of websites, servers, containers, hosting environments and appliances that use PHP.

Include administrative interfaces and bundled runtimes, not just public websites.

A company may have several PHP installations even when it operates only one main website.

Step 2: Confirm the Runtime and Patch Status

Ask the hosting provider or server administrator to verify the PHP version used by the live web service.

A command-line PHP version does not necessarily match the version running behind a website.

Where distribution packages contain backported fixes, verify the relevant vendor security advisory rather than relying solely on the version string.

Step 3: Apply the Security Updates

Install the appropriate patched PHP release or vendor update.

Ensure the affected runtime processes are restarted or replaced so the patched code is actually running.

For hosted services, obtain confirmation from the provider that the relevant environment has been remediated.

Step 4: Prioritise Internet-Facing Systems

Publicly accessible services may be exposed to unauthenticated attack attempts.

Prioritise systems handling sensitive information, payment-related workflows, customer accounts or administrative functions.

Do not overlook firewall management interfaces or other products that may embed PHP.

Step 5: Reduce Unnecessary Exposure

Restrict administrative interfaces to authorised networks or trusted access methods where operationally appropriate.

Remove unused services and review unnecessary public endpoints.

Network restrictions can reduce opportunities for attack but do not repair the underlying vulnerabilities.

Step 6: Review Logs and Security Alerts

Look for unusual activity, unexplained service crashes, suspicious file changes and unexpected authentication events.

If monitoring tools produce a possible PHP2Shell alert, investigate the underlying evidence before concluding that compromise occurred.

Step 7: Verify Website and Application Integrity

Compare important application files with trusted versions or known-good backups.

Review privileged accounts, application configuration, scheduled tasks and relevant integrations.

For WordPress or another CMS, updating the application remains necessary even after PHP has been patched.

Step 8: Continue Monitoring

After remediation, monitor for unusual behaviour and confirm that the updated runtime remains in use.

Document which systems were checked, what was changed and whether any evidence of compromise was found.

PHP2Shell Protection Checklist

Server remediation progress

0 of 9Inventory PHP installations and embedded runtimesVerify the live web-serving PHP versionInstall a fixed release or validated vendor backportRestart or replace affected PHP processesRestrict unnecessary public administrative accessPreserve and review relevant security logsCheck privileged accounts, files and scheduled tasksConfirm backups are available and recoverableDocument remediation and monitor for suspicious activity

Copy checklistThis is a general operational checklist, not a substitute for a technical assessment or incident-response plan.

What Should You Do if You Suspect a PHP2Shell Compromise?

If there is credible evidence of successful exploitation, the situation should be treated differently from routine patch management.

1. Contain the Affected Systems

Work with the hosting provider or security team to isolate affected services and prevent further unauthorised access.

Avoid unnecessary actions that could destroy important evidence.

2. Preserve Evidence

Retain available logs, relevant system records and forensic snapshots using procedures appropriate to the environment.

Do not immediately delete suspicious files without considering their investigative value.

3. Engage Qualified Incident Responders

A confirmed or suspected server compromise may require specialist digital forensics and incident-response expertise.

This is particularly important where attackers may have obtained elevated privileges or accessed other systems.

4. Determine the Initial Access Method

Investigators should establish whether the incident involved PHP2Shell, another vulnerability, stolen credentials or a different entry point.

The presence of an unpatched PHP version is evidence of exposure, not proof that it was the route used by an attacker.

5. Rebuild or Restore From a Trusted State

Where compromise is confirmed, a clean rebuild may be safer than attempting to remove individual malicious files from an untrusted server.

Use verified software packages and trusted backups, and apply relevant patches before restoring public access.

6. Rotate Exposed Credentials

Review and replace credentials that may have been accessible to the attacker.

These may include application secrets, database passwords, API keys and privileged accounts.

Credential rotation should be coordinated with containment and recovery to avoid giving an active attacker access to newly issued secrets.

7. Validate the Recovery

Check application functionality, access controls, logging, monitoring and patch status before returning systems to normal operation.

Continue heightened monitoring after restoration.

Essential PHP Server Security Measures for UK Businesses

PHP2Shell highlights the importance of maintaining the entire technology stack.

A website’s security depends on more than the code visible to customers.

Maintain Supported Software

Keep PHP, the operating system, web server, CMS, frameworks, extensions and plugins appropriately updated.

Where a PHP branch has reached end-of-life, plan migration to a supported release.

Apply Least-Privilege Access

Web services should operate with only the permissions they require.

Avoid giving application processes unrestricted access to sensitive system files or administrative functions.

Separate Important Systems

Where appropriate, isolate public web services from databases, administrative systems and other sensitive infrastructure.

Segmentation can help limit the consequences of a compromised component.

Protect Administrative Access

Use strong authentication, multi-factor authentication where supported, and restricted access to hosting and administration interfaces.

Review dormant accounts and unnecessary privileges.

Maintain Reliable Backups

Keep backups protected from unauthorised modification and test restoration procedures.

A backup that has never been tested may not provide the recovery capability a business expects.

Use Monitoring and Defensive Controls

Logging, endpoint protection, intrusion detection and appropriately configured web application firewalls can support security operations.

However, a WAF cannot be relied upon as a complete fix for a vulnerable PHP runtime.

Review Hosting Responsibilities

Businesses using managed hosting should understand which security tasks are handled by the provider and which remain their own responsibility.

Ask specifically about PHP runtime patching, backups, monitoring and incident notification arrangements.

PHP2Shell and UK GDPR: What Businesses Need to Know

A vulnerable PHP server does not automatically create a reportable personal data breach.

The relevant question is whether a security incident has resulted in a personal data breach and, if so, what risks it creates for individuals.

Under the UK GDPR, organisations generally must notify the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours of becoming aware of a reportable personal data breach.

Notification is required unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.

Where the risk is high, affected individuals may also need to be informed without undue delay.

Businesses should assess the circumstances, document their decisions and consult current ICO guidance.

For wider incident management, the UK’s National Cyber Security Centre provides advice on responding to cyber incidents and securing business systems.

Organisations in regulated sectors may have additional notification or reporting obligations.

Common PHP Security Mistakes to Avoid

Updating only the CMS: A WordPress update does not patch the PHP engine.

Assuming a hosting provider has already fixed everything: Request confirmation of the actual runtime patch status.

Ignoring embedded PHP: Firewalls, appliances and management interfaces may use PHP internally.

Treating WAF rules as a complete fix: Filtering may help reduce risk but cannot replace a security update.

Checking only the command-line PHP version: The web-serving runtime may be different.

Assuming no visible symptoms means no compromise: Some malicious activity may be difficult to detect without logs and specialist analysis.

Confusing attack attempts with successful intrusions: A suspicious request does not establish that an attacker obtained access.

Making unsupported attribution claims: The reported campaign’s suspected origin should not be presented as conclusively established.

Returning a compromised server to service too quickly: Recovery requires confidence in system integrity, credentials and patch status.

Conclusion: What the PHP2Shell Attack Means for Website Security

The reported PHP2Shell attack involving 25 servers demonstrates how a vulnerability in widely used software can become part of a more complex intrusion.

Dream Research described an operation that combined PHP remote code execution with kernel privilege escalation and follow-on activity involving identity infrastructure.

Although some details of the campaign remain undisclosed or unverified independently, the underlying PHP2Shell vulnerabilities are real, critical and have published security fixes.

For UK businesses, the immediate priorities are to identify affected PHP installations, verify patch status, reduce unnecessary exposure and investigate credible indicators of compromise.

The most effective response is evidence-led: patch the vulnerable runtime, confirm the fix is active and treat any suspected compromise as a separate incident requiring proper investigation.

10. FAQ Section

What is the PHP2Shell attack?

PHP2Shell refers to attacks exploiting two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Successful exploitation may allow unauthenticated remote code execution. A report published on 26 October 2026 described an attack chain that researchers said compromised 25 servers.

Did PHP2Shell really compromise 25 servers?

Dream Research reported that its investigators identified artefacts indicating 25 compromised servers, including systems in a US government-affiliated environment. This is a specific published research finding. The complete technical evidence and the affected vendor’s identity have not been publicly disclosed in the reviewed report.

Which PHP versions are vulnerable to PHP2Shell?

Affected versions include releases before PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older unsupported branches also require attention. Some operating-system vendors supply security backports, so administrators should verify the actual package’s security status.

Can PHP2Shell affect WordPress websites?

Yes. WordPress runs on PHP, and an affected server-side PHP runtime may expose the website even if WordPress itself is up to date. Administrators should check the PHP version and relevant hosting configuration.

How can I tell whether my PHP server was hacked?

Investigate suspicious file changes, unknown accounts, unusual network activity, unexpected scheduled tasks and security alerts. None of these indicators alone proves PHP2Shell exploitation. Qualified incident responders may be needed to establish whether a compromise occurred.

Does a web application firewall stop PHP2Shell?

A WAF may reduce exposure to certain malicious requests, depending on its capabilities and configuration. It should not be treated as a complete solution. Updating the vulnerable PHP runtime is the essential remediation.

What should a UK business do after a PHP2Shell attack?

Contain affected systems, preserve evidence, engage appropriate security expertise, investigate the entry point, patch vulnerabilities, rotate potentially exposed credentials and restore services from a trusted state. Assess whether personal data was affected and whether regulatory notification is required.

Is PHP2Shell still a risk after applying the patch?

A correctly installed and active security fix addresses the specified vulnerabilities. However, patching does not automatically remove malware or unauthorised access established before the update. Businesses with evidence of compromise must investigate and remediate the incident separately.

Keep Your Business Website Maintained and Up to Date

Security incidents such as PHP2Shell highlight why businesses need to understand the software and hosting environments behind their websites.

At CRAZILS, we provide professional Web Design & Development, Ecommerce Solutions, and Website Maintenance & Support for UK businesses and international clients.

Whether you are planning a new website, improving an existing platform or reviewing your ongoing website maintenance requirements, we can help you explore practical solutions for your digital presence.

For a suspected active cyberattack or confirmed server compromise, seek assistance from a qualified cybersecurity incident-response specialist.

Contact CRAZILS to discuss your website requirements.

Website: https://crazils.com
Email: info@crazils.com
Phone / WhatsApp: +44 7897 053081

CRAZILS — Digital Solutions. Real Growth.