On 21 October 2026, PHP released security updates for CVE-2026-109618 and CVE-2026-109619. PHP states that the two critical issues can allow unauthenticated remote code execution. The UK National Cyber Security Centre (NCSC) and the EU Agency for Cybersecurity (ENISA) have both urged organisations to identify PHP-based systems, prioritise internet-facing services, and apply the released updates promptly. PHP security advisory · NCSC guidance · ENISA joint statement
This is not only a concern for teams that actively develop in PHP. A WordPress site, a managed commerce site, or an appliance with PHP embedded in its stack can depend on the same PHP runtime. Updating WordPress core, themes, and plugins does not prove that the underlying PHP vulnerability is fixed.
Confirmed Scope and Affected Deployments
PHP describes CVE-2026-109618 as an out-of-memory handling issue that can interrupt PHP while internal request data is only partially initialised. During later cleanup, invalid data may be treated as valid. CVE-2026-109619 concerns request-owned internal state that can remain after the backing memory has been freed, then be used by a later request on the same worker before normal initialisation resets it.
The PHP advisory says all PHP installations serving web requests should be assessed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies Apache mod_php as the highest-risk configuration, noting a demonstrated case in which an unauthenticated request can trigger the attack before application code runs. That is why application-level authentication alone is not an adequate response.
Defensive Inventory Priorities
The following are defensive inventory priorities, not exploitation instructions.
Public Request-Handling Services
Start with internet-facing domains, APIs, administration portals, forms, upload paths, import features, legacy sub-sites, and third-party products that ultimately route requests into PHP. The decisive question is whether a live request reaches an unpatched PHP web runtime—not whether a URL looks especially sensitive.
Runtime and Process Model
Record the web server, the PHP SAPI, the active binary/package version, the package source, and the application each deployment serves. Do not infer the production version from a build pipeline, a container tag, or a CLI command on a different host. PHP’s warning covers several SAPIs, while mod_php deserves the fastest review.
High-Value Commercial Assets
If code execution is achieved, the eventual impact depends on the web process identity, file permissions, network segmentation, and credential handling. A commercial site should treat customer records, orders, payment and logistics integrations, mail credentials, cloud-storage keys, backups, and administrator sessions as assets requiring immediate review. These are potential post-compromise consequences, not evidence that every affected site has already exposed them.
Potential Business Impact of Remote Code Execution
Remote code execution gives an attacker a possible foothold in the context available to the web process. Depending on the environment, the consequences can include:
- reading or altering application files, configuration, environment variables, or database-access details;
- changing content, workflows, or order-related records;
- leaving persistence mechanisms in writable areas or system configuration;
- disrupting service through resource consumption or damaged application state; and
- extending access to internal services where the web tier has excessive network or cloud permissions.
The actual blast radius is environment-specific. A disciplined response preserves relevant logs and assesses for compromise rather than assuming an upgrade by itself removes any prior persistence.
Fixed Releases and Older PHP Branches
PHP lists the following fixed releases:
| PHP branch | Fixed release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 and older no longer receive normal upstream PHP Project updates. Some operating-system distributions and LTS vendors may ship backported fixes, so an older-version deployment needs explicit confirmation that these two CVEs have been patched. PHP also published minimal source backports for 7.4, 8.0, and 8.1 to assist some self-built or non-LTS installations; that does not mean every managed host has already applied them.
Immediate Actions for PHP Teams
Build an Accurate Exposure List
Identify production, staging, disaster-recovery, operations, legacy, and embedded systems that run PHP. Mark public exposure, the real request-serving SAPI, version, owner, package source, and remediation window. NCSC specifically advises organisations not to limit discovery to old PHP versions: all PHP installations should be identified and assessed.
Patch, Restart, and Verify the Live Runtime
Upgrade the request-serving runtime to the applicable fixed release, then restart the relevant web and PHP worker processes under the normal change-control process. Validate the business paths that matter for the deployment, such as login, checkout, forms, uploads, or APIs. PHP is explicit that temporary measures do not provide a complete solution; the update is the objective.
Review Permissions and Signs of Compromise
Reduce unnecessary write access from the web account and unnecessary access to secrets, backups, internal services, and cloud credentials. For systems that were publicly exposed before remediation, review web, PHP, host, and identity logs for unusual requests, unexpected processes, file changes, or unknown privileged accounts. NCSC recommends assessing for evidence of compromise and backdoors when a system cannot be immediately updated or disabled.
A WordPress-Specific Response for Commercial Sites
Treat the PHP Runtime as a Business-Critical Dependency
WordPress executes on PHP. E-commerce, membership, booking, lead-generation, and content-revenue sites should put the underlying PHP patch alongside payment, customer-data, and availability risks. Ask the host, managed-service provider, or operations team for action now; do not limit the response to a plugin update campaign.
Protect the Transaction and Customer-Data Path
Identify the sites that collect forms, take orders, handle accounts, send transactional email, or connect to payment and CRM systems. Confirm that backups are usable, privileged WordPress accounts are limited, credentials are not publicly exposed, and there is a plan to rotate sensitive integration credentials if compromise is suspected. Do not treat deletion of a suspicious file as a complete incident investigation.
Obtain Verifiable Hosting Status
Request the active PHP version and SAPI for the site, confirmation that the two CVEs are patched, the completion time for upgrade and restart, the status of other sites in the account, and the exposure-reduction plan while remediation is pending. ENISA likewise advises organisations to coordinate with hosting and service providers and to prioritise internet-facing systems.
Containment When Patching Is Delayed
PHP documents temporary measures that may reduce exposure to particular paths, but it clearly states that they do not make an installation safe. Evaluate any temporary configuration change in the site’s own environment and treat it as a bridge to upgrading—not a replacement for it.
Where a timely patch and reliable temporary mitigation are not feasible, NCSC and ENISA both recommend considering isolation of exposed applications from public networks until the fix can be applied. That decision has commercial costs, but continuing to expose a high-value customer or transaction system without a viable remediation path is itself a business-risk decision.
A 48-Hour Response Sequence
- Hours 0–4: Identify PHP deployments; flag public systems, Apache
mod_php, and systems handling commercial transactions. - Hours 4–24: Upgrade to the relevant fixed release, restart request-serving processes, and perform focused business validation.
- Hours 24–48: Obtain provider status for managed and bundled products; review logs, writable locations, privileged accounts, and sensitive credentials as appropriate.
- Ongoing: Establish a migration or verified vendor-backport plan for unsupported branches so future critical releases do not remain blocked by end-of-life software.
