Two critical PHP security vulnerabilities have been identified, prompting the National Cyber Security Centre (NCSC) to issue guidance for UK organisations using PHP, a technology used by many websites, web applications and other software products.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could, if successfully exploited, allow an attacker to run code remotely on an affected PHP system without first needing to authenticate.
For organisations, the priority is to establish whether PHP is present within their infrastructure, understand which systems rely on it and ensure the appropriate security updates are applied.
What Has Happened With PHP?
PHP is a programming language that sits behind many websites and web-based applications. It typically runs on the server hosting the application, rather than on the user’s device, and can also be incorporated into other software products.
Two critical vulnerabilities have been identified, CVE-2026-109618 and CVE-2026-109619, both relating to the way PHP handles memory and potentially resulting in remote code execution. Security updates have since been released, with fixes available for the PHP 8.2, 8.3, 8.4 and 8.5 branches. PHP 8.1 and earlier no longer receive updates directly from the PHP project.
The NCSC advises organisations using PHP to take action and makes clear that the issue shouldn’t be treated as something affecting only obviously outdated installations.
Why Are The PHP Security Vulnerabilities Significant?
Remote code execution vulnerabilities can potentially give an attacker the ability to run code on an affected system. In this case, the risk applies to PHP installations handling web requests, making externally accessible websites and applications an important area to review.
However, establishing whether an organisation is affected isn’t simply a question of checking the version of PHP on a website.
The first step is understanding where PHP is running, what relies on it and who is responsible for supporting the affected website, application or service.
How Do You Know If Your Organisation Is Affected?
Organisations should start by establishing where PHP is present across their infrastructure, paying particular attention to systems that are accessible from the internet.
It’s also important to look beyond PHP installations managed directly by your organisation. PHP can form part of third-party software, appliances and services, so relevant supplier security notifications and updates should also be checked.
Once PHP has been identified, establish which website, application or service relies on it and who is responsible for maintaining it.
Depending on the environment, this may involve:
- a web developer or web agency responsible for a website;
- an application vendor or developer responsible for a business application;
- an internal development team responsible for a bespoke application; or
- an IT or hosting provider responsible for the underlying infrastructure.
This distinction matters because changing PHP may also affect the website or application that depends on it. Older systems in particular may require compatibility work before they can be moved successfully to a current version.
What Should Organisations Do About The PHP Vulnerabilities?
Responding to the PHP security vulnerabilities starts with understanding where PHP is running and which websites, applications or services depend on it.
1. Establish Where PHP Is Running
Begin by checking where PHP is present and which websites, applications or services depend on it.
Systems accessible from the internet should receive particular attention because of their external exposure.
Don’t restrict the review to obviously old PHP installations. The current NCSC guidance applies more broadly to organisations using PHP.
2. Establish Who Supports The Affected System
Once PHP has been identified, establish who is responsible for maintaining the website, application or service using it.
For a company website, this may mean involving the web developer or agency responsible for maintaining it. For business applications, the relevant application vendor, developer or internal development team may need to be involved.
Your IT or hosting provider may also need to coordinate changes to the underlying environment.
This is particularly important for older systems. Moving PHP to a newer release may cause compatibility problems if the website or application was designed around an older version.
3. Apply The Appropriate PHP Update
Affected systems should be moved to an appropriate fixed and supported PHP release. For production systems, any update should take account of the website or application’s compatibility requirements.
As of 21 October 2026, PHP lists 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as releases containing fixes for the two vulnerabilities. PHP also notes that version 8.1 and earlier are no longer updated by the PHP project, although some Linux distributions and long-term-support vendors may provide their own fixes.
For an older website or application, development work may therefore be required before the underlying PHP environment can be brought fully up to date.
4. What If You Can’t Update Straight Away?
Where an immediate update isn’t possible, organisations should review the temporary measures published by PHP while arranging a permanent fix.
These measures should not be viewed as an alternative to updating. PHP states that they can reduce exposure to specific methods of attack but do not make the affected installation safe.
Organisations should check the latest NCSC guidance on the critical PHP security issue alongside PHP’s official security and release information before deciding how to address affected systems.
5. Consider Whether An Exposed System Needs Further Investigation
Where an affected system has remained exposed and can’t be updated or disabled immediately, further investigation may be required to check for evidence that it has been compromised.
The NCSC advises organisations to assess these systems before completing remediation and recommends appropriately qualified incident-response support where an organisation doesn’t have the capability to carry out the investigation itself.
6. Check Software Supplied By Third Parties
PHP may also sit within software, appliances or services supplied by another vendor.
Organisations should therefore check security notifications and updates from relevant technology suppliers, rather than assuming that reviewing directly managed servers provides the complete picture.
Legacy Systems Can Make Security Updates More Complex
The PHP issue also highlights a practical challenge for organisations with older websites and applications. Applying a security update may not always be straightforward if the application relies on an older version of the underlying software.
In these situations, addressing the vulnerability may require coordination between the organisation’s IT provider and the developer or vendor responsible for the application. Compatibility issues may need to be resolved before the affected system can be moved onto a current, supported release.
Regular vulnerability scanning can help identify known security weaknesses across an IT environment and provide a clearer view of where remediation should be prioritised.
Where a more detailed assessment is required, penetration testing can provide further insight into security weaknesses and how they may affect an organisation.
Concerned About Your Exposure?
If you’re unsure whether your systems may be affected by the latest PHP vulnerabilities, or want to identify vulnerabilities across your wider IT environment, Akita’s cyber security team can help identify potential areas of exposure and prioritise the steps required to address them.
Speak To A Cyber Security Specialist
Contact Us
