PHP Critical RCE Update: Patch 8.5.12, 8.4.27, 8.3.36, or 8.2.35 Now

PHP has released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution. The patched upstream releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The PHP security advisory published on 21 October says web-serving PHP installations are in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

That description makes this a runtime patch, not a Composer maintenance task. A site can have fully current WordPress core, plugins, and application dependencies while its actual PHP process is still vulnerable. The work is to find every runtime that accepts requests, install the correct fixed package or vendor backport, replace or restart the old workers, and leave enough evidence that the client can see the patch is real.

This guide was checked against PHP's 21 October 2026 advisory and fixed-release notices. Check the package, image, or hosting vendor's current security notice again before making the change. It does not reproduce the vulnerability mechanics. The published advisories are clear that the safe resolution is an update, and an internet-facing production environment is a poor place to learn how an RCE behaves.

The Short Version

If a server is serving PHP web requests, treat it as a priority patching task. The PHP project identifies CVE-2026-109618 and CVE-2026-109619 as critical and strongly encourages all PHP users to update immediately.

The upstream fixed versions are:

Release branch	Fixed upstream version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

The version table is the beginning, not the whole change. On an operating system maintained by a distribution, the correct fix may be a vendor package that backports the security patch while retaining the distribution's own version string. On a managed host, the platform may deploy a patched runtime without giving customers the exact upstream tarball version. Verify with the platform or vendor's advisory instead of rejecting a patched package only because its visible version does not match the PHP download page.

The Response Sequence

1. Inventory every web-serving PHP runtime, image, host, managed service, and worker pool.
2. Prioritize public paths and installations using Apache mod_php, which PHP calls the highest-risk configuration in this advisory.
3. Obtain the patched package, image, or managed-runtime confirmation from the relevant provider.
4. Test the patch in the smallest safe environment that represents the application.
5. Deploy, then restart or replace every long-running PHP worker.
6. Verify the running process and application behavior, not only the repository or package manifest.
7. Preserve a brief change record and review relevant logs through the patch window.

Do Not Mistake a Mitigation for a Fix

The PHP advisory describes temporary measures for constrained cases. It also says those measures do not completely fix the vulnerabilities. Do not make a php.ini change, mark the ticket resolved, and postpone the runtime patch indefinitely.

Configuration can reduce exposure while a vendor package is being built or a maintenance window is being arranged. A patched runtime removes the vulnerable code. Those are different states and should be documented as such.

What PHP Published

The two reports are GHSA-w8hw-w9fx-j79w, tracked as CVE-2026-109618, and GHSA-6wmf-4rv5-p3rp, tracked as CVE-2026-109619. Both advisories list releases below 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as affected within their respective supported branches.

CVE-2026-109618: RCE Via OOM Corruption

PHP's advisory describes an error-handling path around out-of-memory conditions that can leave request memory in an invalid state. The advisory explains that crafted request processing can reach that state and lead to remote code execution. The important operational point is that normal application input validation does not replace the runtime fix.

The PHP GitHub advisory contains the authoritative affected-version and mitigation details. Security teams that need to assess attempted exploitation should work from their own logs, supported detection tooling, and incident process rather than trying to replay the conditions on production.

CVE-2026-109619: RCE Via Stale Global State

The second issue involves worker state that can outlive the request-owned memory it refers to. According to the PHP security advisory, a later request can interact with state that was not correctly reset, creating a use-after-free condition that can reach RCE.

This detail matters for operational planning because recycling some workers may reduce the chance of a particular sequence without eliminating the vulnerable runtime. It is not an argument to lower the urgency for PHP-FPM pools, Apache workers, or application servers that reuse processes. Patch them and restart them.

Define the Estate Before Changing It

Most PHP estates are wider than the client remembers. The public marketing site might use PHP-FPM behind Nginx; an older portal might use Apache; a scheduled job could run a separate CLI binary; and a container platform might have its own base images. Inventory is how you avoid patching the obvious site and leaving the forgotten tenant exposed.

Find the Version the Web Process Uses

Start on a host with the command-line binary, but do not stop there:

php -v
php --ini
command -v php

