Two critical PHP vulnerabilities were patched on 21 October 2026, and anyone running PHP-powered websites should take them seriously.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote code execution (RCE).
In practical terms, that means an attacker may be able to make a vulnerable server execute code without first having to log in.
The PHP project has released fixed versions:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
For businesses running WordPress, WooCommerce or other PHP applications, this is not an update to leave sitting in the queue.
Why these PHP vulnerabilities matter
These vulnerabilities affect PHP itself rather than a particular WordPress plugin, theme or web application.
With many website vulnerabilities, an attacker has to target a specific vulnerable plugin or piece of application code.
A vulnerability in the PHP runtime sits lower down the stack and can potentially affect a much wider range of websites and applications.
CVE-2026-109618 concerns memory corruption during PHP’s out-of-memory handling, while CVE-2026-109619 involves internal request state surviving after the underlying memory has been released.
Under the right circumstances, either can result in remote code execution.
Affected configurations can include systems using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
Why Plesk users need to check more than the control panel
For Plesk servers, installing the fixed PHP version may not be as simple as clicking Check for Updates.
Plesk distributes its own PHP packages through its software repositories.
A server may therefore still be running an older vulnerable version even after the fixed PHP packages have been published.
One possible situation is:
- PHP 8.4.26 remains installed.
- Plesk has already published PHP 8.4.27.
- The Plesk interface shows no obvious PHP update.
- The operating system still reports the older version as its current package candidate.
This can happen if the server has not successfully refreshed or authenticated the latest Plesk repository metadata.
The result is potentially misleading: the PHP security update exists, but the server does not yet recognise it as an installable update.
A Plesk repository signing key can block the PHP update
Software repositories are cryptographically signed.
Before a Linux server trusts new package information, it checks that the repository metadata has been signed by a trusted vendor key.
During a signing-key change or rollover, a Plesk server that does not yet have the new public key may produce an error such as:
NO_PUBKEY
The server may then continue using older cached repository information.
That creates a confusing situation where:
The security update exists, but the server cannot safely see or install it.
The package itself may already be available from Plesk while the local server still reports that no newer version exists.
Don’t bypass repository signature checking
When a critical security update is waiting, it can be tempting to force APT to accept an untrusted repository.
Don’t.
Repository signature checking is one of the protections designed to prevent an attacker from supplying malicious software packages.
Disabling that verification to install a security patch simply creates a different security problem.
Instead, the correct approach is to repair the Plesk repository trust chain using Plesk’s supported update or repository-key mechanisms.
That may include refreshing Plesk Components/System Updates or restoring the current official Plesk repository signing key.
The full signing-key fingerprint should be verified before it is trusted.
Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
For the currently supported affected PHP branches, the security releases are:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
A Plesk server still running PHP 8.3.35, 8.4.26 or 8.5.11 should not be assumed safe simply because its control panel says there are no available updates.
The actual repository and installed package state should be checked as well.
Check more than the PHP version number
A proper PHP security update check should confirm several things:
- Which PHP versions are actually installed.
- Which version the authenticated Plesk repository currently offers.
- That repository signature verification succeeds.
- That every installed package in the relevant PHP family has updated.
- That PHP-FPM is actually running the patched version.
- That websites behave normally after the update.
This matters because PHP is normally installed as a family of packages rather than one single package.
For example, PHP 8.4 may include the base runtime, CLI, FPM, MySQL support, XML, mbstring, GD, OPcache and numerous extensions.
Updating only part of that package family can leave the installation inconsistent.
Plesk’s sw-engine PHP runtime is separate
There is another component Plesk users need to be aware of.
Plesk uses an internal package called sw-engine.
This is separate from the PHP versions used to run hosted websites.
sw-engine provides a PHP runtime used internally by parts of the Plesk control panel and related processes.
That means a server can reach a situation where:
- Website PHP 8.3 is patched.
- Website PHP 8.4 is patched.
- Website PHP 8.5 is patched.
- Plesk’s internal
sw-enginePHP runtime is still waiting for a separate vendor update.
Server administrators therefore need to check both the hosted PHP packages and Plesk’s internal PHP runtime.
Updating one does not automatically mean the other has been fixed.
What could successful PHP RCE exploitation allow?
Because these vulnerabilities can lead to remote code execution, a successful attacker could potentially:
- execute commands under the web-server or PHP account;
- upload or create a webshell;
- modify website files;
- download additional malicious software;
- steal application credentials or configuration data;
- establish persistence through cron or systemd;
- attempt privilege escalation;
- use the compromised server for scanning, spam, malware or cryptocurrency mining.
The exact impact depends on the permissions available to the compromised PHP process and whether the attacker can escalate further.
Patching PHP is only half the job
For a critical remote-code-execution vulnerability, installing the security update should not automatically be treated as the end of the incident.
Administrators should also review available evidence covering the period when the vulnerable PHP version was exposed.
Useful areas to examine include:
- Apache and nginx access/error logs
- ModSecurity events
- PHP-FPM logs
- Plesk authentication and administration logs
- ImunifyAV or Imunify360 detections
- SSH and sudo activity
- unexpected users or SSH keys
- cron jobs and systemd services
- recently created PHP files
- writable upload and temporary directories
- unexpected processes
- unusual network listeners or outbound connections
Automated scanning and exploit probing are common once a serious vulnerability becomes public.
A blocked exploit attempt is not the same thing as a successful compromise.
The important question is whether there is evidence that attacker-controlled code actually executed or that a persistence mechanism was created.
ModSecurity can help, but it does not replace patching
A web application firewall such as ModSecurity may block some exploit attempts before they reach PHP.
That is useful additional protection, but it should never be treated as a substitute for installing the security update.
Attack techniques change, signatures may not recognise every variation and a sufficiently unusual request may bypass an existing rule.
The correct order remains:
Patch the vulnerability first, then use security controls and logs as additional layers of protection and investigation.
What Plesk server owners should check now
If you run a Plesk server, check:
- which Plesk PHP versions are installed;
- whether they are on the fixed security releases;
- whether Plesk’s repositories authenticate correctly;
- whether newer PHP packages exist even if the GUI reports no updates;
- whether PHP-FPM is actually running the patched version;
- whether
sw-enginehas a separate security update available; - whether logs show attempted or successful exploitation.
If repository authentication fails with a missing public key, repair the trust chain using Plesk’s supported mechanism.
Do not disable signature verification simply to force the PHP update through.
The wider lesson from this PHP security update
This incident highlights something that often gets missed in server security.
A vendor announcing that a patch has been released does not necessarily mean every server has successfully received it.
There are several steps between publication and protection:
Patch published → repository updated → repository authenticated → package metadata refreshed → package installed → service restarted → version verified
A failure anywhere in that chain can leave a server vulnerable while everything appears normal from the control panel.
For critical vulnerabilities such as CVE-2026-109618 and CVE-2026-109619, the final installed and running PHP version is what matters.