If you operate a WordPress site, a store, an internal portal, or any service that lets PHP handle web requests, the immediate task is to identify the PHP runtime that is actually serving each request. CVE-2026-109618 and CVE-2026-109619 are flaws in PHP itself. A CMS plugin update, a hosting dashboard that says “up to date,” or a WAF rule does not prove that the relevant web workers are fixed. This guide turns the public disclosures into an inventory, rollout, verification, and incident-review process that a site owner can document.
The PHP project’s advisory assigns both vulnerabilities a CVSS v4.0 score of 9.2 and urges all users serving web requests to update. Its affected deployment discussion includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest-priority confirmed scenario is mod_php: an unauthenticated request can trigger the flaw before application code begins. That priority does not make other PHP deployment modes safe to ignore.
Establish the facts before assigning work
The two issues affect different parts of runtime state. CVE-2026-109618 involves out-of-memory handling while internal request data is only partially initialized; cleanup may then treat invalid state as valid. CVE-2026-109619 involves request-owned global state surviving after its backing memory has been freed, so a later request in the same worker may touch stale memory. Researchers demonstrated remote code execution under particular conditions. That is a serious, specific result; it is not proof that every PHP installation is exploitable with one identical request.
The upstream fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If your deployment follows an upstream branch directly, compare its build with the fixed release for that branch. If your Linux distribution or long-term-support provider backports security fixes, the upstream version string alone may be misleading: verify the vendor advisory, package revision, and build provenance. PHP 8.1 and older do not receive normal upstream releases. The project also published minimal source backports for some older branches for users building from source or without an LTS provider; that should not be mistaken for an automatically maintained old installation.
The key question is whether the runtime serving a particular site contains the fix. A host can have multiple PHP installations. Its command-line interpreter, FPM pools, container image, and individual virtual hosts may differ. Checking a single control-panel number is therefore a starting point, not a closeout record.
The early “CVSS 10.0” rumor should also be separated from the advisory. The PHP Foundation’s postmortem says leaked identifiers circulated with an incorrect score and release time; the actual score is 9.2. That correction does not lower the urgency of updating. It shows why operators should base an emergency plan on maintainer and vendor notices instead of reposted screenshots or claims that the whole internet has gone offline.
Why a CMS update or a WAF rule is insufficient
Applications such as WordPress, Drupal, and Magento run on top of PHP. If a vulnerable state can be reached before an application’s code executes, an application plugin cannot filter that request. Keeping plugins and themes current still matters for their own risks, but it is a separate control from patching the interpreter. Even a very small application can inherit a vulnerable runtime; whether a particular exploit path works depends on the environment and trigger conditions.
A WAF can reduce exposure while you deploy fixes. It is not a substitute for the fix. Cloudflare’s technical report describes protection it deployed, attack traffic it observed, and attempts to vary payloads around rules. A request-only rule cannot be assumed to cover every variant. You also have to check whether every domain, API, upload endpoint, preview host, and directly reachable origin receives the same protection. The PHP project’s guidance explicitly treats temporary mitigations as partial risk reduction: updating remains the complete remedy.
This distinction prevents two false closeouts. A primary domain may be proxied while a preview hostname reaches the same FPM pool directly. Conversely, a new package or image may be present on disk while old workers continue handling requests. An operator needs evidence at both the entry point and the process doing the work.
Build a usable asset inventory first
Appoint one incident or change owner and list every route that can hand an outside request to PHP: public sites, administration panels, APIs, upload services, callbacks, staging hosts, and partner-only endpoints. Include who owns each business service, where it runs, its PHP SAPI, the package or image source, whether the origin can be reached outside a CDN, and who can approve a rollback. Production exposure is not limited to the home page.
Running php -v on a host or in a container is useful, but it reports that shell’s CLI interpreter. It does not automatically report the PHP build used by web traffic. For FPM, inspect the actual binary, pool configuration, and running workers. For Apache mod_php, verify the loaded module and service processes. On container platforms, compare the image tag and digest with the digest of the running pods or tasks after rollout. For managed hosting, ask the provider for the fixed build, corresponding security advisory, and effective deployment time. Do not leave a public phpinfo() page exposed merely to check a version; if a temporary diagnostic endpoint is required, restrict access and remove it afterward.
This compact record can be copied into a change ticket. Fill unknown fields with “not yet verified” rather than a guess:
Asset and domain:
Business owner:
Public entry and direct-origin paths:
Web server and PHP SAPI:
Actual web-request PHP build:
Package or image provider and digest:
Evidence that both CVEs are fixed:
Change window and rollback owner:
Post-deployment worker verification:
Log and alert review:
Asset and domain:
Business owner:
Public entry and direct-origin paths:
Web server and PHP SAPI:
Actual web-request PHP build:
Package or image provider and digest:
Evidence that both CVEs are fixed:
Change window and rollback owner:
Post-deployment worker verification:
Log and alert review:
Prioritize public exposure and confirmed high-risk configurations, such as an unpatched mod_php deployment, then cover other public PHP services and internal systems that an attacker could reach after gaining a foothold. A hosting provider’s silence is an unverified state, not evidence of a fix. Keep an owner and next action on every row.
Roll out the patch and prove it reached web workers
The upstream versions are reference points; your actual patch must come through the correct distribution channel. For official source or container builds, verify the release and image digest. For Debian, Ubuntu, RHEL, or another distribution, read the corresponding security notice and the package revision that backports both fixes. For a control panel or managed host, require the provider’s release information and scope. A latest tag or a green “update complete” badge is not a build record.
Use a five-stage change process:
- Capture the current state. Record the running image digest or package revision, FPM pool configuration, extension list, routing, and WAF coverage. Back up application data and databases and verify the restore procedure. If logs already suggest suspicious activity, preserve the evidence before routine cleanup.
- Test business behavior in staging. Exercise logins, uploads, checkouts, administration, queues, scheduled jobs, and custom extensions. The goal is ordinary regression testing, not running exploit code. A small upstream update can still expose compatibility problems in extensions or deployment scripts.
- Deploy in batches and replace processes. Roll one group at a time, keep capacity, then restart or roll every relevant PHP web worker. Verify long-running queue workers and scheduled tasks if they share the old runtime. Updating files without replacing processes can leave old code in service.
- Verify through the request path. For each domain, follow its real load balancer, proxy, and web worker. Check the effective fixed build, then watch health checks, error rate, latency, session behavior, uploads, and critical transactions. A
php -vresult from the deployment machine does not sign off a web deployment. - Keep a safe rollback decision. Prefer fixing configuration or switching to another verified patched build if regression appears. A short rollback to a vulnerable build requires an explicit security decision, isolation of high-risk paths, a deadline, and an owner; it should not silently become the steady state.
A defensible completion record answers: which asset changed, what build is running now, and who verified it? Use a dated change record, running instance digest, vendor advisory reference, health-check results, and sampled business tests. A dashboard screenshot demonstrates an action in a panel, not necessarily the code processing live requests.
What to do when a patch cannot be deployed today
Old commercial systems, extensions, and managed-hosting schedules can block an immediate update. Track temporary exposure reduction separately from a true fix. The PHP advisory gives path-specific interim measures involving upload limits and settings tied to memory exhaustion or upload-progress behavior. It states that these measures do not provide complete protection. Do not copy a stranger’s php.ini values into production without testing: memory and upload settings can alter availability, user sessions, and normal file handling. Confirm that the intended setting takes effect before request parsing in your particular SAPI.
At the network layer, remove unnecessary public access, disable unused upload paths, and test whether the origin is reachable around the CDN. If you use a WAF, verify rule coverage for every ingress and monitor false positives. For an older PHP branch, get a package-specific backport statement from the distribution or LTS vendor, or schedule isolation, migration, or retirement. An application-level maintenance page is not isolation if the vulnerable PHP process still serves it.
Suspicious restarts, unusual errors, unexpected upload patterns, or unknown files warrant investigation, but none alone proves exploitation. The absence of visible errors also does not prove safety. Preserve web, WAF, system, PHP, and deployment logs; let the incident team decide whether forensics, credential rotation, and notifications are needed. Keep affected assets, fixed assets, temporary exceptions, expiry dates, and owners in one ledger until the exception list is empty.
Where AI helped—and where people remained essential
It is tempting to compress this incident into “AI found a twenty-year-old bug in a week.” The public record is more precise. According to the PHP Foundation, maintainers saw signs of the out-of-memory issue while addressing an external audit finding in 2024. At that point there was no concrete exploit path, and proposed repairs involved difficult compatibility, denial-of-service, and extension-ecosystem tradeoffs. Work stalled. In 2026, reports from Calif, OpenAI, and Wiz clarified impact and exploitability, and the maintainers made a fix their top priority. The result involved both years of human context and AI-assisted analysis and validation.
OpenAI’s disclosure account says Calif used GPT-5.6 Sol as part of its work and Wiz independently found and reported both vulnerabilities. The PHP Foundation describes the researchers’ reports, independent findings, and maintainer-led remediation. The reusable lesson for a security team is a complete loop: discover, independently validate, privately report, test the patch, coordinate disclosure, and verify deployment. Models can accelerate search, code tracing, and hypothesis testing; humans and accountable institutions must still decide what is reproducible, what is affected, and whether a repair is safe for a large ecosystem.
The disclosure process shows another constraint. The PHP Foundation reports that early circulating CVE identifiers carried a wrong score, demonstration material was accidentally published, and a distributor released fixed images before the coordinated time. Releasing clues too early shortens the defender’s time to install a patch. Hiding a finished patch forever does not help operators either. A mature response specifies who receives advance notice, what each participant may share, who packages backports, and when simple operator guidance becomes public.
What the Codex version checker can—and cannot—tell you
OpenAI published a PHP version-checking Codex skill to help operators identify potentially affected versions and consult upstream and provider guidance. It is not proof that entering a site’s URL can establish the absence of the vulnerability. An outside URL rarely reveals the origin’s actual PHP build, and vendor backports can invalidate a simple version comparison. Use such a tool as an inventory assistant, with evidence for where each result came from and a named person verifying the environment.
For a developer content platform such as Code0 or Apito, the same discipline applies when publishing an explanation: keep the maintainer notice, version mapping, change log, and verification result together. AI can organize vendor bulletins or draft a checklist. It cannot sign off on a production system on the site owner’s behalf.
A one-page closeout checklist
Put these seven entries into the change record. Mark each as “verified,” “pending,” or “not applicable”; do not replace the record with a single “done” flag.
| Control | Evidence to retain | Frequent gap |
|---|---|---|
| Asset scope | Public domains, origins, APIs, staging, and managed hosts | Only the home page is inventoried |
| Build and channel | Web-worker build plus package revision or image digest | Only CLI or panel version is checked |
| Patch mapping | Upstream fixed release or vendor advisory for both CVEs | A latest tag is treated as proof |
| Process replacement | All FPM, Apache, or container instances rotated | Old workers keep serving traffic |
| Business regression | Login, upload, session, transactions, and administration tested | Only an HTTP health check ran |
| Perimeter coverage | WAF, direct-origin, and exception-path records | WAF is treated as the patch |
| Incident review | Logs retained, anomalies triaged, owner sign-off | Disclosure-window anomalies ignored |
An organization with this evidence can reasonably say it identified and addressed its exposure. An “upgrade successful” screenshot alone still leaves the runtime and ingress questions open. In this kind of incident, patch deployment is the start of closeout; verification is the final mile.
Sources
- PHP project advisory and fixed releases
- PHP Foundation discovery, repair, and disclosure postmortem
- OpenAI coordinated response and version checker
- Cloudflare perimeter protection and its limits
FAQ
We use Nginx and PHP-FPM, not Apache. Do we still need to update?
Yes. The PHP advisory includes PHP-FPM among web-serving installations that need the fix. The highest-priority confirmed mod_php path does not exempt FPM. Verify the actual web runtime and the corresponding upstream or vendor fix.
The hosting panel displays PHP 8.5.12. Are all sites safe now?
That is not enough evidence. Hosts can run multiple PHP versions or FPM pools, and CLI may differ from the web runtime. Check each domain’s live worker, package build, and running container digest; confirm old workers have exited.
What if our site is on PHP 7.4 or 8.1?
Ask the distribution or LTS provider for a backport that addresses both CVEs. The PHP project has also provided minimal source backports for certain older branches for specialized users. If no trustworthy fix is available, plan isolation, migration, or retirement, and track interim controls as exceptions rather than fixes.
Does a Cloudflare WAF rule remove the need to patch PHP?
No. A WAF can reduce exposure for covered entrances and known attack paths, but it does not prove every variant, direct origin, or unproxied endpoint is protected. PHP’s complete remedy is to update the runtime.
Can the Codex checker prove that a URL is not vulnerable?
No. Its public purpose is to help identify potentially affected versions. An external URL cannot reliably show the origin runtime, vendor backport, or worker state. Treat its output as an inventory clue and verify it against environment evidence.
