Security response · October 2026
PHP CVE-2026-109618 and CVE-2026-109619 update checklist
An agency can update a site and still lack evidence that its PHP runtime was patched. Use the host request, version table, and serving-worker checklist below to close that gap.
Incident guidance can change. Use the linked vendor notices for current scope and instructions.
Quick answer
For CVE-2026-109618 and CVE-2026-109619, verify the PHP package serving web requests and replace the affected workers. Match its release or vendor backport to the fixed-version table below. A plugin update or a version check on a developer laptop does not establish the state of production.
Which PHP versions contain the fixes
The upstream fixes are in the following releases. For distribution packages with backported fixes, use the vendor's advisory and full package build rather than compare only the upstream version string. PHP security announcement.
| PHP release line | Upstream release containing both fixes |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
The official OOM advisory and stale-state advisory list affected and patched versions. These are fixes for the named issues, not a promise that the releases contain no other vulnerabilities.
What are the two vulnerabilities
CVE-2026-109618 concerns out-of-memory handling that can leave internal request data partially initialized and later consume it incorrectly. The advisory documents remote code execution and distinguishes demonstrated mod_php behavior from other server interfaces. PHP OOM advisory.
CVE-2026-109619 concerns internal state retained across requests after its backing memory is freed. A later request in the same worker can encounter that stale state under particular conditions. PHP stale-state advisory.
Both received CVSS v4.0 scores of 9.2. The PHP Foundation explains that early circulating claims used an incorrect score of 10.0. Use the official score and avoid treating a demonstration on one configuration as proof of identical exploitability on every server. PHP Foundation account.
Does PHP-FPM or managed hosting remove the need to update
PHP's announcement includes PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed in its at-risk scope. It describes mod_php as the highest risk. A managed host may install the fix for you, but you still need confirmation for your service. PHP announcement.
Ask which interface and runtime handles production traffic. PHP distinguishes the command-line interface from web server interfaces through its SAPI identifier; a result from one interface is not an inventory of all the others. PHP SAPI documentation.
Prefer authenticated hosting diagnostics or a provider report. Do not leave a public diagnostic page exposing server configuration just to demonstrate a version.
What should an agency ask its host
Send a concrete request for each production site and any preview that accepts public traffic:
Please confirm the status of CVE-2026-109618 and CVE-2026-109619 for [service/domain]. What PHP release, SAPI, and full package build currently serve web requests? If the fix is backported, please link the vendor advisory covering this package. When did the patch reach this service, and when were the affected workers restarted or replaced? Are any pools, containers, regions, or rollback images still using the previous build? Please identify any action we must take.
Track the reply against a named service. A broad statement that “our fleet is protected” is less useful than a package and deployment record that covers your site's actual runtime.
How do you verify the update reached production
Use this closure checklist:
- Identify all serving paths. Include the main site, APIs, admin subdomains, uploads, preview sites, and worker pools that handle HTTP requests.
- Record the fix source. Keep the upstream release or distribution advisory, the installed package/build, and the change ticket.
- Replace the affected processes. Ask for evidence that production workers use the new package; an updated image in a registry is not evidence of a running deployment.
- Run ordinary functional checks. Test sign-in, form submission, uploads if used, and background work dependent on the release. Do not use an exploit as a production smoke test.
- Check recovery paths. Flag rollback artifacts that would restore the affected runtime.
- Keep incident review separate. A patch record establishes remediation of the software version. Investigating whether an attacker previously gained access requires additional evidence.
This is a verification workflow for app owners. Follow the runtime vendor's instructions for the actual package installation and service restart.
Three checks that can miss an affected PHP worker
| Check performed | What remains unresolved | Evidence to request |
|---|---|---|
| A CMS or plugin was updated | The PHP runtime underneath it | Serving PHP package and vendor advisory |
| A terminal reports a patched PHP version | The web server may use a different interface or installation | Version and SAPI of the serving worker pool |
| A patched container image was built | Running instances or rollback images may still use the previous build | Deployment identity, worker replacement, and recovery artifact review |
The command-line and web interfaces are distinct PHP execution contexts. Use the SAPI documentation when collecting that evidence.
What if the host cannot patch immediately
Escalate to the host with the exact service and advisory. PHP states that updating is the complete solution; its configuration measures only reduce specific attack paths. Avoid copying a single memory or upload setting and describing the site as fixed. Those settings have operational consequences and require the full vendor guidance. PHP mitigation guidance.
For PHP 8.1 and older, the announcement distinguishes distribution or LTS backports from normal upstream support. Obtain explicit vendor evidence or plan the supported-version upgrade; an exception patch is not a new support commitment.
Can a website scan prove PHP is patched
An HTTP header or a successful request cannot reliably identify every underlying package, pool, or vendor backport. The strongest evidence comes from the host and the deployed processes. Use an external scan afterward to check other publicly visible issues, with the scope of a live app scan kept clear.
Questions app owners ask
Does updating WordPress resolve these PHP CVEs
A WordPress update alone is insufficient evidence. Confirm the PHP runtime used by the site's serving processes against the host's package advisory, then record when the patched workers replaced the old ones. Keep the CMS and runtime updates as separate entries in the change record.
Is an older version string always proof that the fix is missing
A distribution can backport the fix. Ask for the complete package build and its vendor advisory before classifying it. Conversely, a familiar upstream version printed by a different PHP installation does not establish what the web service is running.
Cite this guide
Vibe App Scanner. “PHP CVE-2026-109618 and CVE-2026-109619 update checklist.” Technical sources reviewed 22 October 2026. This is a synthesis of linked PHP advisories and an operational verification checklist; it contains no VAS measurement of exposed PHP sites.