Why lawyers care
Most of the attention is on patching, but counsel should also be asking what happened before the patch and what needs to be preserved afterward. The two flaws are in PHP, the software that runs many websites and other internet-facing systems. A specially crafted web request may allow someone without a log-on to run code on a server or obtain data from the PHP process, including passwords, authentication tokens, application programming interface (API) keys, and certificates.
The practical issue is broader than a single website. PHP is also used in control panels, phone systems, firewalls, monitoring tools, and vendor products where its presence may not be obvious. Updating WordPress, Drupal, or another application may not fix a vulnerable PHP runtime.
Reported exploitation attempts began before public disclosure. Organizations should patch promptly and determine what was exposed before patching.
What happened
On Oct. 21, PHP released fixes for CVE-2026-109618 and CVE-2026-109619. The vulnerabilities affect PHP installations serving web requests, although exploitability can vary by runtime and configuration. PHP lists releases before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable. Older unsupported versions, including PHP 5, are also affected.
PHP 8.1 and earlier are no longer supported with ordinary PHP releases. PHP published limited source backports for versions 7.4 through 8.1, and some operating-system distributions and long-term-support vendors may provide patched packages for older versions. Organizations using older PHP versions should confirm with the applicable vendor whether a supported patch is available rather than assuming an application or operating-system update addressed the issue.
Information about the vulnerabilities became public on Oct. 20, and PHP moved up its planned security release. Security researchers and providers have since reported exploitation attempts, including telemetry showing an attempt on Oct. 17. The Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued alerts on Oct. 21. Available workarounds can reduce exposure to particular attack methods, but they are not a substitute for patching.
What to do now
Patching is the first step, along with other recommendations.
Preserve the relevant logs. The first vulnerability was reported to PHP on Aug. 1, and a second research team independently found the issues later that month. Because reported exploitation attempts predate public disclosure, organizations should consider preserving available web server, PHP-FastCGI Process Manager (PHP-FPM), Web Application Firewall (WAF), and load balancer logs from Aug. 1 forward. This is particularly important if those logs ordinarily roll off after 30 days.
Review credentials and other secrets. The vulnerabilities may expose information held in PHP process memory. That can include session tokens, API keys, database credentials, and certificates. For affected internet-facing systems, IT and security teams should assess which credentials could have been present and whether they should be rotated. Patching the server does not invalidate credentials that may already have been exposed.
Check for signs of attempted exploitation. Security teams should use current guidance from PHP, security providers, and incident-response vendors when reviewing affected systems. Because these flaws operate in the PHP runtime rather than the application itself, ordinary application logs may not tell the whole story. Our team has received alerts from incident-response providers and can share current indicators and detection guidance.
Questions to answer with your IT and security teams
- Inventory. Where is PHP running? Start with internet-facing systems, but include hosting control panels, VoIP systems, firewalls, monitoring tools, vendor appliances, and other products where PHP may be embedded.
- Patch status. Which systems were affected, which patched versions or vendor backports were installed, when were they installed, and were the PHP services restarted so the updated software is actually running?
- Older PHP versions. If a system remains on PHP 8.1 or earlier, has the applicable distribution or support vendor provided a patch? If not, determine whether the service should be taken offline or appropriately risk-mitigated until it can be remediated.
- Vendors. Ask hosting providers, agencies, and other relevant service providers in writing whether they were affected, when they patched, and whether they reviewed their systems for signs of compromise. Also check what the applicable contracts require of the vendor and of your organization.
- Evidence. Preserve relevant logs and document what was potentially exposed, when each system was patched, what review was performed, and whether potentially affected credentials were rotated. If an issue is identified later, that record can help establish the period of possible exposure.
What comes next
This event is a useful reminder that older, widely used software can still contain significant vulnerabilities. The time between disclosure and attempted exploitation can also be short. Organizations should know where foundational software such as PHP is running, have a process for receiving and acting on vendor security notices, and keep enough logging to investigate what happened before a patch was installed.
For counsel, the question is not simply whether IT installed the patch. It is whether the organization can identify what was affected, preserve the relevant evidence, address credentials and vendors, and document the work that was done. We are happy to help with any questions that you have, as many organizations are working through this.
