A website can appear to work normally while its PHP runtime still needs a critical security update. Knowing who maintains that runtime is the first step toward a verified fix.
Core takeaways
- Confirm the PHP runtime serving your website, including any vendor-provided security backport.
- Updating a CMS or plugin does not update PHP itself.
- Verify that patched workers or containers are actually running, then investigate any signs of compromise.
What happened, and what should you do first?
On 21 October 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution: an attacker may be able to run code on a server without first signing into the website. The PHP security announcement recommends immediate updates.
Start by asking whoever operates your website: Which PHP runtime handles our web requests, and has it received both fixes? Ask for the package revision or deployed image, and confirmation that the updated runtime is running. A statement that the website or its plugins are up to date does not answer that question.
The name PHP2Shell is used in the Dutch National Cyber Security Centre's operational guidance. A vulnerable installation needs attention; the name alone is not evidence that a particular website has been breached.
Where PHP fits into a website
A browser sends a request to a web server. For a PHP application, the server passes work to a PHP runtime, which executes application code and may query a database before returning a response. A content management system such as WordPress runs above that runtime.
This distinction explains why different updates have different owners. The website editor might update content, a developer might update plugins, and a hosting provider might maintain PHP. All three can report their own work complete while a runtime update is still outstanding.
For owners, the useful question is therefore about the whole service: who updates each layer, and who verifies the result?
What the two vulnerabilities mean
CVE-2026-109618: an unsafe interruption during memory handling
PHP normally allocates memory while preparing and handling a request. If memory runs out at a sensitive point, request data can remain only partly initialized. Cleanup can then act on invalid internal data. The official OOM corruption advisory describes how that condition can lead to code execution.
The advisory documents an Apache mod_php path that occurs before application code begins. It also distinguishes other deployment modes: its analysis considers PHP-FPM susceptible, while noting that a complete FPM exploit had not been demonstrated in that advisory. Operators should patch rather than assume every configuration has the same attack path.
CVE-2026-109619: a worker reuses state that should have been cleared
A PHP worker can handle multiple requests over its lifetime. Some internal state may retain references to memory from a completed request. If that memory is freed without properly clearing the reference, a later request on the same worker can act on stale data. This is a use-after-free problem, described in the official stale global state advisory.
The operational lesson is that application login controls alone do not address flaws in the runtime underneath them. Updating the runtime is necessary even when the application appears healthy.
Is your business website affected?
PHP's announcement covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies mod_php as the highest-risk deployment in the demonstrated scenario. Check the runtime behind each hostname, not just the technology named on your home page.
For managed hosting, ask the provider which PHP version or patched package serves your account. If an agency manages the site, establish whether the agency or host owns runtime updates.
For self-managed servers, inventory the PHP services, virtual hosts, and containers. One machine can serve several sites through different runtime versions. Include staging sites and older subdomains that still accept requests.
For appliances and bundled software, check the vendor's advisory. NCSC-NL highlights products that embed PHP, including network devices and management interfaces. These may require a vendor firmware or product update rather than a manual PHP replacement.
A website served entirely as static files has no PHP runtime in that delivery path. Its related APIs, administration tools, and hosting accounts still need their own maintenance. An HTML-looking URL or the absence of a visible version header is not a reliable inventory method.
Which PHP versions contain the fixes?
These are the upstream fixed releases listed in the PHP announcement, checked on 23 October 2026. Use a later supported security release if your provider offers one.
| PHP branch | Upstream release containing both fixes |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Upstream numbers are only part of the check. A distribution or support vendor may backport the fixes into a package with an older base version. Verify the vendor's advisory and full package revision. For example, Ubuntu's CVE guidance explains how its package statuses and security notices identify available fixes.
PHP 8.1 and older have ended upstream support; check vendor coverage or plan a supported migration. PHP 8.2's security support ends on 31 December 2026, according to the PHP support schedule. An emergency patch and a longer-term upgrade can be separate maintenance tasks.
How to verify that the update actually took effect
Treat verification as a short record of the change, not merely a successful installation command. A practical sequence is:
- Identify the serving runtime. Record the website, service or PHP-FPM pool, deployment mode, and package or image revision. The PHP command-line documentation distinguishes CLI from other server interfaces. As an operational consequence, a shell's
php -vresult alone cannot prove which runtime serves a website. - Apply the correct update. Use the hosting provider, operating-system packages, product vendor, or maintained container image. Check application compatibility and retain a usable backup and recovery path.
- Replace the running processes. Restart the relevant PHP service or web server according to its deployment procedure, or redeploy updated containers. Confirm that old workers and old replicas are gone.
- Check the application. Verify the serving runtime again through trusted administration tools. Test the site's important functions, such as login, forms, uploads, and scheduled jobs. Avoid publishing a diagnostic page that exposes configuration details.
- Record the evidence. Save the fixed revision, advisory reference, deployment time, verification result, and responsible person. This makes follow-up work much easier when another site or server is discovered later.
Request filtering and restricted access can reduce exposure while maintenance is arranged. PHP states that its temporary mitigations are incomplete. Follow current vendor guidance and keep an owner and deadline for the actual patch.
What to check after patching
Patching closes the vulnerability; it does not establish what happened before the change. Review retained web and application logs, unexpected file changes, unfamiliar scheduled tasks, unusual processes, and suspicious outbound activity. Preserve relevant evidence before rebuilding a system that may have been compromised.
An absence of obvious errors is not proof that nothing happened. If investigation suggests an attacker could read application secrets, revoke and replace the affected database passwords, API tokens, or deployment credentials from a trusted environment. Coordinate those changes with the services that use them. A compromised host may need a clean rebuild as well as credential rotation.
What this teaches us about routine maintenance
For a small team, a useful maintenance record can be simple: system, runtime, maintainer, exposure, support deadline, and recovery method. That list makes a security announcement actionable without requiring everyone to understand memory internals.
Separate application updates from runtime updates, and give someone responsibility for verifying both. Keep administration access controlled and backups recoverable. For private business systems, our WireGuard discussion explains the role of a managed network path. LanPier applies an existing WireGuard connection to a customer-controlled maintenance workflow; the systems reached through it still need their own patches.
DigiPBX's public site is generated as static files and delivered through Cloudflare Pages, with a separate JavaScript function for connection diagnostics. It does not run PHP in that public delivery path and is not directly affected by these PHP runtime flaws. We still maintain its build process and hosting accounts. Different architectures change what needs attention; clear ownership makes that attention practical.