On 21 October 2026, PHP released urgent fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. Updating comes first. Then review why an internal application is directly reachable from the public Internet.

Patch first. Reduce exposure permanently. Private access is an additional defence, not a replacement for security updates.

What PHP has confirmed

The official PHP advisory describes two runtime issues, rather than flaws in a particular application:

Vulnerability	Issue	Potential impact
CVE-2026-109618	Out-of-memory handling can leave internal request data partially initialised; subsequent cleanup may treat invalid data as valid.	Unauthenticated remote code execution.
CVE-2026-109619	Request-owned internal state can survive after its backing memory has been freed and be reused by a later request in the same worker.	Unauthenticated remote code execution.

PHP’s 20 October advance notice rates both CVSS v4.0 9.2, Critical. The risk covers web-serving installations including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

PHP identifies mod_php as the highest-risk configuration, with a demonstrated exploit triggered by an unauthenticated request before application code runs. That specific path should not be described as identical across every runtime. A demonstrated exploit is not, by itself, confirmation of attacks in production.

Fixed versions: update and verify

Branch	Fixed release published on 21 October
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Install these versions or a later update containing the fixes. Distribution and LTS packages may use different version numbering: check the vendor’s security advisory.

PHP 8.1 and older no longer receive ordinary upstream maintenance. PHP supplied minimal emergency source backports for 7.4, 8.0 and 8.1, but this does not restore support for those branches. Confirm a vendor patch or migrate to a supported branch.

After updating, restart the relevant processes and verify the runtime actually serving web requests, not just the command-line version. PHP-FPM, Apache and containers may run different versions.

An application login is not always a runtime barrier

An internal ERP, CRM, intranet or administration panel may be published on a public port 443. Before reaching its login, a request passes through the web server and, depending on deployment, PHP.

Internet → public web server → PHP → application login

A flaw reachable before application code can bypass the protection people expect from that login. This does not mean every PHP application is exploitable in the same way; it means runtime exposure deserves a separate assessment.

What ConnectaSec Access changes

An application intended only for authorised staff or suppliers can remain on a private network, with access controls applied before reaching its origin.

User → identity and access policy
     → secure connection → connector → private application

A correctly configured ConnectaSec Access deployment can use outbound connectivity without publishing inbound ports on the application server. Identity and policies determine access to the resource. The Microsoft 365 integration helps manage users and groups; specific authentication and MFA capabilities depend on configuration and the identity services in use.

Direct access to the origin must also be closed: old public addresses, alternative DNS names and firewall rules can leave the original path exposed. Adding a layer without removing direct origin access does not achieve this architecture.

Access does not fix the vulnerability

PHP remains vulnerable until patched. A malicious authorised user, compromised device or misconfigured alternative path can still present a risk.

Private access can reduce the ability of an anonymous Internet attacker to contact the private backend directly. This is valuable defence in depth, including during an urgent patching window, but it does not make a vulnerable installation safe.

PHP lists temporary measures that reduce specific exploitation paths and explicitly states that only an update is a complete solution. Do not change memory or request-processing settings blindly: availability implications need assessment by the responsible team.

Five actions for businesses and MSPs

Inventory PHP servers, containers and applications, identifying public exposure.
Update the runtime or install a vendor-confirmed patch without waiting for another security layer.
Verify active web workers and inspect logs for compromise; patching does not remove a previous intrusion.
Remove unnecessary exposure from internal applications and check for direct origin access.
Review permissions so employees and suppliers reach only the resources they need.

A public website needs to remain public. An internal ERP or administration panel does not necessarily need the same exposure. Explore the ConnectaSec platform to assess private resource access.

Private applications should remain private

A lower-layer vulnerability can compromise an application even when its login is well designed. Updating is essential; reducing exposure is an additional, permanent defence.

Request a demo to review access to your internal applications.

Official sources

Reviewed on 22 October 2026. “PHP2Shell” is not an official name in the cited advisories; this article uses the CVE identifiers.