Updated 21 October 2026. Emergency patches are available.
CVE-2026-109618 and CVE-2026-109619 are PHP runtime vulnerabilities that can allow unauthenticated remote code execution. The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A vendor-confirmed backport is also a valid fix. Updating your application alone does not update its PHP runtime. PHP release guidance
Identify the runtime that serves real requests, update it, replace its old workers and check for compromise. PHP-FPM is affected too.
WordPress updates do not replace PHP
Updating WordPress, a theme or a plugin is useful maintenance, but these vulnerabilities are in the PHP engine beneath the site. A security plugin cannot certify that the server runtime is fixed. You need your host or server administrator to install the corrected PHP build and restart its workers.
Identify who is responsible
On managed or shared hosting, ask the provider to confirm its patch status. On an unmanaged VPS or cloud server, PHP is often not patched automatically: the owner or their developer must apply the update. If you administer the server, use the Ubuntu and Debian, AWS or DigitalOcean guide that matches your environment.
Check all domains, subdomains and staging sites in the hosting account. They can use different PHP versions. WordPress Site Health information can help identify the site's PHP version, and the host's runtime selector can show the selected branch. Neither a branch label nor a version number alone proves whether a vendor backport was applied.
Ask the host for a precise answer
Send your provider the affected domains and ask for the following information:
- The full PHP package or build revision serving each site.
- Confirmation that both CVE-2026-109618 and CVE-2026-109619 are fixed, with the matching vendor advisory.
- Confirmation that every old PHP worker has been replaced after patching.
- The status of other sites, staging environments and scheduled PHP jobs on the account.
- Availability of access and error logs from 20 October 2026 onward and assistance investigating suspicious activity.
If the provider offers a fixed supported branch in its PHP selector, back up the database and files, check compatibility and switch through the host's documented process. Test the site immediately. Do not select an older vulnerable branch to resolve a plugin problem; involve the developer or keep the site restricted while compatibility is corrected.
PHP 8.1 and older need a supported upgrade or a vendor-confirmed backport. PHP 8.2 security support ends on 31 December 2026, so a patch on that branch should be accompanied by an upgrade plan.
If the host has not patched yet
Ask the provider to restrict the site or serve static maintenance before requests reach PHP. A WordPress maintenance plugin still executes PHP. A WAF or disabled upload progress can reduce particular attack paths but is not a complete fix. Shared-hosting customers should not assume they can apply server-wide mitigations through a plugin or .user.ini file.
Check the site for signs of compromise
Download or ask the host to preserve available logs from 20 October onward. Review unexpected administrator accounts, recent plugin installations, changed themes, unusual scheduled tasks, unexpected PHP files in uploads and changes to wp-config.php. Compare core and extension files with trusted releases, accounting for legitimate customisations. A file scan or clean checksum result does not rule out database changes or stolen credentials.
If you have shell access, the dated file-change check in the main advisory can help identify files for investigation. On shared hosting, use the account's actual document root or ask support to run the check. Suspicious timestamps are leads, not proof; normal updates also change files, and attackers can disguise timestamps.
If compromise is suspected, preserve evidence, restrict access and involve the provider or incident responder. Restore trusted files and investigate persistence before reopening. Rotate exposed hosting, WordPress, database and application credentials from a clean device, and invalidate affected sessions. A backup taken after compromise may contain the same backdoor.
Test before considering the work finished
Confirm the active web runtime with the provider, then test administrator login, front-end pages, forms, media uploads, checkout where applicable and scheduled tasks. Review errors and ensure other sites on the account still work. Keep the provider's confirmation and the date of the worker restart with your maintenance records.
Get your PHP update completed
Send this guide to the person responsible for your server and ask for confirmation of the fixed runtime, completed worker restart and compromise review. If you need help, contact your hosting provider or development team with the package version, hosting platform and affected sites so they can act quickly.
Related guides
- Main PHP2Shell security advisory
- How to fix PHP on Ubuntu and Debian
- How to fix PHP on AWS EC2 ECS and EKS
- How to fix PHP on DigitalOcean
- How to fix PHP on Laravel Forge
- How to fix PHP on WordPress and shared hosting
