Critical PHP flaws: from memory corruption to a verified fix

What these vulnerabilities change

The flaws affect PHP itself, beneath frameworks such as Laravel, Symfony and WordPress. An application can have current dependencies while still running a vulnerable interpreter. The potential impact is remote code execution with the PHP process privileges; access to files, secrets and dependent services is limited by the permissions and isolation of that environment.

Fixes were released on October 21, 2026. PHP assigns both CVEs a CVSS 4.0 score of 9.2; NVD records a CVSS 3.1 score of 9.8 for CVE-2026-109618. These are assessments using different scoring versions and vectors. Public proofs of concept increase urgency, but do not establish compromise or universal exploitability.

Official patched versions

This table covers supported upstream branches. Distribution backports may carry a different package version: verify the vendor advisory and package revision. PHP 8.1 and older are outside regular upstream support; LTS packages and emergency source backports require separate assessment.

CVE-2026-109618 · interrupted initialisation, invalid memory

Out-of-memory (OOM) handling can interrupt an operation while internal request structures are only partly initialised. Request shutdown may later treat that incomplete state as valid. The issue is unsafe cleanup following the interruption, rather than simply “using too much RAM”.

With mod_php, remote code execution has been demonstrated before application code runs. PHP-FPM may terminate a child after a startup failure, but application-execution paths also need assessment. A login page and checks implemented solely in a framework therefore do not provide a sufficient boundary.

CVE-2026-109619 · freed memory, surviving reference

The second flaw crosses a request boundary. A persistent worker retains a global reference to memory owned by an earlier request. If the state is not properly reset before that memory is freed, a later operation may use it as if it were valid: a use-after-free.

The chain needs a producer of stale state and an early consumer that reaches it before normal initialisation, in another request handled by the same worker. Fatal errors can interrupt cleanup; session and upload operations or early diagnostics can contribute to a path. A new HTTP request does not necessarily mean a new process or fresh global memory.

The same flaws, different exposure paths

Prioritising actual exposure

Start with internet-facing services and mod_php environments. Map APIs, administration tools, uploads, importers and third-party products that embed PHP as well. In FPM, assess the pools and application flow; changing only the HTTP frontend does not remove an interpreter flaw.

A backported fix may retain an older upstream version number. Base the decision on the vendor advisory and installed package revision, rather than HTTP banners or a textual version comparison. A generic “PHP 8.2+” label is insufficient: each branch has its own first patched release.

Layered defence, with the runtime fix at its centre

The decisive control is the complete runtime patch. While preparing the change, restrict exposed paths and review proxy and server limits. A WAF may reduce recognised traffic; it cannot prove that every memory-corruption path is blocked.

Disabling session.upload_progress.enabled when unused, or fatal_error_backtraces in applicable PHP 8.5 cases, addresses particular paths and requires administrative configuration and worker restarts. Neither replaces patching. Do not apply blanket memory_limit changes without assessing availability and resource boundaries.

A verifiable remediation workflow

1. Inventory PHP in web servers, FPM pools, queue workers, scheduled jobs and images. Running php -v in a terminal checks only that CLI binary.
2. Confirm the fix in the vendor advisory and record the package, revision, repository source and container image digest where applicable.
3. Test authentication, uploads, sessions, imports, integrations, extensions and background jobs in staging. Prepare a restorable backup and a rollback plan.
4. Update the package or rebuild the image and replace every affected process. Files updated on disk do not guarantee that old workers have stopped running.
5. Validate the runtime serving real traffic, business workflows and logs after the change. Use restricted diagnostics; do not publish phpinfo() as proof of the version.
6. Retain deployment and validation evidence. A rollback to a vulnerable version requires containment and a new remediation plan.

What to observe after the update

Correlate fatal errors, OOM events, worker crashes, startup warnings and unusual upload behaviour with proxy and application logs. These signals guide investigation but do not individually demonstrate exploitation. Missing log messages are not proof of safety either: a failure can occur before an error is written.

If compromise is suspected, patching does not complete incident response. Preserve evidence, contain the asset and assess credentials, file changes and dependent access. Remediation must be accompanied by an investigation into what happened before the fix.