Two critical vulnerabilities in PHP have triggered an international effort to secure websites, applications and online services. The UK’s National Cyber Security Centre (NCSC) is urging organisations to act immediately, with the US National Security Agency also advising that systems which cannot be secured should be taken offline.
For technical decision-makers, the immediate priority is clear: establish where PHP is running, apply the security fixes and investigate potential exposure.
What is the problem?
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 out of 10 under CVSS v4.0. Under certain conditions, they could allow an unauthenticated attacker to execute code remotely on a vulnerable server.
The flaws concern PHP’s handling of memory: one involves corruption during an out-of-memory condition; the other involves internal state that can persist after the memory it references has been released.
PHP is a fundamental component of the web, underpinning platforms such as WordPress, Drupal and Joomla, as well as countless commercial applications and services. Its widespread use means organisations may be exposed through systems they do not immediately associate with PHP.
How did we get here?
The story began in 2024, when researchers identified a theoretical weakness but struggled to establish how it could be exploited in practice.
In 2026, researchers from security firm Calif, OpenAI and Wiz used AI-assisted security research to investigate the problem and identify exploitable vulnerabilities. Work began with the PHP Foundation and software vendors to develop and coordinate the release of fixes.
That process was disrupted when details leaked ahead of the planned disclosure, followed by the circulation of a video demonstrating aspects of the attack. The release of emergency patches was brought forward.
The episode illustrates both sides of AI-assisted security research: advanced tools can help researchers uncover and fix difficult vulnerabilities, but attackers can also use AI to accelerate the development of exploits once technical details become public.
What should organisations do?
Patch immediately.
The PHP team has released fixes for supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CHECK THE OFFICIAL PHP ADVISORY and your operating system or hosting provider for the appropriate update. Older, unsupported versions need particular attention; ask vendors about backported fixes or plan an upgrade.
Find every installation.
Prioritise internet-facing systems, but include development environments, appliances, control panels and third-party products that bundle PHP. Managed hosting customers should obtain explicit confirmation that the underlying PHP runtime has been secured.
Isolate systems that remain vulnerable.
If a system cannot be patched or fully mitigated promptly, consider taking it offline. The PHP team says updating is the only safe choice; do not assume a workaround eliminates the risk.
Check for compromise.
Monitor logs and investigate suspicious activity, unauthorised changes, accounts or backdoors. Patching does not remove an attacker who may already have gained access.
————————————————————————————————————————————————————-
Our technical Team issued the following Advisory for our clients this morning.
Critical PHP Security Advisory: CVE-2026-109618 & CVE-2026-109619
We are writing to notify you of critical Remote Code Execution (RCE) vulnerabilities affecting PHP environments (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2). Official patches have been released by the PHP Development Team and Linux package maintainers.
Please review the details and recommended immediate actions below.
What You Need to Know
An unauthenticated remote attacker could exploit these flaws to execute arbitrary code on servers running affected PHP runtimes. Updates are now live for active, supported PHP branches (PHP 8.2, 8.3, 8.4, and 8.5).
Actions We Have Taken
Managed/Hosted Infrastructure: If your application runs on our fully managed hosting, our engineering team has already applied official package updates or deployed localised mitigations across our infrastructure to protect your applications.
Recommended Actions for Self-Managed Servers
If you manage your own servers, Virtual Private Servers (VPS), or custom application deployments, please take the following steps immediately:
Apply Updates or Mitigations: Run your OS package manager (apt update && apt upgrade or dnf update) to update to the latest patched PHP runtime. If package updates cannot be applied immediately, deploy local server mitigations to restrict malicious payloads.
Handle End-of-Life (EOL) Versions: Official security patches are not provided for legacy versions (PHP 8.1, 7.x, or 5.x). If you run EOL environments, we strongly advise upgrading immediately or isolating these applications behind access controls and firewalls.
Restrict Access: If patching or local mitigations must be briefly deferred, restrict public access to vulnerable PHP applications as an immediate safeguard.
Beyond the immediate response
The threat is escalating rapidly. Cloudflare CEO Matthew Prince has reported that attempted exploitation surged from thousands of attempts before public disclosure to millions afterwards. These figures represent attack attempts, not millions of confirmed breaches. The increase underlines how quickly attackers can respond when details of a critical vulnerability become public. Organisations should not wait for evidence of a successful attack before acting.
If your team is already responding, the fundamentals will be familiar. The harder question is whether you can identify every affected system and verify that each has been secured.
The lesson is simple: knowing about a vulnerability is not the same as knowing your organisation is protected.
If you’d like to discuss this issue further, please get in touch.