Skip to content
Critical PHP Vulnerabilities Alert to webp

Critical PHP RCE Vulnerabilities: CVE-2026-109618 and CVE-2026-109619

Research updated 21 October 2026 · 11-minute read · Critical

Two critical vulnerabilities in the PHP language runtime can allow unauthenticated remote code execution (RCE): CVE-2026-109618 and CVE-2026-109619. The PHP project assigns each a CVSS v4.0 score of 9.2. Administrators of internet-facing PHP services should identify the runtime that actually serves requests and move to a vendor-verified patched build urgently.

These are flaws in PHP itself, rather than in WordPress, Laravel, or another individual application. A vulnerable runtime can expose many applications on the same host, although the practical attack path depends on the server API, request-processing configuration, PHP build, and application behavior.

Executive summary

  • CVE-2026-109618: an out-of-memory handling flaw can leave request state partially initialized and expose it to unsafe shutdown processing.
  • CVE-2026-109619: stale global state can retain references to memory from an earlier request and be consumed by a later request handled by the same worker.
  • Impact: PHP and its security advisories describe potential unauthenticated RCE. Successful code execution runs with the privileges of the PHP worker.
  • Exposure: the PHP project reports a demonstrated, application-independent exploit path against Apache mod_php for CVE-2026-109618. It assesses other server APIs separately; do not assume every deployment is equally exploitable.
  • Action: update to a fixed branch release or a vendor package with a documented backport, then restart or redeploy the serving workers.

Urgency: PHP says there are no complete configuration mitigations. Workarounds can reduce exposure while patching is arranged, but do not replace an update.

At a glance

CVECore issueWhat defenders should know
CVE-2026-109618Out-of-memory handling and invalid request stateMultipart parsing can contribute to memory exhaustion. The advisory confirms RCE against Apache mod_php; it also discusses distinct conditions for FPM and other APIs.
CVE-2026-109619Stale request-owned global stateA later request may use state left by an earlier request on a persistent worker. Confirmed paths depend on the API and request/configuration behavior.

Both advisories list the same fixed releases and critical severity. The score describes severity, not proof that every affected server can be exploited in the same way.

What is affected?

PHP is the server-side runtime that executes PHP application code. The web server or application server connects incoming HTTP requests to PHP through an interface such as Apache’s in-process mod_php, PHP-FPM, or another runtime integration. This integration affects when PHP parses a request, starts and shuts down a request, and reuses workers.

The advisory highlights mod_php because it demonstrates an unauthenticated request path for CVE-2026-109618 that can reach vulnerable shutdown handling before the application’s own code begins. That makes it especially important to inventory. It does not establish that all PHP-FPM, FrankenPHP, or LiteSpeed installations have the same exposure:

  • Apache mod_php: the OOM advisory confirms a demonstrated RCE path. PHP also identifies a demonstrated CVE-2026-109619 path in this configuration.
  • PHP-FPM: PHP’s advisories describe different conditions from mod_php. For CVE-2026-109618, a startup failure exits the FPM child, but other OOM paths after normal startup may remain relevant. For CVE-2026-109619, exposure depends on the request path, worker behavior, and in some cases early configuration diagnostics or session upload progress.
  • FrankenPHP and LiteSpeed/LSAPI: the PHP advisories discuss these integrations as likely or conditional candidates, with different evidence and conditions. Review the specific advisory and your vendor’s updates instead of extrapolating from the mod_php demonstration.
  • Containers and managed hosting: the runtime inside an image or provider platform may differ from the host’s CLI version. Rebuild or redeploy custom images; ask the host to confirm the serving runtime and patch status.

These descriptions summarize the PHP project’s advisories; they are not a guarantee of safety or exploitability for a particular site. See the detailed CVE-2026-109618 advisory and CVE-2026-109619 advisory for configuration-specific conditions.

CVE-2026-109618: Out-of-memory handling

PHP can encounter an out-of-memory (OOM) condition when allocating memory to process a request. The advisory explains that PHP’s OOM handling could interrupt execution while request memory was reachable but not fully initialized. In some paths, shutdown processing could then read or branch on invalid request state.

Multipart form-data parsing is relevant because the PHP advisory describes ways multipart input can create substantial internal memory use. For example, the decoded request representation may use more memory than the bytes sent over the network, and certain multipart structures can increase the work PHP performs. These conditions do not mean that every multipart request is dangerous; they explain why request size and parsing limits matter during triage.

For Apache mod_php, the advisory confirms an unauthenticated HTTP exploit path that triggers request shutdown after startup has failed, before application code runs. PHP reports the demonstrated impact as remote code execution as the web worker account. It also notes that PHP-FPM behaves differently when startup fails and that other FPM paths depend on conditions after normal startup.

