CVE-2026-109618 and CVE-2026-109619: Patch PHP Now

Two flaws in PHP's handling of fatal errors can leave stale pointers behind for a later request, creating paths to unauthenticated remote code execution and memory disclosure. Update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 now; PHP 8.1 and older will not receive an upstream fix and must move to a supported branch.

Which PHP versions are affected?

The ranges above come from the PHP advisories and are repeated in NVD's CVE-2026-109619 record and Google Cloud's response guidance. Do not read “PHP 8.2 or newer” as sufficient on its own: an early 8.2, 8.3, 8.4 or 8.5 build is still vulnerable. The patch number matters.

What CVE-2026-109618 and CVE-2026-109619 do

PHP normally creates request-scoped data, uses it while one request is running, then clears it before that request's memory is released. These vulnerabilities break that assumption when fatal error handling jumps out of an operation at the wrong moment.

CVE-2026-109618 concerns out-of-memory handling that can interrupt PHP while internal request data is only partly initialised. Cleanup can then handle invalid data as though it were valid. CVE-2026-109619 covers global state that continues to point into memory after the request owning it has gone away. A later request handled by the same worker can read or branch on that stale state before it is reset.

That is a use-after-free pattern across requests. An attacker first creates the abnormal state, then needs a later request to land on a worker where the stale pointer survives. If the memory is reused in a controllable way, the result can move from a crash or memory disclosure to execution of attacker-chosen code.

The important operational point is that the vulnerable component is the PHP interpreter. A plain PHP application, WordPress, Drupal, Laravel or custom code can all sit above the affected runtime. The application does not need to contain the memory-safety bug itself.

How exploitation works

JFrog's technical analysis describes a confirmed application-independent route involving PHP's multipart upload-progress feature. That feature writes attacker-influenced upload state to a session file. Error handling during decoding can leave request bookkeeping reachable after its memory has been freed. A later upload handled by the same worker can reclaim that memory with attacker-controlled values and turn the stale state into control of program execution.

The details matter because they explain two apparent contradictions. The CVSS 4.0 vector includes high attack complexity and attack requirements, yet the bugs are still Critical: exploitation needs conditions and more than one request, but it does not require an account or a click. They also explain why restarting workers matters. A process that was running vulnerable code can retain bad state; replacing every worker ensures the fixed runtime starts cleanly.

Public proof-of-concept code deserves caution. JFrog found fake repositories circulating alongside the disclosure. Do not run an unreviewed “checker” on a production host. Inventory the installed package or container image instead.

What WordPress site owners should do

WordPress's dashboard shows the WordPress version, not necessarily the PHP patch release that serves the site. Check the runtime directly:

php -v
wp --info
php-fpm -v

On managed hosting, the control panel may name only a branch such as “PHP 8.3”. Ask the host to confirm the complete version, including the patch number, and whether all FPM or web-server workers were restarted after the update. If you deploy a container, rebuild it from an updated base image and redeploy it; restarting an old image only starts vulnerable code again.

1. Take a recoverable backup of the database and uploaded files.
2. Move to a fixed release on a supported branch. PHP 8.1 or older needs a branch upgrade, not another patch on the same branch.
3. Restart every PHP worker or redeploy every application instance.
4. Smoke-test the site: front page, login, editor, forms, checkout and scheduled jobs. PHP branch upgrades can expose plugin compatibility problems that a patch update does not.
5. Verify from the host with php -v, and verify the web-serving runtime separately if command-line PHP and FPM use different packages.

Scan.now's WordPress scanner now checks a PHP version when the server discloses one in its HTTP headers. A hidden version is not proof of safety, so the scanner will say it could not verify the runtime rather than giving an all-clear.

Temporary mitigations if you cannot patch immediately

The PHP advisories describe ways to interrupt known exploit paths: turn off session.upload_progress.enabled, turn off fatal_error_backtraces on PHP 8.5, avoid a finite PHP memory_limit, and recycle workers aggressively. JFrog notes that each measure is partial: the upload-progress setting does not close the OPcache or backtrace paths, and removing the memory limit also removes a resource-exhaustion safeguard.

If an emergency change is unavoidable, make it at the administrative PHP configuration level, not with application code that runs after request startup, then restart every worker. Treat the change as a short bridge to the upgrade, document it, and remove it after patching. A web application firewall rule may block known request shapes, but it cannot repair a memory-safety flaw in the runtime.

How urgent is this?

Both vulnerabilities have a CVSS 4.0 base score of 9.2. NVD's initial CVSS 3.1 assessment for CVE-2026-109619 is 9.8: network reachable, no privileges, no user interaction, and high impact to confidentiality, integrity and availability. The scoring systems express attack prerequisites differently, but neither result supports waiting for a normal maintenance cycle.

Unit 42 reported seeing proof-of-concept material and estimated more than 22.6 million exposed PHP instances as potentially vulnerable in its telemetry. That figure is exposure, not a count of confirmed compromises. At publication, public technical work showed exploitability; it did not establish that every exposed instance had been attacked.

How to verify the fix

Record the full output from the running environment, not a package manifest from a developer laptop:

php -r 'echo PHP_VERSION, PHP_EOL;'
php --ini
ps aux | grep '[p]hp-fpm'

Confirm that the reported version meets the fixed threshold for its branch and that the worker start time is later than the package or image update. Where a distribution backports security fixes without adopting the upstream version number, use that distribution's CVE tracker and package changelog as the authority. In that case an external version-only scanner can report a false positive, and the host's package evidence is what resolves it.

Frequently asked questions

Does updating WordPress fix CVE-2026-109618 or CVE-2026-109619?

No. Update WordPress as normal, but these two fixes are PHP releases installed by the host, operating-system package manager or container build.

Is PHP 8.2 safe?

Only PHP 8.2.35 or later. The same rule applies to the other supported branches: 8.3.36, 8.4.27 and 8.5.12 are the first fixed releases.

If X-Powered-By is hidden, am I safe?

No. Removing the header makes passive version detection harder; it changes no executable code. Check the runtime on the server or ask the hosting provider for the full patched version.

Should I use a public proof of concept to test my site?

No. Version and package verification answer the exposure question without attempting exploitation, and fake proof-of-concept repositories appeared during the disclosure.

Sources

• NVD: CVE-2026-109619
• Unit 42 threat brief
• Google Cloud response guidance
• JFrog technical analysis