Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, could allow unauthenticated remote code execution on affected servers. Both vulnerabilities are rated Critical, with a CVSS v4.0 score of 9.2.
The UK National Cyber Security Centre (NCSC) is urging organisations to take immediate action. PHP has released security updates, and organisations should identify affected systems and apply the appropriate fixes as soon as possible.
If you know a system runs PHP, prioritise updating it immediately. Do not wait for a vulnerability scan.
The vulnerabilities affect PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project identifies mod_php as the highest-risk configuration and reports a demonstrated exploit that can trigger before application code runs.
The initial fixed upstream releases are:
Update to a fixed release in your current branch or apply the equivalent security update provided by your operating system, hosting provider or software vendor. Package version strings can differ from upstream PHP version numbers when vendors backport security fixes, so check the relevant vendor advisory.
PHP 8.1 and older no longer receive routine security updates from the PHP project. However, some operating system distributions and long-term support vendors provide backported security fixes. The PHP team has also published minimal source backports for PHP 7.4, 8.0 and 8.1.
Check your vendor’s security advisory and package status to establish whether your specific installation has been patched. Where a supported, fixed vendor package is unavailable, plan to migrate to a supported PHP branch.
PHP 8.2 is currently fixed for these vulnerabilities, but upstream support for PHP 8.2 ends on 31 December 2026. Organisations using this branch should plan their upgrade accordingly.
The NCSC recommends identifying systems running PHP, prioritising internet-facing systems, applying security updates and monitoring third-party vendors for updates to products and services that include PHP.
1. Identify systems running PHP
Identify systems running any version of PHP, not just older releases. Start with internet-facing websites, applications and servers. Include custom-built websites, third-party applications, appliances, containers and services that may bundle or embed PHP.
The NCSC-NL PHP2Shell repository provides an inventory of software products that may be affected. The inventory is not exhaustive, and entries may require further investigation. Use it as a starting point rather than a complete list of affected systems. Custom PHP applications also need to be considered.
2. Apply the available security updates
Update affected PHP installations to an appropriate fixed version or follow the relevant vendor’s instructions if PHP is bundled within another product.
Check that the update has been applied to every relevant runtime, container, application or appliance. Complete any required service restarts or other vendor-specified steps so that the patched code is running.
3. If you cannot patch immediately, reduce exposure
PHP provides temporary mitigations for specific attack paths. These measures can reduce exposure, but they are not a complete fix and do not make an affected installation safe. Updating to a fixed release remains the recommended solution.
If you cannot patch immediately, follow the official PHP security advisory and NCSC guidance on temporary mitigations. If effective mitigation is not possible, consider taking the affected system offline until it can be remediated.
4. Check for signs of compromise where necessary
If you cannot update or disable an affected system immediately, the NCSC advises assessing it for evidence of compromise before upgrading or applying mitigations. This should include checking for attacker-installed backdoors.
Patching addresses the vulnerability but does not establish whether a system was compromised previously. Review relevant logs and investigate suspicious activity. If you find evidence of compromise, follow your incident-response procedures and seek specialist assistance where needed.
For the full recommended response, read the NCSC’s PHP security guidance.
If you know a system runs PHP, apply the relevant security update without waiting for a scan. If you are unsure whether your environment contains affected systems, AppCheck can help investigate potential exposure.
CVE-2026-109618 and CVE-2026-109619 are listed in AppCheck’s vulnerability database and can be identified through version matching. AppCheck does not currently perform active exploitation checks for these vulnerabilities. Attempting to trigger them could disrupt or crash affected processes.
A version-based detection can help identify potentially affected systems, but it is not proof that a vulnerability is exploitable. Equally, failure to identify a PHP version does not prove that a system is unaffected.
To enable PHP version detection in a web application scan:
This check relies on PHP version information being available in HTTP responses. If your external applications do not disclose this information, a web application scan may not identify the PHP version accurately.
An authenticated infrastructure scan may provide additional version information, depending on the scan’s access and coverage. See the guide: How to Scan: Infrastructure.
Neither the AppCheck Scanner Web Portal nor AppCheck Hubs use PHP, so CVE-2026-109618 and CVE-2026-109619 do not directly affect these environments.
However, organisations running PHP across their own websites, applications or infrastructure should still follow the guidance above to identify and secure potentially affected systems.
If you have questions or would like help, please get in touch. Our team is happy to support you.
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorised by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
