PHP Patches Two Critical Remote Code Execution Flaws: What IT Teams Should Do Now

PHP runs a very large share of the web, including content management systems, ecommerce platforms and internal business tools, so a critical flaw in the language runtime affects far more than developers. IT teams that run any PHP application should treat this as an urgent patch-now item.

Facts below come from the PHP project's own security announcement, the GitHub security advisory for CVE-2026-109618 and TechCrunch reporting published October 21, 2026. The official PHP site is php.net.

What Happened

The PHP project announced on October 20, 2026 that a critical security release would arrive at 14:00 UTC on October 21. The release shipped fixes for CVE-2026-109618 and CVE-2026-109619, both described as critical flaws allowing unauthenticated remote code execution.

According to the PHP announcement, the fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advance notice rated both issues at CVSS v4.0 9.2. The project's wording is blunt: "There are no complete mitigations, updating is the only safe choice."

• CVE-2026-109618: out-of-memory handling can interrupt PHP while internal request data is only partly initialized, so cleanup may treat invalid data as valid. The GitHub advisory says attackers can trigger the condition through multipart request parsing and describes remote code execution as the web worker user, demonstrated against mod_php with default settings.
• CVE-2026-109619: request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use that stale state before it is reset.
• Affected setups: 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.

TechCrunch reported that the U.S. National Security Agency warned on the same day that sites that cannot be patched immediately should be taken off the web until they can be, and that the flaws were found with help from AI-assisted research by security firms including Wiz and a researcher in OpenAI's Patch the Planet effort. OpenAI said it knew of no reports of exploitation in the wild at the time of that report.

Why It Matters

Unauthenticated remote code execution means an attacker needs no login to run code on a server. Because the PHP project says the risk is highest for mod_php, where a request can trigger the attack before application code runs, normal application-level defenses may not help.

PHP powers a large part of the web. TechCrunch cited estimates of roughly 70% of websites and over 33 million sites, though counts vary by source. PHP also notes that 8.1 and older no longer receive project updates, so unmaintained servers are most exposed. Attackers often reverse engineer patches quickly, and TechCrunch quoted Wiz warning that language models can help adapt exploits, so the window to patch is short.

What It Means for B2B SaaS Buyers and IT Teams

Any vendor, agency or internal app running PHP may be exposed, including CMS-based marketing sites, customer portals and legacy admin tools. Ask your SaaS vendors whether they run PHP and when they patched, and track your own servers separately.

• Inventory first: you cannot patch what you cannot find. An IT asset management tool or CMDB can list servers and runtimes.
• Include third parties: ask hosting providers, agencies and SaaS vendors for patch status in writing.
• Check managed hosting: shared hosts and platforms may patch on their own schedule, so confirm the version on your account.
• Scan exposure: use vulnerability management software and website security tools to find vulnerable PHP versions and public endpoints.

What to Do Now: Patch Checklist

Update to a fixed release today: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run PHP 8.1 or older, upgrade to a supported version, use a vendor backport or apply the project source backports, and take systems offline if you cannot patch.

1. List every server, container image and managed host that runs PHP, and record versions.
2. Update to a fixed version, or install your Linux distribution's patched package. The PHP project says distributions received the patches in advance.
3. Restart PHP-FPM or Apache workers after updating so the new code is loaded.
4. For PHP 8.1 and older, use vendor backports or the minimal source backports the project published, and plan an upgrade. PHP 8.2 reaches end of life on December 31, 2026.
5. If you cannot patch immediately, apply the stop-gap limits in the PHP announcement (request size and upload limits, disabling upload progress tracking, restarting workers), knowing they reduce exposure but do not make an installation safe.
6. Rebuild container images and redeploy; check CI/CD base images for old PHP layers.
7. Review web server and application logs for unusual large or malformed multipart requests from October 21 onward.

The PHP project also warned that the volunteer-maintained rpms.remirepo.net repository would not have updates on release day, so teams using it should switch to distribution packages or build from source.

Related Reading and Categories

Use this event to test your patch process. The same checks apply to other recent critical bugs in remote access and security tools, such as the BeyondTrust zero-day we covered earlier, and to the software categories that help you find and fix exposure.

• Read our earlier note on the BeyondTrust Remote Support zero-day.
• Browse Vulnerability Management Software for scanning and prioritization tools.
• Browse Website Security Software for monitoring and protection options.
• Browse IT Asset Management Software to keep a live inventory of runtimes and servers.

Frequently Asked Questions

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
The fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, 2026. PHP 8.1 and older no longer receive project updates, so use a vendor backport, the project source backports or upgrade to a supported release.

Can we mitigate these PHP flaws without upgrading?
The PHP project lists stop-gap settings such as stricter request size limits and disabling upload progress tracking, but says they reduce exposure without making an installation safe. It states that updating is the only safe choice, so treat mitigations as a short bridge.

How do we know whether our SaaS vendors are affected?
Ask each vendor whether their product or hosting stack runs PHP, which versions are deployed and when patches were applied. Request written confirmation for critical systems, and include a patch-timeline clause in future security questionnaires.