Updating WordPress, Drupal, or your website's plugins does not necessarily update the PHP software running on the web server. To address the critical vulnerabilities known as PHP2Shell, someone must verify that the PHP runtime actually handling web requests has received the security fixes. For an outsourced website, that person may be your hosting provider rather than your web designer.
On October 26, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. The change makes patch verification an immediate operational priority, not simply an item to revisit at the next website redesign. A KEV listing indicates evidence of exploitation; it does not mean that any particular website has been compromised.
What changed, and which websites are affected?
The PHP project released emergency fixes on October 21, 2026 for two critical flaws that can allow unauthenticated remote code execution. They concern PHP's internal handling of memory and request state, not a particular WordPress plugin or website theme. PHP says installations serving web requests are at risk across common deployment methods, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies particularly high risk with Apache mod_php, where a demonstrated attack can be triggered before application code executes.
The PHP security advisory lists these fixed upstream releases:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
These are upstream PHP release numbers, not a universal test for every hosting environment. Linux distributions and long-term-support vendors may backport the security fix into packages that retain an older-looking version number. Conversely, an updated package on disk does not establish that every web-serving process has loaded it. Confirm the applicable vendor security advisory, installed build, and running service.
PHP 8.1 and older no longer receive security releases directly from the PHP project. If your application depends on one of these branches, ask whether your supported operating-system or hosting vendor has issued a documented backport, and plan an upgrade rather than relying on an unsupported runtime indefinitely. CISA's PHP alert advises taking affected PHP services offline when they cannot be updated promptly.
How to check PHP on a WordPress website
For a WordPress site you administer, open Tools → Site Health → Info → Server and look for the PHP version. This is the PHP environment reported by that WordPress installation, not the WordPress version. The official WordPress Site Health documentation explains the location of these server details.
That number gives you a starting point. It may be enough to spot an outdated upstream build, but it cannot independently prove that a distribution-specific backport is installed or that other websites on the same account have been fixed.
If your web developer does not manage the hosting platform, direct the question to the host. Ask for the running PHP build serving the affected hostname, the advisory or package proving that both CVEs are fixed, when the change reached production, and whether any additional PHP pools, containers, or staging sites still need attention.
Three hosting situations, three different decisions
Consider these hypothetical examples involving an MSP responsible for several client websites:
What the team finds | The useful decision |
A WordPress site is fully updated, but its server reports an unpatched upstream PHP 8.2.34 build. | Escalate to the hosting owner to install an appropriate fixed PHP release. Updating WordPress again will not repair the runtime. |
A Linux-hosted application reports PHP 8.2.34, but its vendor says the vulnerability has been backported. | Request the actual installed package release and vendor advisory. Do not treat a shortened version string alone as proof of either exposure or remediation. |
The production website runs a fixed build, but an old staging hostname still serves requests using vulnerable PHP. | Include that reachable staging system in remediation, or remove its exposure. A completed production change does not fix a separate instance. |
The common requirement is an asset-specific answer: which hostname or application, which effective PHP runtime, which fix, and which person verified it. An inventory that stops at “our host handles updates” leaves those questions unanswered.
A practical patch-and-verification handoff
The website owner, hosting or development team, and security operations team should be able to complete one short record for each affected application:
- Identify the actual owner and runtime. List public sites, administrative interfaces, APIs, staging systems, and other PHP services. Record the web-serving PHP version and deployment method, not just the command-line PHP version on an administrator's laptop or server.
- Apply the vendor-approved fix. The host or system administrator deploys the appropriate patched package or documented backport and ensures the web-serving PHP workers use it. Where necessary, restart or replace workers so older processes do not continue running vulnerable code.
- Verify the live application. Confirm the effective runtime and patch evidence after deployment, then test business-critical paths such as sign-in, contact forms, file uploads, checkout, or customer portals. Record who performed the check and when.
- Review possible activity before the fix. Patching closes the known software flaw but does not undo an earlier compromise. CISA recommends monitoring for suspicious behavior such as PHP worker processes launching shells or downloading tools. Investigating those events requires appropriate server or endpoint telemetry and a defined incident-response process.
- Make an explicit decision if a system cannot be patched. Document whether the service will be taken offline or otherwise isolated while remediation proceeds. The PHP project warns that its temporary mitigations do not provide a complete fix.
For each system, a useful completion record contains the hostname, responsible host or administrator, web-serving build, vendor advisory, deployment time, live verification result, and any unresolved exception. That record is much more useful during an incident than an email saying “everything is updated.”
Where a managed WAF and SOC fit
A web application firewall (WAF) may help reduce exposure during the patching window, but it must not be mistaken for the PHP update itself. CISA says WAF protection may help; the PHP project says there is no complete substitute for patching.
Network Box USA's managed WAF service provides application-layer request filtering, policy and signature management, tuning, and reporting. When the affected traffic actually passes through the WAF, those capabilities can support a layered response. Whether a specific policy recognizes a particular exploit path must be assessed and verified. Traffic that bypasses the WAF receives none of that protection. See our related explanation of virtual patching versus fixing the application.
Monitoring is a separate responsibility. Network Box USA's qualifying managed services include SIEM capabilities and Security Operations Center support. Relevant web and security events can support investigation when the required sources are available and configured. Evidence that a PHP worker launched a shell, for example, may require host logs or endpoint telemetry that WAF request logs alone cannot supply. The hosting provider or application owner remains responsible for patching the PHP runtime; monitoring and network controls do not transfer that responsibility automatically.
What counts as finished?
Do not close the work because WordPress is current, because a host sent a generic reassurance, or because the WAF is enabled. Close it when the responsible teams can identify the affected services, substantiate the vendor fix in the running PHP environment, verify the application still works, and address any suspicious activity or unresolved exposures.
A separate note for October 2026
The PHP project also published an October 23 advisory on a distinct, configuration-dependent session-upload-progress issue. That issue is not one of these two KEV entries, so organizations should check current vendor guidance rather than treating the PHP2Shell patch as a universal fix for every PHP advisory.
If you are reviewing a public PHP application and need to understand the role of WAF policy, network security, and managed monitoring while the hosting team remediates the software, contact Network Box USA to discuss the relevant coverage and responsibilities.