Those commands identify the shell's PHP binary. They may be different from the binary used by PHP-FPM or Apache. Record the service unit, executable path, package owner, configuration directory, SAPI, application owner, and whether the system accepts public requests.

For PHP-FPM, inspect the running process and service configuration through the operating system's normal tooling. For Apache, identify whether PHP is a loaded module or whether Apache forwards requests to FPM. For containers, inspect the image digest and the PHP version inside the running image, not only the image tag in source control.

ps -ef | rg '[p]hp-fpm|[a]pache2|[h]ttpd'
systemctl status php-fpm

Use the service name that exists on the target host. A versioned FPM service is common, and guessing a unit name during a live patch is a good way to restart the wrong thing.

Do Not Forget Indirect PHP Runtimes

Ask the same questions of:

• WordPress sites on managed hosting;
• customer portals maintained by another vendor;
• queue workers and cron jobs that share a base image;
• CMS appliances, control panels, and bundled stacks;
• preview, staging, and white-label environments that are still reachable;
• old servers left online for redirects, import tools, or file uploads.

A control panel's selected PHP version does not prove the host package is patched. A Dockerfile that says FROM php:8.4-fpm does not prove a running image was rebuilt after the fixed tag was available. Treat each as a lead in the inventory, then capture evidence from the actual runtime.

Prioritize Public Request Paths

PHP says all installations that serve web requests should be considered at risk. It specifically calls the risk highest for Apache mod_php, where it has a demonstrated exploit that can run before application code executes. That means framework middleware, a WordPress security plugin, or a WAF rule should not be described as a full barrier for this issue. Those layers still belong in a broader website security program, but they do not remove the need for this runtime update.

Start With Exposure, Not Panic

The order of work should reflect reachable attack surface and business importance. A sensible first pass is public upload and form endpoints, authenticated customer portals, administrator-facing systems that have public entry points, and sites with Apache mod_php. Internal systems still need a patch plan, but a public service that accepts arbitrary requests should not wait for an inventory spreadsheet to reach perfection.

Keep the claim precise. A public PHP process running an affected release is a patching priority. That does not establish that it has been compromised. Preserve a time-bounded copy of relevant access, error, and host logs before routine rotation deletes them, then let the evidence and incident process determine whether deeper investigation is required.

Use a Small Change Record

For each runtime, capture a short row:

Field	Example evidence
Service	Customer portal, WordPress site, API worker
Exposure	Public, VPN-only, internal
Runtime	FPM, Apache module, container, managed platform
Before state	Package or image digest and observed PHP version
Patch source	OS vendor advisory, image release, or managed-host statement
Owner	Person responsible for application behavior
After state	Running version, restart time, health-check result

This is not bureaucracy for its own sake. It separates systems that are patched from systems someone merely intends to patch, which is valuable when a client asks for an answer the next morning.

Choose the Right Patch Path

An upstream PHP source release is not necessarily how the application was installed. Use the update mechanism that actually owns the runtime.

Distribution Packages and LTS Backports

For a distribution-provided PHP package, check the distribution's own security advisory and package changelog. Maintainers may backport the fix without replacing the entire upstream version identifier. In that situation, the vendor's claim that its package includes CVE-2026-109618 and CVE-2026-109619 matters more than a superficial comparison with 8.4.27.

Update one representative node first where the topology allows it. Capture the installed package identity before and after the change. Then restart the web-serving workers so the process maps the patched binary and extensions.

# Use your distribution's normal package query and update process.
# Record package names and exact versions in the change record.
php -v
php -m

Do not paste generic repository commands into a production ticket without confirming the target distribution, enabled repositories, and package naming. The command that is correct for a Debian-based host can be wrong for an RPM-based host or a commercial image.

Containers and Immutable Deployments

For container workloads, pin a patched base-image digest after the official image or a supported internal base image has been rebuilt. Build a new application image, run the checks that matter, deploy it, and verify the live workload's digest.

# Illustrative policy check. Set the expected version for the chosen branch.
RUN php -r 'echo PHP_VERSION, PHP_EOL;'

