Information reviewed： · Published by Tsumira Japan (SourceArt Ltd)
The two vulnerabilities concern PHP runtime memory and request-state handling. Affected environments may permit unauthenticated code execution or information disclosure. A working website, updated CMS or deployed WAF alone does not establish that the underlying runtime has been fixed.
1. What was disclosed, and when?
PHP published CVE-2026-109618, CVE-2026-109619 and fixed releases on 21 October 2026. This analysis was reviewed on 22 October 2026. We use explicit dates so that the publication and review do not become ambiguous as “today” changes.
PHP2Shell is a research label. Operational records should contain both CVEs, the supplier and package identifiers. This concerns the runtime, so a search restricted to WordPress plugins can miss the component requiring maintenance.
| Identifier | Core issue | Operational focus |
|---|---|---|
| CVE-2026-109618 | Interrupted memory allocation and inconsistent request state | Actual runtime, applicable patch and process replacement |
| CVE-2026-109619 | State surviving a request and referring to freed memory | Coverage of multiple paths and configuration review |
2. Terms: runtime, SAPI, worker and RCE
| Term | Meaning here |
|---|---|
| PHP runtime | The software executing the application, potentially maintained separately from the CMS. |
| SAPI | The execution interface linking PHP to a web server or other host, such as mod_php, FPM or CGI. |
| Worker | A process handling requests, sometimes reused for subsequent requests. |
| OOM | Out of memory: a PHP limit and an underlying allocation failure are distinct conditions. |
| Use-after-free | Treating released memory as though it still contained valid live data. |
| RCE | Remote code execution; consequences also depend on process privileges and the surrounding system. |
Separate the PHP installed on disk, the PHP already loaded into a process, and the PHP actually reached by a website request. Changing or inspecting one does not establish that all three agree.
3. CVE-2026-109618: interruption during memory exhaustion
PHP’s advisory describes an OOM interruption leaving incomplete request state that later shutdown processing may consume. Memory corruption can lead to code execution. For mod_php, a demonstrated path occurs before application code starts.
- Handle a request
- Memory exhaustion interrupts work
- Incomplete state remains
- Shutdown consumes that state
Operationally, an application login check should not be treated as a substitute for runtime maintenance. Track application authorization and the PHP fix as separate controls.
4. CVE-2026-109619: state surviving its request
The second PHP advisory describes worker state retaining a reference after its request memory is freed, then consuming it later. Both the state-producing and state-consuming operations matter; several error and session paths are involved.
- Request A creates state
- A reference outlives its memory
- The worker is reused
- Request B consumes the old reference
Source: PHP stale-state advisory ↗
Do not equate changing one setting with fixing the entire vulnerability. Restarting an unchanged vulnerable binary is also insufficient: the replacement process needs the applicable fix.
5. Impact includes memory disclosure as well as execution
Wiz Research reports unauthenticated RCE demonstrations using WordPress, Drupal and Joomla, and disclosure of PHP process memory. Those are representative research targets, not a boundary limiting the issue to those CMS products.
A successful compromise could put the configuration, credentials and application data accessible to the process into the investigation scope. The disclosure or a version string does not prove that an individual website has already leaked data.
Source: Wiz Research findings ↗
Assess business impact beyond downtime: bookings, orders, customer records and connected APIs. Determine what the affected process could access in your environment rather than assuming every deployment has identical impact.
6. How to assess mod_php, FPM, CGI and other integrations
PHP’s release guidance covers web-serving installations. The demonstrated paths and conditions differ by integration. PHP identifies mod_php as particularly high risk; this is not evidence that FPM is exempt.
| Deployment | What to inspect |
|---|---|
| Apache mod_php | Loaded PHP module and the Apache processes using it. |
| Nginx or Apache with FPM | The target FPM binary, pool and active workers. |
| php-cgi or FastCGI | Launch configuration, supplier and persistent processes. |
| FrankenPHP or LiteSpeed | The PHP included in the product/build and supplier guidance. |
| Containers and multiple nodes | Each image, replica and request destination, independently of host PHP. |
Being within the affected scope does not imply that the same exploit was demonstrated against every configuration. Equally, an unvalidated path is not a safety certification.
7. Fixed releases and vendor backports
| Upstream PHP branch | Release containing these fixes |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
These are upstream release boundaries. Vendor packages can retain an earlier prefix while incorporating fixes. Identify the branch, supplier, full package revision and applicable notice together.
For example, Ubuntu 24.04’s USN-8948-1 lists 8.3.6-0ubuntu0.24.04.13. Debian publishes release-specific security packages too. Do not apply an Ubuntu package comparison to Debian or third-party packages.
For PHP 8.1 or earlier, confirm separately whether the supplier provides these fixes and ongoing maintenance. Remaining available to run is not a commitment to provide security updates.
8. Why interim measures are not completion evidence
An administrator should assess interim measures if an update cannot be applied immediately. The following explains their role, not a configuration recipe. Availability, memory exhaustion and application behaviour require assessment.
| Measure | Limit to consider |
|---|---|
| WAF or request limits | Check coverage and bypass routes; they do not replace the runtime fix. |
| memory_limit=-1 | A mitigation for PHP-limit paths with separate memory and allocation risks. |
| session.upload_progress.enabled=0 | Addresses confirmed session paths, not all variants. |
| PHP 8.5 fatal_error_backtraces=0 | Limited to the relevant backtrace path. |
| Disable display_errors | Error visibility and root-cause remediation are different controls. |
Configuration placement and when workers apply it matter too. Do not assume an application-level ini_set() is sufficient. Have the administrator consult the advisories, record any temporary measure and its expiry, and progress toward a fixed runtime.
9. What an external URL check can establish
| Observation | Evidence boundary |
|---|---|
| A public PHP header | The disclosed string, not a complete runtime inventory. |
| No version found | Insufficient public evidence, not proof of either safety or vulnerability. |
| A fixed upstream number | A useful indication, not proof covering all origins and nodes. |
| HTTP 200 | A response, possibly cached, rather than proof of remediation. |
Tsumira’s passive check reads public information. It does not attempt exploitation or investigate compromise. Use it as an entry point toward supplier, administrative and running-process evidence.
10. A practical prioritization framework
| Situation | First action |
|---|---|
| Patch state unknown | Identify runtime and supplier, then establish the fix and required action. |
| Fix available but not deployed | Prepare recovery and maintenance, apply it and replace old workers. |
| Fix unavailable or support unclear | Contact the supplier and assess exposure reduction and a maintained migration path. |
| Unexpected files, accounts or connections | Coordinate evidence preservation and incident response alongside patching. |
| Only part of a fleet updated | Identify remaining nodes and verify traffic destinations and coverage. |
This is an operational organizing framework, not an individual risk verdict or a response-time guarantee. Where customer data or business interruption has major consequences, involve the administrator and appropriate specialists.
11. Compromise assessment and patching are separate tasks
Research guidance highlights unusual requests, memory errors, repeated 500 responses and unexplained worker churn as investigative leads. No single such observation proves exploitation of these CVEs.
Preserve relevant timestamps and existing logs and identify changes before making additional adjustments. Coordinate evidence handling, investigation scope, recovery and credential decisions through a trusted administrative path.
Conversely, normal rendering, a lack of observed errors or a newer public version does not prove the absence of compromise. Keep incident-assessment conclusions separate from patch completion records.
12. Evidence to retain before reporting completion
- Covered domains, nodes, pools and containers, plus reasons for any exclusions.
- Supplier notice, full installed package revision or image identifier and review timestamp.
- Evidence that the relevant process was replaced and mapped to actual web requests.
- Customer-journey tests, unresolved issues and the next responsible owner.
Report what changed, what was verified and what remains unknown separately. This makes it possible for the site owner to decide whether further action is needed. Missing evidence should remain an explicit open item.
13. Next: follow the update procedure or request assistance
Open the server update and verification guide with commands →
Experienced administrators should match the procedure to their environment and supplier guidance. If you cannot identify the stack, assess the commands or confirm recovery, ask for investigation and update support before attempting changes.
This general technical explanation does not certify individual security, absence of compromise or successful execution. Tsumira Japan agrees scope and cost before carrying out paid work.
Questions and answers
Does an updated WordPress mean no PHP work is needed?
No. The CMS and server runtime may have different maintainers and update procedures.
Is PHP-FPM unaffected?
That conclusion is not supported. Paths and conditions differ, while PHP recommends updating web-serving installations.
Can a WAF replace patching?
Treat it as one defensive layer, verify its coverage and continue toward the applicable runtime fix.
Does disclosure mean my site was already attacked?
No. Disclosure and version evidence cannot establish compromise. Investigate concerns and preserve evidence with the appropriate specialists.
Official references
- PHP: 21 October 2026 security announcement ↗
- PHP advisory: RCE via OOM corruption ↗
- PHP advisory: RCE via stale global state ↗
- Wiz Research: PHP2Shell findings ↗
- Ubuntu: fixed package notice ↗
- Debian: PHP 8.2 security package ↗
- Debian: PHP 8.4 security package ↗
- PHP: supported versions ↗
Official guidance and interfaces can change. Confirm your actual plan, configuration and the supplier’s latest notice. This guide does not certify the security or patch status of any individual environment.
Need help with your site?
We can help clarify the information and scope. Paid work begins after you approve the scope and cost.