php2shell: A Practical PHP Response Guide from Maverc’s Advanced Threat Unit

If your organization runs PHP, the immediate question is simple: where is it running, and have those systems received the security fix? The harder question comes next: could someone have reached them before you patched?

The two PHP core vulnerabilities commonly called php2shell, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote code execution in affected deployments. Because the flaws sit in the runtime rather than an individual website plugin, an application update alone does not necessarily address them.

This is Maverc’s Advanced Threat Unit response guidance for the teams responsible for those systems. Our recommendation is to treat patching and compromise assessment as separate workstreams. A patched server may still contain an attacker’s webshell, stolen credentials, or persistence left behind before the update.

What the vulnerabilities mean for your environment

Both issues involve PHP’s handling of memory and request state. CVE-2026-109618 concerns unsafe handling around memory exhaustion during request initialization. CVE-2026-109619 concerns stale request-related state that can lead to a use-after-free. Successful exploitation can give an attacker execution in the context of the affected process.

That does not automatically mean root or administrator access. It does mean the attacker may gain the web worker’s access to application files, connection strings, service credentials, and reachable systems. A tightly restricted service account limits the damage. A web worker with broad permissions can turn a website incident into a much larger compromise.

Apache deployments using mod_php deserve urgent attention because vulnerable processing can occur before application code runs. Authentication inside your application is therefore not a reliable boundary for this issue. PHP-FPM, CGI, FrankenPHP, and LiteSpeed environments also need review against the PHP advisory and their vendor’s guidance. Do not assume a different web server or request handler makes you safe.

First, find every copy of PHP

Start with externally reachable applications, then work through internal systems and packaged software. The obvious websites are only part of the inventory. Hosting panels, legacy business applications, containers, and vendor appliances may each carry their own runtime.

• Record the application, business owner, host or container, exposure, PHP branch, package source, and request handler.
• Check the runtime actually serving web requests. The result of php -v describes the command-line binary, which may differ from the PHP-FPM pool or Apache module in production.
• Review running services, web server configuration, package records, container image manifests, and vendor documentation to identify additional copies.
• Include standby nodes, autoscaling templates, disaster recovery systems, scheduled workers, and images that could redeploy a vulnerable runtime later.
• For hosted applications and appliances, ask the provider which advisory applies, what fixed build they supply, and whether the running service has been updated. Keep their response with the asset record.

Avoid placing a public phpinfo page on your site to investigate. It can expose configuration and environment details. Use administrative access or a restricted diagnostic method, then remove temporary diagnostics.

Patch the runtime, not just the application

The PHP security releases addressing these issues are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Use a supported release containing these fixes or a later security update from a trusted source. Confirm the release notes against the branch you actually deploy.

Distribution and appliance vendors may backport fixes without changing the displayed version to one of those upstream numbers. In that situation, verify the installed package’s full build identifier against the vendor’s security advisory. A scanner that checks only a version string can report a patched backport as vulnerable or miss an unpatched bundled runtime.

• Prioritize internet-facing systems, especially mod_php deployments, then systems that hold sensitive information or can reach important internal services.
• Test the updated runtime with the extensions and application dependencies used in production. Exercise authentication, file uploads, payment or transaction workflows, and background jobs as applicable.
• Deploy the verified package or rebuilt image. Restart or replace the affected PHP workers and web services as required so the old process is no longer handling requests.
• In a cluster, verify every node and pool. Updating one host does not close exposure on its peers.
• Update deployment templates and base images, then confirm a fresh deployment also contains the fix. Otherwise scaling or recovery can undo your remediation.
• If compatibility prevents an immediate update, restrict or remove exposure while the owner and vendor resolve it. Do not silently return to a vulnerable version as a rollback strategy.

PHP 8.1 and older are outside upstream support. Some older branches have limited source backports or vendor-maintained fixes, but those are not a substitute for a supported migration plan. Verify the exact build rather than assuming any older package is protected.

What to do while the patch is being prepared

The PHP project’s guidance is that configuration changes are not a complete substitute for updating. Memory limits and request-size controls may narrow particular paths, but they do not establish that the vulnerability is resolved.

Use temporary controls to reduce exposure, not to declare the incident closed. Apply request-body limits at the reverse proxy where appropriate, restrict administrative applications to approved networks, disable unneeded endpoints, and limit outbound connections from web workloads to destinations they genuinely need. Check that a proxy rule cannot be bypassed through a directly reachable origin server.

A WAF rule, a lower post_max_size value, or disable_functions is not proof of remediation. Test legitimate uploads and business transactions before tightening limits. If an exposed system cannot be patched or meaningfully isolated, consider taking it out of service until a fixed build is available.

Hunt for behavior, not just a named exploit

Do not wait for a public proof of concept before reviewing your environment. Useful detections already exist for what attackers do after gaining execution. These signals are not unique to php2shell, and an alert alone does not prove which vulnerability was used.

