On October 21, 2026, PHP released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical flaws that can allow unauthenticated remote code execution. The latter is the “use after free” issue: a worker can retain a pointer to memory from a completed request, then use that stale state in a later request. The first concerns out-of-memory cleanup during partial request initialization. PHP identifies all web-facing PHP installations as in scope and calls out Apache mod_php as the highest demonstrated risk.
This is a PHP engine issue beneath both EZCMS and WordPress. Updating either application alone does not replace the PHP build used by the web server. The immediate job is to identify the PHP build actually serving each site, apply a fixed vendor build, restart workers, and verify the result. On October 23, PHP also advised a temporary setting for a separate, uncommon session upload progress path.
What happened and what is fixed
CVE-2026-109618 lets an allocation failure interrupt PHP while request data is only partly initialized; later cleanup can treat invalid data as valid. CVE-2026-109619 concerns request-owned state that survives after its memory is freed. A later request on the same worker can encounter that stale pointer before normal initialization resets it. These are memory-handling defects in PHP, not evidence that every EZCMS or WordPress installation has been compromised. PHP reports demonstrated unauthenticated code execution for mod_php; PHP-FPM and other web SAPIs also need updating.
PHP's October 21 fixed releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 8.1 and earlier have no standard upstream release, though an OS or long-term-support vendor may supply a backport. A vendor-patched package can retain an older-looking PHP version string, so record its package release and security advisory as well as the PHP version. PHP says an updated build is the only complete remedy for the two October 21 issues; request limits, worker isolation, and WAF rules are exposure controls, not substitutes. See the PHP release advisory and supported branches.
October 23 follow-up: PHP recommends setting session.upload_progress.enabled=0 until the next regular bug-fix release to cover an unlikely additional route, CVE-2026-115560. PHP says this route requires an unusual combination: configuration starts with the php_binary or php_serialize session handler, application code switches to php before session_start(), and upload progress remains enabled. Check application compatibility, apply the setting at server level where appropriate, restart the PHP workers, and track the next PHP advisory. The October 21 fixed releases still need to be installed. See PHP's October 23 notice.
Which update belongs to whom?
Shared or managed hosting: the provider usually installs and patches the server's PHP binaries, extensions, and worker services because those are shared server components outside a site's files and CMS admin. The site owner can often choose a supported PHP branch in the hosting panel, but must ask the provider whether the selected branch has the fixed or backported build, when it was applied, and whether all workers were restarted. A version selector alone does not prove the security patch landed.
EZCMS Business Sites: use the EZCMS administration Check/Run flow to keep Core current, then test pages, admin login, forms, product content, and integrations after the host's PHP patch. Core updates improve CMS code but do not patch the interpreter. EZCMS Core requires PHP 8.3 or newer, so a host's move from an older branch needs compatibility testing. WordPress: back up the database and files, use Dashboard > Updates for WordPress core, plugins, and themes, and check Tools > Site Health > Info > Server for the web PHP version. WordPress updates also do not replace server PHP; follow the host's PHP selector or ask support to patch it. See WordPress update instructions and its PHP upgrade guide.
Net Management: one incident workflow for every customer
- Inventory and assign an owner. List each public site, host, environment, PHP branch, package origin, web SAPI (mod_php, PHP-FPM, LiteSpeed or other), and who controls the guest OS. Check every pool and node;
php -v reports CLI PHP and may differ from the build handling HTTP requests. - Confirm patch evidence. Match the installed build to the PHP fixed release or the OS vendor's security bulletin/backport for both CVEs. Record the package version, bulletin, deployment time, and worker restart. Treat an unsupported branch without a documented vendor fix as an urgent migration item.
- Protect and patch. Take a tested backup or VM snapshot, use a staging node where available, apply trusted vendor packages or rebuild the approved image, and restart the correct PHP-FPM/Apache/LiteSpeed workers. Do not download an unverified binary or assume a WordPress/EZCMS update resolves this engine flaw.
- Verify and monitor. Confirm the web-serving PHP build, package advisory, and fresh worker processes; exercise login, uploads, contact forms, checkout or business workflows, and admin editing. Review web and PHP error logs for crashes and suspicious activity. Escalate signs of compromise to an incident review rather than treating a successful patch as proof the server was never abused.
- Record closure. For each customer, mark provider confirmation requested/received, build verified, workers restarted, smoke test passed, and any remaining migration or October 23 setting task. Recheck when a later vendor advisory changes the answer.
Webmin and terminal: self-managed Linux servers
In Webmin, sign in with authorized server administration access and open System > Software Package Updates. Refresh available updates, identify the PHP packages and their repository, review the offered versions and advisory, then apply the vendor update. If the page offers no fixed build, inspect the configured repository or vendor support; Webmin presents operating-system package updates but does not itself publish PHP fixes. Check the relevant PHP-FPM or web-server service in Webmin and restart it after the package change. Confirm with a web request and the vendor's package record. See Webmin's module guide.
For Debian/Ubuntu, a qualified operator can use sudo apt update, inspect apt list --upgradable and apt-cache policy php8.3-fpm (substitute the installed branch/package), then use the approved repository's update process, for example sudo apt upgrade. For RHEL-family hosts, use sudo dnf updateinfo list security and sudo dnf upgrade --security where that repository publishes security metadata. Check the exact package release with dpkg-query or rpm -q, then restart the installed PHP-FPM version and/or Apache service. Service names vary; inspect systemctl list-units '*php*fpm*' 'apache2*' 'httpd*' before restarting. Test the actual site because CLI and web SAPIs may have different configurations. Avoid leaving a public phpinfo() page behind.
If a fixed build is not immediately available, follow the PHP advisory's temporary controls, including disabling session upload progress at server level and restarting all workers. PHP describes additional request-size and memory controls, but warns no configuration mitigation is complete. For a highly exposed system with no patch path, restrict access or take it offline until the risk is resolved.
Azure, AWS, and on-prem responsibility
Azure VM: the customer or their Net Management provider owns guest OS and application patching. Use Azure Update Manager to assess and deploy available packages, then confirm the PHP vendor bulletin and application tests. Update Manager draws from the machine's configured package sources; it does not manufacture a missing PHP fix. Azure App Service is different: Microsoft manages its platform OS and runtime, while the customer still checks the selected runtime, compatibility, and app-level changes. See Azure shared responsibility and Update Manager operations.
AWS EC2 or a self-managed Lightsail server: the customer or management provider owns guest OS and PHP packages. AWS Systems Manager Patch Manager can scan and install updates on managed EC2 and enrolled on-prem nodes, but relies on approved package sources and still needs verification. See AWS shared responsibility and Patch Manager. On-prem: follow the same package, restart, validation, and incident record steps; also confirm backups, firewall exposure, and out-of-band access before an emergency change.
Emblaze.Ca