Critical PHP flaws allow remote code execution. Update this week.

The short version

What happened, in plain English

PHP is the programming language behind a great many websites, including content management systems such as WordPress and Joomla. When PHP runs out of memory while handling a web request, it abandons the work abruptly. The PHP security advisories explain that, in some situations, this leaves PHP's internal bookkeeping half-built or still pointing at memory that has already been released. Cleanup code, or a later request handled by the same worker process, can then trust that bad data. An attacker who arranges the right sequence of requests may be able to turn that into running their own code on the server.

The first flaw (CVE-2026-109618) is about the half-built state during an out-of-memory failure. Per the advisory, specially shaped file-upload requests can exhaust memory while staying within configured limits. The second (CVE-2026-109619) is about state that outlives the request that created it, so a later request can use it before PHP has reset it.

The advisories describe the confirmed impact as unauthenticated remote code execution with the privileges of the web worker account. In plain terms: no login is needed, and the attacker's code runs with the same permissions as the website. That account can usually reach the site's files and configuration. CVSS rates attack complexity as high, which reflects how hard the attacks are to get right, not that they can be ignored.

Is it being exploited?

As of our last verification, the PHP project's announcements, its GitHub advisories and the NVD entries do not state that these flaws are being exploited in the wild, and we did not find them in CISA's Known Exploited Vulnerabilities catalog. They do state that remote code execution has been demonstrated: against Apache mod_php for CVE-2026-109618, and against Apache mod_php and PHP-FPM for CVE-2026-109619. Wiz Research, in a write-up referenced by NVD, reports demonstrations against default WordPress, Drupal and Joomla installations. Details are public and a patch exists, so treat this as urgent.

Who is affected

• Versions. The PHP project lists PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. NVD's configuration data lists earlier versions as affected as well, from 7.3.0 for CVE-2026-109618 and from 5.4.0 for CVE-2026-109619, so treat older unsupported versions as exposed.
• Web servers. PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php.
• Your website platform. The flaws are in PHP, not in WordPress, Joomla, Laravel or any plugin, so updating your CMS does not fix them. The server's PHP version is what matters.
• Vendor-managed sites. If an agency, developer or hosting provider runs your PHP, they control the patch. You still need to ask.
• Old versions. PHP 8.1 and older no longer get updates from the project. Some Linux distributions and long-term-support vendors backport fixes. A site with no PHP at all is not exposed to these flaws.

What to do this week

1. Find out where PHP runs. List your public website, customer portal, intranet, plugins and any vendor-hosted applications built on PHP.
2. Ask your host or IT provider for the facts. Which PHP version is running, and has the October 21 security update been applied? Backported packages can keep an older version number, so ask for the vendor's security notice rather than relying on the number alone.
3. Patch. The PHP project says updating is the only complete fix. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release in your branch, and restart every PHP worker. PHP 8.2 reaches end of life on December 31, 2026, so plan a move to a newer branch.
4. If you cannot patch today, the PHP project lists measures that reduce exposure to specific attack paths but do not make a server safe: enforce a memory limit of -1 at the server level, set a low post_max_size, set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0. Have someone who understands the trade-offs apply them.
5. Add a layer in front. The advisory suggests enforcing request-size limits at the web server or proxy, and blocking multipart uploads where an application does not need them. A web application firewall (WAF) can help but does not replace the update.
6. Check your backups. Confirm a recent copy exists that an attacker on the server could not alter, and test a restore.
7. Turn on logging and watch it. Wiz suggests looking for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies and unexplained PHP worker restarts. A clean log is not proof of safety, per the PHP advisory. If you suspect a compromise, involve a professional and rotate credentials.

One more item: on October 23, 2026, PHP published an informational advisory suggesting session.upload_progress.enabled=0 until the next regular bugfix release, relating to CVE-2026-115560, with a full advisory promised in that release. The project says it needs an unusual combination of configuration and application code.

Need a second set of eyes?

Not sure what runs PHP, or what to ask the people who run it? A free assessment is a good place to start. Use the contact form and tell us about your business. This page is general information, not individual advice, and the situation may change as PHP and others publish updates.

Sources

Primary sources, checked October 24, 2026:

• PHP.net news: security advisory (October 21, 2026) and informational advisory (October 23, 2026)
• PHP 8 ChangeLog (8.5.12 and 8.4.27 entries)
• GitHub advisory GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)
• GitHub advisory GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)
• NVD entry for CVE-2026-109618
• NVD entry for CVE-2026-109619
• PHP security team announcement for CVE-2026-109618 (oss-security)
• PHP security team announcement for CVE-2026-109619 (oss-security)
• Wiz Research write-up (third-party research, referenced by NVD)
• CISA Known Exploited Vulnerabilities catalog (checked for these CVEs)