Two critical PHP vulnerabilities. Here's what to fix.

On 21 October 2026, the PHP security team released fixes for two critical vulnerabilities that may allow attackers to execute code remotely without logging in. This is an urgent patching event — not evidence that every PHP website has already been compromised.

What actually happened?

On 20 October, PHP warned that a critical release was coming. On 21 October, the maintainers published patched versions and technical advisories for CVE-2026-109618 and CVE-2026-109619. Each received a critical severity rating of 9.2 under CVSS v4.0.

The most important distinction: these are problems in the PHP runtime, not necessarily bugs introduced by a particular WordPress theme, Laravel application or plugin. A vulnerable PHP engine may be attacked before your application's normal protections have a chance to run.

The two vulnerabilities, explained

CVE-2026-109618 — unsafe handling of out-of-memory failures

PHP can interrupt work when a request runs out of memory. In vulnerable releases, that interruption may happen while internal request data is only partly initialized. Cleanup can then interact with invalid memory. Researchers demonstrated unauthenticated remote code execution against Apache mod_php; other deployment modes require their own risk assessment.

CVE-2026-109619 — stale internal state across requests

Some request-specific internal state can remain accessible after its underlying memory has been freed. Another request processed by the same worker may interact with that stale state. This creates a route to memory corruption and, in some conditions, remote code execution.

Which PHP versions need updating?

According to the PHP project's 21 October security advisory, these are the fixed releases for the maintained branches:

PHP 8.1 and older no longer receive regular security releases from the PHP project. Some operating-system and long-term-support vendors may supply backported patches. If you are on an older branch, confirm the fix with your vendor and plan an upgrade to a supported PHP version.

These weaknesses concern PHP installations serving web requests across common modes, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team highlights mod_php as especially exposed, with a demonstrated path that can be triggered before application code executes.

What developers should do today

1. Inventory your deployments. Identify the PHP version actually running in production, including all containers, staging systems, cron environments and older sites. Your terminal's php -v output may not be the same as the version serving web traffic.
2. Install a fixed runtime. Update through your OS or hosting vendor's security packages, or deploy a rebuilt supported PHP container image. Managed-hosting customers should confirm the runtime update with their provider.
3. Restart the affected workers. Ensure FPM, Apache or other PHP workers reload the new binaries and configuration. Verify the active PHP version using a secured operational check.
4. Test the application. Run smoke tests for sign-in, checkout, forms, file uploads, queue jobs and important integrations. Do not roll back to a vulnerable runtime simply because a dependency needs attention.
5. Review exposure and logs. Check HTTP, WAF, server and error logs for unusual spikes, multipart requests and suspicious execution or outbound traffic. These observations alone are not proof of compromise.
6. Maintain recovery options. Make sure backups are usable and privileged credentials are protected. If indicators suggest compromise, follow an incident-response process, investigate and rotate affected secrets as appropriate.

What if you cannot patch immediately?

The PHP team lists temporary ways to reduce exposure, such as limiting oversized or complex multipart requests and disabling session.upload_progress.enabled for one confirmed attack path. For the out-of-memory issue, it also describes a carefully controlled memory_limit=-1 configuration workaround — but warns that this is not a complete fix and introduces resource-management considerations.

These measures depend on the vulnerability, PHP version and server configuration, and some require worker restarts. Read the maintainers' exact instructions before changing production settings. A web application firewall can help reduce suspicious traffic, but it cannot substitute for a patched runtime.

Does this mean PHP is unsafe?

No. A critical vulnerability is a serious defect, but it does not mean every application written in the language is inherently insecure. Every major software ecosystem requires security updates. The practical lesson is to keep runtimes supported, track upstream advisories, and treat infrastructure patching as part of software engineering.

For businesses, the immediate question is simple: Do we know which PHP version powers our website, and who is responsible for updating it? If the answer is unclear, that ownership gap is worth fixing.