Critical Vulnerability, Cyber security, PHP, PHP2Shell, Remote Code Execution

Critical PHP vulnerabilities: Are you affected and what should you do?

22nd October 2026

Two critical vulnerabilities have been identified in PHP, the server-side technology used by websites, web applications and a range of commercial products.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could allow an attacker to execute code on an affected web server without first needing an account or login. The PHP Project released emergency updates on 21 October 2026 and urged users to update immediately. The UK National Cyber Security Centre has also told organisations to identify affected systems, prioritise internet-facing services and apply the available updates.

This is not only an issue for web developers. PHP may be running beneath your corporate website, customer portal, e-commerce platform or another product managed by a supplier.

If you believe your organisation is under immediate cyber threat or has experienced an incident, contact Zensec immediately for support.

Which PHP versions are affected?

The PHP Project has released the following fixed versions:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

PHP 8.1 and earlier no longer receive updates directly from the PHP Project. Organisations using an unsupported version will need to move to a supported release or obtain an appropriate update through their operating-system or long-term-support supplier.

The issue affects PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

PHP may be running in more places than you expect

Checking the version behind your main website is a sensible starting point, but it should not be the end of the exercise.

PHP is also used in:

Customer and partner portals
Internal web applications
E-commerce platforms
Legacy systems
Hosting control panels
Network and storage appliances
Monitoring, ticketing and CRM products
Container images carrying their own PHP installation

Some of these systems may be maintained by a web agency, hosting company, software vendor or another third party.

Ask each relevant supplier to confirm whether PHP is present, which version is running and whether the affected installation has been updated. Do not assume that updating the host server automatically updates the PHP version packaged inside every appliance, application or container.

What should organisations do now?

1. Find every PHP installation

Start with systems accessible from the internet, including websites, portals, applications and remote management interfaces. Then check internal services and third-party products that may bundle PHP.

2. Apply the appropriate update

Move affected systems to a fixed release or install the security package supplied by your operating-system or long-term-support vendor.

Make sure PHP worker processes are restarted after the update so that the patched code is being used.

3. Deal with unsupported versions

If a system is running an unsupported PHP version, leaving it online is not a sustainable response. Establish whether a supported vendor update is available and plan to upgrade, isolate or replace the affected system.

4. Confirm the position with suppliers

Ask hosting providers, web agencies and software vendors to confirm whether their services are affected and when remediation was completed.

5. Review exposed systems for compromise

If an affected system was accessible from the internet while unpatched, consider what evidence is available from that period.

This is separate from patching. The update prevents future exploitation of the vulnerabilities, but it cannot establish whether the server was accessed beforehand.

What signs should you look for?

Preserve relevant logs before making unnecessary changes to a system you suspect may have been compromised.

Potential areas for investigation include:

Unusual PHP or web server crashes and memory errors.
New or modified files in website, upload, plugin or theme directories.
The web server launching shells or download tools.
Unexpected outbound connections from the server.
New user accounts, SSH keys, scheduled tasks or cron jobs.
Changes to server and PHP configuration files.

Any one of these may have an innocent explanation. They still warrant investigation when they appear on a system known to have been exposed.

If suspicious activity is identified, avoid making further changes that could destroy useful evidence. Updating a compromised server does not remove every form of attacker access.

When is a compromise assessment appropriate?

A compromise assessment may be appropriate where:

The system was internet-facing before it was patched.
You cannot establish exactly when remediation took place.
There are gaps in logging or monitoring.
The organisation is unable to determine whether suspicious activity occurred.
The system holds sensitive information or connects to other important services.
Unusual files, processes, accounts or network activity have been identified.

The purpose is not to repeat a vulnerability scan. It is to look for evidence that the vulnerability was used or that an attacker established access by another means during the exposure period.

A focused assessment can include log analysis, file-integrity checks, web-shell detection, persistence review and examination of suspicious network or process activity.

Patching and investigation answer different questions

Patching answers: Is the known vulnerability still open?

A compromise assessment answers: Is there evidence that someone used it while it was open?

Organisations need to be able to answer both.

The immediate priority is to identify and update affected systems. Where systems were exposed, the next priority is to establish whether the evidence supports a clean conclusion or a wider incident investigation.

Concerned your organisation may have been affected?

If a PHP-powered system remained internet-facing before remediation, patching alone may not establish whether it was accessed beforehand.

Zensec is an NCSC-assured Cyber Incident Response provider. Our DFIR team can help assess exposed systems, identify signs of compromise and advise whether further investigation is required.

If you’d like to discuss your exposure or review a potentially affected system, contact the team.

Update: 27 October 2026

The risk associated with the PHP2Shell vulnerabilities has increased following confirmation of active exploitation. CISA has added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalogue, reinforcing the need for organisations to prioritise remediation of exposed PHP systems.

A further PHP remote code execution vulnerability, CVE-2026-115560, was also disclosed on 23 October. This vulnerability affects systems under a more unusual combination of configuration and application conditions, and mitigation guidance has been issued while a permanent fix is pending.

Organisations should continue to identify internet-facing PHP systems, apply the available security updates for PHP2Shell and investigate potentially exposed systems for signs of compromise.

The underlying advice remains consistent with the NCSC’s guidance to identify PHP across the estate, prioritise internet-facing systems and update to fixed versions.