The patch changes how PHP handles OOM so unsafe early exits do not leave shutdown handling to process invalid state. Consult the advisory for the precise technical analysis and limitations.

CVE-2026-109619: Stale global state

A persistent worker handles requests over time. Some PHP state is global to that worker, while the memory it refers to belongs to one request. PHP must reset references before releasing that request’s memory. If an interrupted operation or later diagnostic leaves a reference behind, the memory can be freed while the worker still retains a pointer to it.

If a subsequent request reaches code that uses the stale reference before normal request initialization resets it, PHP may access freed memory. The advisory describes confirmed producer and consumer paths, including fatal-error/backtrace behavior in PHP 8.5 and session upload-progress handling. Which path is reachable depends on the server integration, configuration, and request or application behavior.

This is a memory-safety issue in the runtime. It is not a claim that a particular framework or CMS has a separate vulnerable endpoint. The risk is that an attacker can reach a susceptible processing path and potentially turn the stale state into code execution under the worker’s account.

Severity and what is known about exploitation

Each CVE has a published CVSS v4.0 score of 9.2 (Critical). The CVE-2026-109618 advisory’s vector lists network access, no privileges, no user interaction, high attack complexity, and a required attack condition. The score should be read alongside the implementation details: an unauthenticated attacker may be able to reach a serious impact, but deployment conditions affect exploitability.

The PHP advisories document validated or demonstrated exploit paths in specified configurations. That is evidence of technical exploitability. It is not by itself evidence of exploitation in the wild. The sources cited here do not establish that attackers are actively exploiting these CVEs at scale. Continue monitoring PHP and your security vendors for new incident reporting.

Affected and fixed versions

BranchUpstream versions covered by the advisoryFixed upstream releaseRecommended action
PHP 8.5Before 8.5.128.5.12Upgrade to 8.5.12 or a later vendor-verified fix.
PHP 8.4Before 8.4.278.4.27Upgrade to 8.4.27 or a later vendor-verified fix.
PHP 8.3Before 8.3.368.3.36Upgrade to 8.3.36 or a later vendor-verified fix.
PHP 8.2Before 8.2.358.2.35Upgrade to 8.2.35 or a later vendor-verified fix.
PHP 8.1 and olderUpstream no longer provides regular security updatesNo regular upstream fix releaseUpgrade to a supported branch, or verify an explicit distribution/LTS backport.

PHP’s release note says these critical flaws affect versions from PHP 5.4 through 8.5.11. It also says some distributions and long-term support vendors received patches in advance; those providers may backport a security fix without changing the upstream version string. Use your operating system or hosting provider’s security notice and package changelog as evidence. Do not decide solely from a banner, php -v, or a version string exposed by a website.

PHP 8.2 is scheduled to reach end of life on 31 December 2026, so organizations using that branch should include a supported-version upgrade in their planning. PHP release and security information

How to assess your exposure safely

Identify the PHP runtime that receives web requests—not only the PHP CLI binary used by an administrator or deployment script. A host may have different versions or builds for CLI, PHP-FPM pools, Apache modules, LSAPI, and individual containers.

  1. Inventory endpoints and owners. List public sites, APIs, admin portals, and internal services that execute PHP. Include hosting accounts, virtual machines, Kubernetes workloads, serverless deployments, and third-party managed services.
  2. Identify each serving API. Check Apache modules and virtual-host configuration, FPM service and pool configuration, LiteSpeed/LSAPI, FrankenPHP, or the container entry point. Verify which service is bound to each site.
  3. Trace the deployed binary or image. Record package name, repository, build provenance, container image tag and digest, and the deployed revision. A mutable tag alone is weak evidence that a workload has been rebuilt.
  4. Check vendor patch records. Compare the package build and changelog with the operating-system, hosting, or runtime provider’s advisory. Account for documented backports on older supported distributions.
  5. Confirm configuration-specific paths. Review request parsing, multipart support, worker persistence, session upload progress, early per-directory/per-request INI overrides, and application routes that can encounter fatal errors. Use the PHP advisories for interpretation.
  6. Keep the assessment private. Do not publish a phpinfo() page or expose detailed runtime metadata to the internet to check a version. Use authenticated server inventory and provider consoles.

A public HTTP response may omit or falsify its PHP version. A version banner is not a reliable patch verification method.

Remediation and temporary risk reduction