The build log is useful evidence, but it is not the final proof. A deployment can continue using an older replica, a stale cache, or a tag that was resolved before the image update. Compare the workload's running digest with the tested artifact and query the runtime after the rollout.

Managed Hosting and Control Panels

If a host manages the PHP binary, open a support case or use its security notice to establish three facts: which runtime version or backport fixes the CVEs, when it is available for the customer's plan, and how an existing FPM or Apache worker is refreshed. Screenshotting a control-panel dropdown is not enough.

Where a host cannot confirm a patch promptly, consider the business impact of moving the application to a supported patched runtime. The decision should include application compatibility, DNS and certificate management, backups, and ownership. Do not turn an urgent security patch into an unplanned platform migration unless the risk decision explicitly calls for it.

Test the Application You Actually Run

A critical runtime patch is a poor time for a broad refactor. Keep the change narrow, but test the workflows that would make the client feel a failure first.

Exercise the Request Boundary

In a representative environment, make a normal request through the same web server, FPM pool, cache, and application path used in production. Test authentication, a write operation in a safe test area, a file-upload path if the site owns one, scheduled work, and a failure path with invalid input. Include integrations such as payment webhooks or SSO only when a safe staging equivalent exists.

For a WordPress site, the least surprising checks are usually front-end rendering, the administrator login, media upload in a disposable environment, a form submission, permalink handling, and the cron or queue mechanism that the site actually uses. Do not test a critical production site by generating abnormal memory pressure or reproducing a security advisory.

Check Extensions and Configuration

PHP point releases can surface an extension issue that a simple homepage request misses. Compare the enabled modules and the effective configuration with the before state:

php -m | sort
php --ini
php -i | rg 'Loaded Configuration|Scan this dir|memory_limit|session.upload_progress'

Avoid publishing phpinfo() to the internet as a quick verification technique. It leaks useful configuration detail. Use a restricted shell session, deployment telemetry, a protected diagnostic endpoint, or a one-time internal command, then remove any temporary checks.

Deploy Without Leaving Old Workers Behind

Changing files on disk does not update a process that has already loaded the old PHP binary. This is especially easy to miss with long-lived FPM pools, Apache worker processes, containers, and an autoscaling group with mixed rollout state.

Drain Before You Restart

In a multi-node service, remove one node or replica from new traffic, wait for health checks to converge, then patch and restart it. Verify a realistic request, return it to service, and proceed through the remaining failure domains. This makes a small operational problem visible before it becomes a fleet-wide one.

In a single-server environment, prepare a short maintenance window or use the application's normal graceful-reload path. State the expected effect honestly. A tiny, planned interruption is preferable to a surprise restart during a customer transaction.

Replace, Then Confirm

After the restart or rolling replacement, confirm all of the following:

1. The package, image, or host runtime is the intended patched release or confirmed vendor backport.
2. The running web worker has started after the deployment event.
3. Readiness and a real application request succeed.
4. Error rates, latency, worker availability, and upstream failures remain near the pre-change baseline.
5. No old replicas or worker pools continue serving traffic.

The most useful proof connects the package or image identity to the process that accepted the production health check. A ticket that only says "updated PHP" leaves a future responder guessing.

Handle PHP 8.1 and Older Carefully

The PHP project says PHP 8.1 and older do not receive project updates for these CVEs. Its supported versions page lists 8.2 through 8.5 as supported branches, with PHP 8.2 receiving security support through 31 December 2026. If this patch becomes the point where your team plans a broader move to 8.5, our earlier PHP 8.5 feature guide can help frame the compatibility work separately from this emergency response.

Check for a Supported Backport

Some operating-system or long-term-support vendors may ship a supported backport for an older branch. Check that vendor's exact advisory, the installed package changelog, and its support statement. PHP also published minimal source backports for source builders of 7.4, 8.0, and 8.1, but those are not normal upstream security releases for the branches.

For a client application, a local source patch may be a temporary containment measure only when the team genuinely owns the build, testing, and deployment pipeline. It creates a maintenance obligation. A supported runtime upgrade is usually the more defensible endpoint.

Plan a Real Upgrade Path