Start with process lineage. Look for php-fpm, php-cgi, lsphp, or an Apache worker launching a shell, another interpreter, or a downloader. Nginx typically passes PHP requests to a separate worker, so follow that worker’s activity rather than expecting Nginx to be the parent of every suspicious process.

• Unexpected command execution, including identity and host discovery through id, whoami, uname, or hostname.
• Shells or interpreter one-liners launched by web workers, particularly with encoded content or unusual arguments.
• curl or wget downloads followed by execution, or unexpected outbound connections to unfamiliar hosts.
• New or modified executable files in the web root, upload directories, temporary paths, or application code outside the normal release process.
• Reads of application secrets, cloud credentials, or service account tokens that do not fit the workload’s normal behavior.
• New cron jobs, service definitions, SSH keys, or privileged accounts without a corresponding approved change.
• Changes to logging, security agents, permissions, or application configuration that could conceal activity or preserve access.

Some applications legitimately invoke converters, backup utilities, or shell commands. Compare alerts with approved behavior, process arguments, the service account, destination, file changes, and nearby requests. Tune known workflows narrowly instead of excluding the entire PHP service from monitoring.

A clean process alert history is not proof of safety. An attacker may stay inside the compromised process without launching a shell, and telemetry may be incomplete. Combine process, file, network, application, and cloud audit evidence.

Connect suspicious requests to host activity

Review reverse proxy, access, error, PHP-FPM, and application logs alongside endpoint telemetry. Unusually large multipart requests, request-initialization memory errors, or worker crashes can help prioritize investigation. They may also have benign causes, and a successful exploit need not crash the worker.

• Preserve original timestamps and time zones, and normalize them when building a timeline.
• Correlate request IDs, destination host, URL path, response status, worker activity, and file changes where your logging supports it.
• Use forwarded client addresses only when your proxy configuration establishes a trusted source. Otherwise an attacker may supply misleading headers.
• Review the period the vulnerable service was exposed, using the longest useful retention available. Do not assume public disclosure marks the beginning of possible compromise.
• Document missing telemetry as a visibility gap, not as a negative finding.

Avoid running untrusted exploit code on production systems to see whether they are vulnerable. Validate patch status through the advisory and installed build. Any exploit-based testing belongs in an authorized, isolated environment.

If you find signs of compromise

Patching stops the known entry path; it does not undo an intrusion. Escalate credible evidence through your incident response process and establish an owner for containment, investigation, and recovery.

• Isolate the affected workload or remove it from the load balancer while preserving evidence. Coordinate availability decisions with the application owner.
• Preserve relevant logs, suspicious files, process information, and forensic snapshots where your platform and response procedures support them. Avoid destroying useful evidence through an immediate reimage.
• Determine what the compromised service account could read, modify, or reach. Investigate shared storage, adjacent hosts, cloud activity, and authentication records rather than stopping at the web root.
• Revoke exposed tokens and rotate potentially accessed application, database, and cloud credentials from a clean administrative environment. Replace the compromised credential, update dependent services, and verify the old credential no longer works.
• Remove persistence and restore from a trusted, patched image when compromise is confirmed. Deleting a single webshell is not a reliable recovery plan.
• Follow your organization’s legal, contractual, and notification procedures if the investigation identifies affected data or reporting obligations.

Be deliberate about credential rotation. Rotating a secret while an attacker still controls the application may simply give them the replacement. Coordinate isolation, rebuilding, revocation, and restoration so access is actually removed.

How to know the work is complete

A closed ticket should demonstrate more than a successful package installation. Keep a short evidence record that another person can verify.

• Every in-scope runtime has a confirmed fixed upstream release or vendor backport, with the package or image identifier recorded.
• The running web-serving processes have been restarted or replaced and verified, not just the command-line binary.
• All production nodes, failover systems, deployment templates, and replacement images have been checked.
• Critical application workflows pass testing, and monitoring remains enabled after the change.
• The compromise review has an owner, a documented lookback period, findings, and any visibility limitations.
• Where compromise was found, persistence removal, recovery, credential revocation, and follow-up monitoring are documented separately from patching.

Run a follow-up exposure check after deployment and again after the next scaling or release event. That second check helps catch vulnerable images or forgotten nodes returning to service.

Maverc’s Advanced Threat Unit guidance

The priority is straightforward: identify the actual runtime, deploy a verified fix, investigate the exposure window, and retain evidence that both patching and recovery are complete. Behavioral detection provides another layer of defense, but it cannot guarantee that every attempt will be caught.

Maverc’s Advanced Threat Unit can help teams assess PHP exposure, review suspicious activity, and validate detection coverage. Our managed detection and response and incident response services support the work from initial triage through recovery, while penetration testing can evaluate defenses in an authorized environment.

Technical basis: PHP project security advisories and release guidance. This article provides Maverc’s operational recommendations; it does not claim original discovery of these vulnerabilities. Recheck the PHP project and your software vendor for updates before making production changes.