Application security
Critical PHP flaws: from memory corruption to a verified fix
An HTTP request should not compromise the process serving your business application. CVE-2026-109618 and CVE-2026-109619 can cross that boundary under specific memory-management and request-lifecycle conditions. Understanding the two mechanisms helps teams prioritise remediation and verify that the running application actually received the 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
| Branch | Affected versions within branch | First patched version |
|---|---|---|
| PHP 8.2 | 8.2.0–8.2.34 | 8.2.35 |
| PHP 8.3 | 8.3.0–8.3.35 | 8.3.36 |
| PHP 8.4 | 8.4.0–8.4.26 | 8.4.27 |
| PHP 8.5 | 8.5.0–8.5.11 | 8.5.12 |
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.
- 01HTTP input
The process starts handling the request.
- 02Allocation in progress
Internal structures are still incomplete.
- 03OOM interruption
Execution exits before initialisation completes.
- 04Unsafe cleanup
Invalid state can lead to memory corruption.
Conceptual diagram: these steps explain the failure mechanism, not a universal exploit.
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.
- 01Request A
An operation publishes internal state.
- 02Memory freed
An interruption leaves a global reference uncleared.
- 03Same worker
The process persists and accepts another request.
- 04Request B
An early consumer uses the stale reference.
Conceptual diagram: these steps explain the failure mechanism, not a universal exploit.
The same flaws, different exposure paths
| Environment | What matters in the assessment |
|---|---|
| Apache + mod_php | Highest priority: request startup can reach the flaw before application code runs. Remote code execution has been demonstrated. |
| PHP-FPM | Not immune. Confirmed paths depend on application behaviour; worker reuse and the timing of initialisation matter. |
| Containers and other SAPIs | A container does not patch the interpreter. Check the image, embedded version, extensions and execution model; a server name is not evidence of immunity. |
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.
- 01Contain exposure
Restricted access, limits and perimeter observation.
- 02Patch the runtime
Fixed packages and replacement of every worker.
- 03Validate operation
Running version, tests and deployment evidence.
Conceptual diagram: these steps explain the failure mechanism, not a universal exploit.
A verifiable remediation workflow
- Inventory PHP in web servers, FPM pools, queue workers, scheduled jobs and images. Running php -v in a terminal checks only that CLI binary.
- Confirm the fix in the vendor advisory and record the package, revision, repository source and container image digest where applicable.
- Test authentication, uploads, sessions, imports, integrations, extensions and background jobs in staging. Prepare a restorable backup and a rollback plan.
- 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.
- 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.
- 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.