Reporting snapshot: October 21, 2026. This article distinguishes confirmed technical findings, attributed reports of attacks, and Echo Effect's recommendations. Security advisories can change as investigators validate additional attack paths. The cover is an original AI-generated conceptual illustration, not a photograph of an attack.
The PHP security emergency circulating as PHP2Shell concerns two critical vulnerabilities in the PHP runtime, the software that executes many websites. PHP released fixes on October 21, 2026. An attacker may be able to execute code without logging in. The official severity is CVSS v4.0 9.2, not the 10.0 figure circulated before disclosure. PHP security announcement
For a business owner, the immediate question is whether the PHP actually serving your website has received both fixes. A functioning homepage, an updated plugin list, and a hosting company's general security badge do not answer that question.
Act now: Ask your hosting provider to confirm remediation for CVE-2026-109618 and CVE-2026-109619, including the installed package or image and replacement of affected running workers. If compromise is suspected, containment and evidence preservation belong alongside patching. A patch closes a vulnerability; it does not establish that an attacker never got in.
What happened, and what “hacked” actually means here
There are three different situations that should not be collapsed into one headline:
| Situation | What it establishes | What it does not establish |
|---|---|---|
| A vulnerable PHP runtime is installed | The system needs exposure assessment and remediation | That anyone has attacked it |
| Suspicious requests or exploit attempts reach the site | Someone may be testing or attacking the service | That code execution succeeded |
| Unauthorized execution, access, or changes are verified | An actual security incident requiring investigation | That PHP2Shell was necessarily the entry point |
Cloudflare says it observed attack traffic and changing payloads during the disclosure period. It also reports deploying protections for its free and paid WAF customers from 03:02 UTC on October 21. This is direct provider reporting about its own network; it is not a count of successfully compromised websites. Cloudflare's incident account
Our reporting does not establish a defensible worldwide victim count, a single responsible threat actor, or a universal indicator that identifies every successful exploit. We therefore do not claim that every PHP website has been breached or that a particular percentage of the internet has been compromised.
For the same reason, a service going offline during emergency maintenance is not evidence of a hack. An operator may deliberately restrict access while updating. Customers should ask for the service's own incident statement before drawing conclusions about stolen information.
The disclosure timeline
The PHP Foundation says signs of the out-of-memory problem emerged during work connected to a 2024 security audit. Calif and OpenAI reported the same underlying issue on August 11, 2026. Wiz contributed additional research later that month. After information circulated on October 20, PHP advanced the planned October 22 release by a day. PHP Foundation's disclosure retrospective
| Date | Milestone | Source |
|---|---|---|
| August 19 to 24 | Wiz reports discovery, laboratory RCE demonstrations, and submission to PHP | Wiz research timeline |
| October 20 | Public advance notice announces two critical fixes for the following day | PHP team's mailing-list notice |
| October 21 | Emergency versions become available before the announced 14:00 UTC target | ENISA joint statement |
There is a small timestamp discrepancy worth preserving: CERT-EU records the release at 13:30 UTC, while ENISA records 13:40 UTC. The advance notice scheduled 14:00 UTC, or 10:00 a.m. Eastern Daylight Time. These sources agree on the date and availability of the fixes; this article does not invent a single precise release minute. CERT-EU advisory, ENISA statement
Why a PHP flaw reaches so many different websites
Think of a website as several layers: its business features, a framework or content management system, the language runtime, and the operating environment. Fixing one layer does not automatically replace another.
WordPress explicitly says these vulnerabilities are in PHP, are not specific to WordPress, and do not require a WordPress release to fix. Its guidance directs owners to Tools → Site Health → Info → Server to inspect the PHP version and to coordinate with their web host. WordPress security notice
The inventory extends beyond a company's public marketing site. NCSC-NL highlights embedded PHP in appliances, network devices, and management interfaces, and maintains operational information and a software inventory. NCSC-NL PHP2Shell repository
Our recommendation is to inventory each hostname and deployment, including staging sites, abandoned campaign sites, customer portals, webmail, and administrative applications. Record who owns the runtime. “The agency handles the website” and “the host manages the server” are incomplete answers until someone accepts responsibility for installing and verifying the security update.
For a vendor-managed appliance, follow that vendor's remediation procedure. Replacing a bundled interpreter manually can break the product or leave other copies untouched. Obtain the product advisory and fixed build identifier instead.
How the two vulnerabilities work
These are memory-safety failures in PHP's own request lifecycle. They are different from a stolen administrator password or a malicious plugin installation. The following explanations describe the failure mechanisms without providing an exploit recipe.
CVE-2026-109618: an interrupted allocation leaves unsafe cleanup work
PHP can stop a request when it exhausts its memory allowance. The advisory describes an abrupt exit using longjmp(). If that exit happens while internal data is only partly initialized, cleanup may subsequently handle incomplete state as though it were valid. Memory corruption can follow.
Apache's mod_php is especially concerning because it performs shutdown after a failed startup. The demonstrated path can therefore occur before the application's own code runs. PHP-FPM handles startup failure differently by exiting the child, but that does not establish immunity to failures reached during application execution. PHP's OOM advisory
Here is the conceptual mistake: cleanup expects a completed object, while an error has interrupted the code responsible for completing it. Error handling becomes part of the attack surface. A login check in application code cannot protect an earlier failure in the runtime's startup sequence.
Why a small incoming request can create a large memory problem
Calif's investigation describes a mismatch between declared request size, decoded input, and the amount of memory PHP allocates to represent that input. Multipart metadata and nested field structures can require substantially more internal storage than the incoming bytes suggest. A request-size limit alone therefore does not necessarily bound the memory required to process a request. Calif's original research
The general engineering lesson is to budget processing work as well as payload bytes. The same number of incoming bytes can represent very different numbers of objects, headers, fields, or nested structures. A system that measures only the envelope can miss the cost of unpacking it.
CVE-2026-109619: one request leaves state that a later request misuses
Long-lived workers can handle many requests. PHP retains some global state inside those workers, including references to memory belonging to an individual request. If an interruption prevents a reset, the memory can be freed while a reference survives. A later request on the same worker may use that stale reference before ordinary initialization replaces it. This is a use-after-free.
The advisory describes a producer that leaves state behind and a consumer that later uses it. It confirms session-lifecycle RCE for mod_php and PHP-FPM, with the FPM path requiring a suitable application operation. PHP's stale-state advisory
View the full-size request lifecycle diagram.
An evidence caveat matters here. The OOM advisory says it has no complete FPM exploit demonstration for that specific analysis; the Foundation retrospective separately reports FPM RCE through application paths. The stale-state advisory validates an FPM session path. We preserve those scopes rather than claiming either that every FPM setup is trivially exploitable or that FPM is safe.
What successful exploitation could expose
Wiz reports both code execution and process-memory disclosure. Memory may contain credentials, tokens, keys, or information associated with other requests. Its researchers demonstrated exploitation against selected applications; those demonstrations are research results, not proof that the named applications' users were breached. Wiz's technical report
The practical consequence depends on what the compromised process can access. A web worker with tightly limited permissions presents a different recovery problem from one that can modify application code, read broadly privileged credentials, or reach unrelated internal services. Do not translate “remote code execution” into “automatic root access.” Investigators must establish the actual permissions, reachable resources, and subsequent activity.
Which versions contain the fixes?
These are the upstream fixed releases announced for the supported branches:
| PHP branch | First fixed upstream release for this emergency |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
PHP lists PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed within the affected web-serving landscape. PHP 8.1 and older are outside normal upstream support. Some vendors backport fixes; PHP also supplied minimal source backports for 7.4, 8.0, and 8.1. Official versions and remediation notice
View the full-size patch reference.
Why a version string can mislead you
Ubuntu's notice provides a concrete example: its fixed Ubuntu 24.04 package is 8.3.6-0ubuntu0.24.04.13, rather than a package labeled 8.3.36. Ubuntu 22.04 receives 8.1.2-1ubuntu2.28. The distribution revision matters. Compare the complete installed package against the advisory for that exact operating-system release. Canonical's package table
Do not apply these Ubuntu examples to another distribution. Likewise, a paid extended-support entitlement is useful only if the relevant repository is enabled and its fixed package is installed. An invoice for support is not patch evidence.
What to do if you might be impacted
The following is Echo Effect's recommended operating sequence. Assign a named owner and record completion evidence for each step. A small business can ask its host or administrator to carry it out; an infrastructure team can use the same sequence across its fleet.
1. Establish what is actually running
Build a compact inventory with: hostname, origin server, hosting account, PHP branch, full package or image identifier, web integration, responsible person, and current remediation status. Include every replica and every PHP pool serving a different site.
For WordPress, the Site Health screen is a useful starting point. For administrators, these local commands provide initial evidence:
php -v
php --ini
They describe the command-line PHP binary and its configuration. They do not prove which runtime your web server uses. Reconcile the output with the web-server configuration, FPM service, hosting panel, or running container. A server can contain more than one PHP installation.
Do not publish an unrestricted diagnostic page containing phpinfo() just to answer this question. Use an authenticated administrative surface or a controlled local check, and remove temporary diagnostics after use.
For each system, finish this sentence: “Requests for this hostname are handled by this runtime, and this vendor document confirms that its exact build fixes both CVEs.” If you cannot finish it, the system remains unverified.
2. Reduce exposure while the update is prepared
CERT-EU recommends immediate patching and, where that is not feasible, considering isolation of internet-facing applications until remediation is applied and verified. CERT-EU response guidance
Our recommendation is to make containment decisions at the traffic boundary with the host or incident responder. A maintenance plugin still runs within the application stack and should not be assumed to block requests before PHP processes them. A static maintenance response served outside the affected runtime, a private access restriction, or removal from the public load balancer can provide a clearer boundary when implemented correctly.
Confirm what remains reachable: the direct origin, alternate hostnames, old DNS entries, administration ports, and IPv6 listeners. Keep a trusted management route available so the team can complete the repair. Record the time and nature of restrictions; those facts help later investigation.
3. Install the vendor's complete update and replace running workers
Update every affected runtime through its supported package, hosting, appliance, or image process. Do not assume that replacing files on disk changes code already loaded into a running worker.
Canonical specifically says affected applications may need a restart and identifies restarting Apache for mod_php; it also notes that automatic security updates do not remove that restart requirement. Ubuntu update instructions
Our deployment checklist is to replace or restart the relevant workers, verify the running build afterward, and check normal customer journeys. For containers, update the source image or build definition and recreate the running workloads. Also update templates and rollback images so the next deployment or scaling event does not bring back the vulnerable runtime.
Test login, checkout if present, uploads, forms, and background work appropriate to the application. Keep the rollback plan on a patched build. If compatibility fails, maintain containment while correcting the incompatibility instead of silently restoring an exposed version.
4. Investigate exposure, especially when compromise is suspected
Keep two questions separate: “Is the runtime fixed now?” and “What happened before it was fixed?” A positive answer to the first cannot resolve the second.
Elastic's detection guidance focuses on behavior such as a web-server process spawning a shell or an unexpected child, retrieving additional tooling, or creating a web shell. These are investigative leads, not PHP2Shell-specific proof. Elastic's detection analysis
Our recommended review covers web and proxy logs, PHP errors, endpoint process history, file changes, outbound connections, administrative accounts, scheduled jobs, and relevant cloud audit events. Correlate time, host, worker, request, and subsequent behavior where the available telemetry allows it.
For example, a memory error by itself may reflect a legitimate resource problem. A memory-error burst followed by an unexplained child process and a new executable file is a stronger reason to escalate. Neither example substitutes for forensic analysis of the actual system.
Define the review period from the best available evidence, not merely from the moment a news story appeared. Preserve older records when feasible. The public disclosure date does not establish the earliest possible attack date.
5. Preserve evidence before destructive cleanup
WordPress's recovery guidance recommends documenting symptoms and times, contacting the host, and preserving a snapshot before cleaning. It also warns that replacing known files can leave attacker-added files behind. WordPress hacked-site recovery guidance
Our recommendation is to coordinate evidence collection with containment. Export relevant logs to a location the affected application cannot alter. Preserve deployment identifiers, suspicious files, account changes, and a chronological record of actions. Restrict access to these materials because they may contain customer information or secrets.
If active harm is occurring, do not postpone containment for a perfect forensic collection. When responders are available, let them determine whether volatile memory or other short-lived evidence should be captured before a restart. Avoid running random “PHP2Shell checkers” or exploit demonstrations against production as a substitute for package verification and professional investigation.
6. Recover from a trustworthy baseline and address credentials
If compromise is confirmed, our recommendation is to rebuild the affected service from trusted, patched components and restore reviewed data. Identify all persistence and access paths within the incident's scope. Merely deleting the first suspicious PHP file can leave a second route intact.
Inventory secrets the compromised worker could read or access: database credentials, application secrets, mail credentials, storage tokens, deployment credentials, and relevant signing material. Prioritize revocation based on actual exposure and privilege. Perform recovery administration from a trusted device and control plane.
Coordinate credential rotation with containment and service replacement. New secrets placed into an actively compromised environment may be exposed again. Invalidate affected sessions or tokens where appropriate, and verify that dependent services still function after rotation. Keep a record of what was revoked and what remains under investigation.
Finally, verify the recovered service before reopening it, then monitor for recurrence. State the limits of the investigation honestly. “No evidence found in the records available to us” is a narrower and more defensible statement than “nothing happened.”
Assign someone to coordinate communications with customers, staff, and relevant service providers. Keep confirmed facts, unresolved questions, service impact, and the next update time separate. Avoid promising that data was unaffected before the investigation supports that conclusion. For a material incident, involve the organization's incident-response, insurance, and legal contacts to determine the appropriate reporting and notification process.
View the full-size response workflow.
Temporary mitigations: useful limits, significant caveats
The following are emergency exposure reductions described by PHP and CERT-EU, not interchangeable fixes:
| Measure | Scope and limitation |
|---|---|
session.upload_progress.enabled=0 | Blocks confirmed session paths, not every stale-state variant. Apply before parsing and restart workers. |
PHP 8.5: fatal_error_backtraces=0 | Addresses the confirmed fatal-backtrace path, not all state-lifecycle failures. |
Administratively enforced memory_limit=-1 | Removes the PHP memory-limit trigger; underlying allocation failures remain possible. |
| Tighter request and processing limits | Reduce selected input paths; enforce decoded size and structural limits at the appropriate boundary. |
Removing PHP's memory limit can introduce availability risk. The official guidance pairs it with container or cgroup boundaries and warns against substituting RLIMIT_AS or RLIMIT_DATA. Treat these changes as administrator-led emergency work, with testing and a short path to the complete patch. CERT-EU's mitigation details
Do not copy an isolated setting from social media and mark the incident resolved. The owner must understand where the setting takes effect, whether another setting overrides it, and which attack path it actually addresses.
What a WAF can and cannot establish
Cloudflare describes protections combining request and response signals because request data alone may be insufficient. Its provider-specific report does not establish that another WAF, an application plugin, or a direct-to-origin request receives equivalent protection. Cloudflare's protection details
Our recommendation is to verify that applicable rules are active and that relevant traffic actually traverses them. Ask the provider about coverage and exceptions. Continue runtime remediation even when blocking appears effective. A blocked request is useful evidence about that request, not a certificate that the origin is clean.
Why it happened, and could it have been prevented?
There are two separate prevention questions: could the underlying defects have been addressed sooner, and could a particular organization's exposure or damage have been reduced? The answer to both is “potentially,” with different responsibilities and no honest guarantee.
What the maintainers themselves acknowledged
The PHP Foundation describes competing fixes with compatibility, performance, and extension-ecosystem tradeoffs. It says consensus-based decisions and limited specialist capacity allowed work to stall before demonstrated exploitability clarified the urgency. It acknowledges a structural failure and describes changes to decision-making and staffing. Its account also says a mistakenly published demonstration video disrupted coordinated disclosure. These are the Foundation's statements, not an inference that maintainers intentionally ignored a known public exploit. Foundation retrospective
Our take: test the failure paths, and give hard security decisions an owner
For runtime maintainers, we would prioritize fault-injection testing around allocations, fatal errors, startup, shutdown, and request reuse. Ordinary feature tests ask whether valid input produces the expected output. Security tests also need to ask what remains reachable after execution stops halfway through an operation.
The design goal should be explicit: partially constructed objects must not become valid cleanup targets, and references to request-owned memory must not survive into later requests. Changes should be reviewed across integrations and extensions, with regression tests for the actual lifecycle boundary.
Testing alone cannot resolve a stalled compatibility decision. A security process needs an accountable escalation owner, documented options, a decision deadline proportionate to the risk, and sufficient engineer time to validate the chosen approach. “No working exploit yet” should inform prioritization without becoming an indefinite reason to leave a credible memory-safety concern unresolved.
These measures might have reduced the delay or caught variants earlier. We cannot prove that any single change would have prevented this specific disclosure crisis.
Our take: businesses need a runtime maintenance plan, not just website maintenance
For organizations using PHP, the most achievable prevention is operational readiness. Define emergency update ownership before a critical advisory arrives. Keep an inventory that maps a public hostname to a runtime, deployment, vendor, and responsible person. Maintain a tested way to restrict traffic and a way to restore service using trusted components.
Make patch verification a deliverable. Ask for the actual package revision or image digest and evidence that the running service changed. A support ticket marked complete without those details is difficult to audit and easy to misunderstand.
Practice recovery against the real business workflow. A backup that has never been restored is an untested dependency. A restore that reintroduces the same unpatched image is not a successful security recovery. Include contacts, authentication, DNS, mail, and payment dependencies in the exercise so the team understands where credentials and operational control reside.
Our take: limit what a compromised web worker can reach
We recommend separate application identities, narrowly scoped database access, restricted outbound connectivity where practical, and separation between writable content and executable application code. Avoid giving a public web process deployment credentials or administrative access it does not need.
These controls reduce possible consequences; they do not repair PHP's memory handling. Evaluate them against normal application behavior so that emergency hardening does not break legitimate uploads, mail delivery, or integrations without a recovery plan.
For multi-site hosting, ask how sites are isolated. A company should know whether compromising one site could expose another site's files or credentials. That question remains useful after this particular vulnerability is patched.
Where AI fits, without the hype
Wiz attributes its research acceleration to AI-assisted analysis, debugging, and exploit development. OpenAI describes a broader effort involving maintainers, researchers, and providers, and emphasizes engineering support, isolation, and safer software foundations. These accounts support AI's role in the research and response; they do not establish that AI autonomously compromised the internet. Wiz research account, OpenAI's coordination account
Our view is that faster discovery increases the value of preparation. Organizations cannot safely assume that a complicated vulnerability will remain too difficult to exploit. At the same time, a model-generated report still needs reproduction, technical review, and a tested remediation. Automation should shorten the path from evidence to action, not replace that evidence.
What to ask your hosting provider today
Use the following request as a practical starting point. It asks for verifiable answers without assuming your provider has failed:
Please confirm the status of CVE-2026-109618 and CVE-2026-109619 for every PHP runtime serving our sites. Provide the full fixed package revision or image identifier, the relevant vendor advisory, and confirmation that affected workers were restarted or replaced. Please identify any remaining unpatched pools, replicas, staging sites, or bundled runtimes; explain interim traffic restrictions; and confirm whether you have identified suspicious activity affecting our account. If investigation is needed, please preserve relevant logs and coordinate evidence collection before cleanup.
Keep the response with your change records. If the host reports only a WAF change, ask separately for the runtime update status. If the host reports a backport, request the advisory that maps the installed package to both CVEs.
How we researched this article
We prioritized the PHP project's security advisories for technical scope, the Foundation's retrospective for its own decisions, researchers' accounts for their demonstrations, distribution guidance for package details, and provider telemetry for attributed attack observations. We did not run exploits or conduct forensic examinations of readers' systems.
The response and prevention sections are Echo Effect's recommendations, not a claim that a source endorses every step or that we can diagnose a particular site from a version number. The diagrams are original explanatory artwork, not captured attack evidence. All linked incident sources below were reviewed for this October 21 reporting snapshot.
For organizations formalizing their process, NIST SP 800-61 Revision 3 provides an incident-response framework integrated with cybersecurity risk management. Use an established response process and qualified responders when the evidence indicates an intrusion.
Primary sources and further reading
- PHP: October 21 security release, fixed releases and emergency guidance.
- PHP: OOM corruption advisory, CVE-2026-109618.
- PHP: stale global state advisory, CVE-2026-109619.
- PHP Foundation retrospective, discovery, coordination, and process changes.
- Calif research, original technical investigation.
- Wiz research, demonstrations and disclosure chronology.
- Cloudflare response, observed traffic and WAF protection.
- CERT-EU advisory 2026-018, exposure and remediation.
- ENISA joint statement, coordinated European response.
- WordPress security notice, site-owner guidance.
- Canonical's Ubuntu guidance, package revisions and restarts.
- NCSC-NL operational repository, embedded products and vendor tracking.
- Elastic detection guidance, behavioral investigation leads.
- WordPress recovery documentation, evidence and cleanup considerations.
- OpenAI's coordination account, research support and disclosure planning.
- NIST SP 800-61 Revision 3, incident-response recommendations.
Echo Effect's recommendation: close the exposure, establish what actually ran, preserve what can be investigated, and verify recovery. Give every conclusion an owner and supporting evidence. That is how a frightening headline becomes a manageable response.