Permanent remediation

  1. Prioritize internet-facing PHP services, especially Apache mod_php deployments and services processing user-controlled uploads.
  2. Apply the fixed release for the branch, or a security update explicitly confirmed by the operating-system or hosting vendor to contain the fix.
  3. Restart or redeploy the right workers. Restart Apache, PHP-FPM, LiteSpeed/LSAPI, or the corresponding runtime. Rebuild and redeploy custom images and ensure the orchestrator replaces old pods or instances.
  4. Verify the running deployment. Recheck package provenance and process configuration, confirm all replicas use the patched artifact, and review health and error metrics after rollout.
  5. Record the change. Capture the affected services, package/image versions, vendor advisory, restart time, validation evidence, and any exceptions that remain.

Temporary measures if patching is delayed

PHP’s advisory provides configuration mitigations for specific paths. These measures reduce exposure; PHP explicitly says only updating completely mitigates the vulnerabilities.

  • For CVE-2026-109618: the PHP advisory recommends administratively enforcing memory_limit=-1 to remove the predictable per-request limit implicated in the confirmed OOM path. This does not prevent an underlying allocation failure. Keep post_max_size conservative, keep upload limits below it, and enforce decoded request-size, multipart-part, header-count, input-variable, and nesting limits at the front end where possible. Consider blocking multipart requests for applications that do not need them. Avoid RLIMIT_AS and RLIMIT_DATA; PHP warns these can cause allocation failures that reach the vulnerable path.
  • For CVE-2026-109619: PHP recommends disabling session upload progress (session.upload_progress.enabled=0) in configuration applied before request parsing and restarting every worker. On PHP 8.5, disabling fatal_error_backtraces blocks the confirmed fatal-backtrace path. Review invalid or deprecated per-request settings that emit diagnostics before request initialization, and address attacker-reachable fatal errors or timeouts. These controls cover specific paths, not every possible variant.

Use the exact PHP advisory for conditions and caveats before changing production configuration. Test changes against application upload and session requirements, apply them consistently across pools and replicas, and treat them as short-term controls while the patch is deployed.

Detection and incident response

The advisories do not provide a universal log signature that proves exploitation. Generic errors or memory pressure alone cannot confirm these CVEs. Review multiple sources together and compare activity with the vulnerability window:

  • Web-server and proxy access/error logs for unusual multipart requests, malformed or unusually large request bodies, request bursts, and correlated 5xx responses.
  • PHP-FPM, Apache, LiteSpeed, and application logs for worker exits, restarts, OOM/fatal-error patterns, or unexpected request-startup failures.
  • Host and container telemetry for unexpected child processes, outbound connections, modified web files, new persistence mechanisms, or unexpected changes to image/runtime state.
  • Endpoint detections and audit records for suspicious execution by the PHP worker account, while remembering that generic detections are not CVE-specific proof.

If compromise is suspected: isolate the affected service where operationally feasible; preserve logs, container/image digests, process telemetry, and relevant snapshots before rebuilding; involve your incident-response team; rotate secrets accessible to the PHP worker; inspect for persistence and unauthorized changes; and redeploy from trusted, patched artifacts. Keep evidence and timestamps for later investigation. A clean patch status does not establish that no prior compromise occurred.

Frequently asked questions

Does every PHP website need urgent attention?

Every operator should identify their PHP runtime and patch status promptly. Practical exposure differs by server API, configuration, and request path; do not assume all deployments are equally exploitable.

Is PHP-FPM automatically safe?

No. The advisories describe differences between FPM and Apache mod_php, including startup behavior and conditions involving later requests. Review the specific advisory and your deployment rather than treating FPM as immune.

Does upgrading the CLI version fix the web runtime?

Not necessarily. CLI PHP may be a separate package or binary. Confirm the runtime used by each web server, FPM pool, LSAPI service, or container, and restart or redeploy it after patching.

Can a vendor backport the fix without changing the upstream version number?

Yes. PHP says some distributions and LTS providers supply backported fixes. Confirm the exact package build and vendor security notice instead of relying only on the upstream version string.

Are configuration workarounds sufficient?

No. PHP describes them as partial measures for specific paths. Updating to a fixed release or verified vendor package is the complete remediation.

What if my hosting provider controls PHP upgrades?

Ask the provider to identify the serving PHP branch and API, confirm whether the relevant security patches are deployed (including any backport), and state when all workers or containers were restarted. If the provider cannot confirm the status, consider moving affected services to a managed runtime with a verifiable patch process.

Conclusion: prioritized checklist

  • Inventory every internet-facing PHP runtime and identify its serving API.
  • Update to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor package with documented fixes.
  • Restart workers or redeploy images, then verify every instance is using the patched artifact.
  • Use PHP’s configuration workarounds only as temporary, path-specific risk reduction.
  • Review telemetry for suspicious activity and preserve evidence if compromise is suspected.

For organizations that need support validating PHP deployments or coordinating remediation, CL-Infosec can help assess runtime exposure and patch coverage. Contact CL-Infosec through the organization’s established contact channels.

Sources and further reading