Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed on October 21, 2026, both scoring 9.2 out of 10 on the CVSS v4.0 scale. Both flaws allow unauthenticated remote code execution on web servers running PHP. Updating your CMS alone won't fix an engine-level flaw: the PHP runtime itself must be patched, and every active process must reload the corrected version.
🚨 Organizations should immediately patch critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619. These vulnerabilities enable unauthenticated #RCE and affect PHP installations serving web requests. Learn more: 🔗 https://t.co/8vu6SvNzfB pic.twitter.com/LUWik7aQcG
— CISA Cyber (@CISACyber) October 21, 2026
Cloudflare has reported observing active attack traffic targeting its customers, according to the Cloudflare blog. CloudLinux has separately flagged traffic matching known exploit patterns. These observations signal real hostile activity, though they don't confirm every vulnerable installation has been compromised.
Two Distinct Memory Management Bugs
CVE-2026-109618 targets PHP's behavior when a request exhausts available memory. The interruption can leave internal data structures partially initialized. When the request shutdown sequence runs, the process may treat those incomplete structures as valid, creating a window for remote code execution without any credentials, operating with the privileges of the web process account.
CVE-2026-109619 is a use-after-free bug: an internal reference remains accessible after the memory it pointed to has been released. A subsequent request handled by the same process can reach those now-invalid pointers. The official advisory confirms that remote code execution has been demonstrated here as well. Gaining remote code execution doesn't automatically mean gaining system administrator privileges: the initial impact depends entirely on the permissions of the compromised web process.
Which Servers Are Exposed
The PHP project's advisory covers installations that handle web requests via PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The project rates the risk highest for Apache with mod_php, where a demonstrated exploit path can activate before the application code even begins to execute. An input validation check placed inside the CMS or application layer cannot therefore be considered adequate protection for that configuration.
Risk is not uniform across setups. The advisories distinguish between demonstrated exploit paths and conditions that depend on execution mode, loaded extensions, and application behavior. For CVE-2026-109619, remote execution has been validated through the session management cycle in PHP-FPM as well. Running PHP-FPM alone doesn't make a server safe.
Three Things to Remember
- Severity: two critical vulnerabilities, both rated CVSS v4.0 9.2.
- Fix: update the PHP engine and ensure the corrected code is loaded by every process serving web traffic.
- Verification: check the engine actually used by the web server, not just the binary available in the terminal.
Correct Versions and the Backport Question
The PHP project has identified the first corrected releases across its four maintained branches. The version numbers listed in the advisories refer to packages distributed directly by the project. For Linux distribution packages and vendor-supported builds, you must also consult the relevant vendor security bulletin, since those may carry corrections backported to older upstream version strings.
Two critical vulnerabilities have been identified in PHP, a widely used programming language that powers websites and web applications. These vulnerabilities (CVE-2026-109618 and CVE-2026-109619) could allow malicious cyber actors to remotely execute code in PHP core, potentially… pic.twitter.com/tnwiQv5v0F
, FBI Cyber Division (@FBICyberDiv) October 21, 2026
The corrected version numbers are listed in the official advisories for both CVE-2026-109618 and CVE-2026-109619.
PHP 8.1 and all earlier branches no longer receive updates from the PHP project, but some vendors maintain packages with backported fixes targeting older upstream releases. For those packages, the upstream version string alone is not enough to determine whether the correction is present: you need to check the specific package revision and the vendor's own security bulletin. PHP 8.2's official security support ends on December 31, 2026, which means applying this patch and planning a version migration are two separate and equally urgent tasks.
How to Update and Verify the Result
The update must cover every PHP installation active on the server. A single system can host multiple PHP versions, multiple sites, and separate process pools. cPanel documentation, for instance, distinguishes the panel's own internal PHP from the EasyApache packages serving hosted sites. Plesk and CloudLinux publish separate guidance for their specific components and platforms: check the relevant bulletin for your actual environment before proceeding.
Daniele Molteni
Running php -v in the terminal identifies the PHP binary in your shell path, which may differ from the engine actually configured for your site. A check through the hosting control panel or a diagnostic page served by the web server itself gives you the correct picture. If you use phpinfo(), restrict access strictly and remove the page immediately after the check: it can expose file paths, configuration values, HTTP headers, and environment variables. Work through the following sequence with your system administrator or hosting provider:
- Prepare a backup or snapshot with a tested restore procedure ready before touching anything.
- Identify all PHP versions and components in use, including engines assigned to individual sites and those used by control panel software.
- Install the correct packages through your distribution's package manager or the vendor's official update tooling.
- Restart all affected services and processes, following the instructions specific to PHP-FPM, Apache, or your environment: old processes must not continue handling requests after the update.
- Verify the result from both the terminal and the site, confirming the version number, package revision, and correct operation of your applications.
WAF Rules and Temporary Measures Are Not a Substitute
Cloudflare and CloudLinux have deployed rules to intercept certain exploit patterns, as reported on the Cloudflare blog. These provide an additional layer of defense, not a removal of the flaw from the server itself. Cloudflare explicitly recommends applying PHP updates even when its WAF protections are active.
Configuration-level mitigations described in the official advisories also cover specific attack paths only and don't represent a general solution. They must be evaluated against your application stack and applied at the correct point in the configuration. Full protection from both vulnerabilities requires the corrected code distributed by the PHP project or delivered through a vendor package that includes the patches.
The Check That Actually Matters
The decisive verification is what the server is actually running. A newer package version in the package manager, or a control panel showing its latest release, doesn't by itself confirm that every site has stopped using the old engine. The check must reach all the way down to the process receiving and handling live web requests.
For administrators, the intervention is complete only when three verifiable outcomes are in place: patches installed, processes updated, and applications confirmed working. Working through each step in order avoids the common mistake of confusing patch availability with patch application. Watch the PHP project's supported versions calendar at php.net to plan any 8.2 migration before the December 31, 2026 end-of-support date arrives.
Sources
- PHP, official announcement of October 21, 2026.
- PHP, advisory CVE-2026-109618 and advisory CVE-2026-109619.
- PHP, supported versions calendar.
- Cloudflare, observed attacks and WAF protections.
- CloudLinux, update and mitigation status.
- cPanel, release notes and Plesk, bulletin on affected components.
- PHP manual: command-line options and information exposed by phpinfo.