Do not confuse "the website appears to work" with a support plan. An old PHP branch may be coupled to an old framework, custom extensions, or an obsolete operating system. Make the migration visible: capture the current constraints, test compatibility in a clone, budget for code and plugin work, and define the target supported branch.

The emergency patch is still urgent. The larger upgrade should be scheduled as a separate piece of work with its own acceptance criteria, rollback path, and owner.

Temporary Controls Are Only a Bridge

PHP documents short-term measures such as controls around request sizes and memory behavior for the first issue, and configuration changes around upload progress and worker restart for the second. The exact advice is version- and deployment-sensitive. Read the official PHP advisory before changing production configuration.

Use the Wording That Matches Reality

If a vendor package is delayed, write down the temporary controls as risk reduction, the expected expiry time, the affected services, and the person who owns the final update. Avoid saying "mitigated" when the official guidance says the update is the complete solution.

This wording matters with clients. It communicates urgency without manufacturing certainty. A client can approve a focused maintenance window when they understand the difference between a temporary barrier and a corrected runtime.

Keep Emergency Changes Reversible

Document the original configuration, the changed values, the reload or restart performed, and the validation result. Do not combine these emergency controls with unrelated PHP tuning, web-server migrations, extension upgrades, or framework changes. Every extra variable makes it harder to prove what fixed a regression.

Verify the Patch in Production

Verification is where a patch becomes defensible. The target is not simply a successful deployment job. It is evidence that the patched runtime now serves the application and the application still meets its basic contract.

Build a Small Evidence Set

Keep the following with the change record:

• before and after package versions or image digests;
• the official advisory or vendor backport notice used to establish the fix;
• deployment, restart, or replica-replacement timestamp;
• running PHP version or internal diagnostic result from the live environment;
• health-check and representative workflow result;
• a brief metrics window covering errors, latency, and worker health;
• any incident-review decision and log-preservation window.

The PHP project publishes the fixed source packages and checksums on its downloads page. That is useful to source builders. Most customer deployments will instead need the equivalent traceability from a distribution package, internal base image, or managed platform.

Review the Patch Window

Review only the evidence your retention policy permits and that actually helps the question at hand. Look for unexpected error spikes, worker crash loops, unusual authentication failures, newly failing forms, and incidents reported by the application owner. If the evidence points to suspicious activity, hand it to the security or incident team rather than turning a blog checklist into a forensic conclusion.

Avoid promising that a patch proves no prior compromise occurred. It proves the patched runtime is deployed. The incident question is separate and must be answered from evidence.

Put a PHP Maintenance Plan Behind the Emergency Fix

The urgent patch should lead to one useful operational improvement: nobody should have to rediscover every PHP runtime during the next critical release.

Keep a Runtime Inventory

Maintain a small, owned inventory of web-facing runtimes and their update path. For each service, identify its PHP branch, SAPI, package or base-image source, deploy mechanism, owner, health check, backup location, and end-of-support date. This can live in a service catalog, a repository file, or an infrastructure system. The important part is that it stays current enough to use under pressure.

Make Client Maintenance Visible

For a client-managed WordPress or PHP estate, a maintenance agreement should state who watches upstream security releases, who is allowed to approve an emergency change, how a staging check works, what is backed up, and how quickly a patched runtime can be deployed. This is practical care, not a sales trick. It turns a late-night version hunt into a known workflow.

If your team needs help mapping an estate, testing the PHP runtime upgrade, or verifying a WordPress site after the change, talk to Nandann about PHP and WordPress maintenance. We can help make the patch narrow, observable, and understandable for the people who own the site.

Sources And Version Checks

The following primary sources support the version and remediation guidance in this article. Verify your specific operating-system package, container image, or managed host against its own advisory before deployment.

• PHP security advisory, 21 October 2026
• CVE-2026-109618: GHSA-w8hw-w9fx-j79w
• CVE-2026-109619: GHSA-6wmf-4rv5-p3rp
• PHP 8.5.12 release
• PHP 8.4.27 release
• PHP 8.3.36 release
• PHP 8.2.35 release
• PHP downloads and checksums
• PHP supported versions

---