PHP2Shell: check your PHP and verify the running fix

15 questions about checking and fixing PHP2Shell

1. What should I do when a scanner reports PHP2Shell?

Save the alert, affected hostname, detection time and evidence it used. Ask whether it matched an advertised version, inspected an installed package or tested behavior. Then map its finding to the two CVEs and your actual PHP supplier. Start the technical comparison with the PHP advisory for CVE-2026-109618 and its companion advisory.

2. Is PHP-FPM affected, or only Apache mod_php?

PHP includes FPM in its risk guidance. The out-of-memory advisory explains that FPM handles failure during request startup differently from mod_php, while other failures after startup can still reach affected cleanup behavior. At publication, that advisory described FPM as susceptible without reporting a complete FPM exploit for that issue. Do not apply the demonstrated mod_php attack's exact conditions to every interface or exempt FPM from patching. See PHP's susceptibility analysis.

3. Will updating WordPress, Drupal or a PHP plugin fix this?

Check what the update actually contains. These advisories concern the PHP interpreter, so an application-only update leaves the runtime question unresolved. If a product bundles PHP, its supplier may deliver the runtime fix in a product update. Ask for the product notice, fixed build and instructions that apply to your installation. NCSC-NL's operational guidance includes software that embeds or depends on PHP, beyond ordinary websites.

4. Why does php -v disagree with my hosting panel?

The commands may refer to different PHP installations or interfaces. Your shell can select a command-line executable while a hosting account uses a separately selected web runtime. PHP's command-line introduction explains that binary names and locations depend on installation. Record both outputs, then have the host identify the executable or module serving the specific website.

5. Which php.ini file matters for my website?

Use the configuration loaded by its web runtime. PHP can select different files by interface and can scan additional configuration directories. A command-line --ini report belongs to that invocation. Ask for the loaded web configuration path and any relevant pool or server overrides through a protected administrative report. PHP's configuration-file documentation explains the search order and when files are read.

6. Can PHP 8.3.6 already contain the PHP2Shell fix?

Yes, when the supplier documents a fixed package based on that version. Ubuntu 24.04's 8.3.6-0ubuntu0.24.04.13 is one specific example in USN-8948-1. A bare 8.3.6 does not identify that package revision or its source. Preserve the full version, operating-system release, package name and supplier notice together, then confirm that the site's PHP workers use the installed fix.

7. What evidence should I request from a shared hosting provider?

Ask it to confirm both CVEs for your hosting account, identify the fixed package or internal build, link its advisory or package source, and state when affected web workers were replaced or restarted. Include each site's selected PHP branch if accounts can use different versions. Where a provider uses a private build, ask for its written mapping between that build and both fixes.

8. Does a successful package update mean the fix is running?

Package records identify the installed build. Canonical's update guidance says applications can still require a restart after updates, including those installed automatically. Have the operator check affected services and workers, then obtain a web-runtime report and application checks. Keep the installation time and service transition evidence together so another administrator can review how the conclusion was reached.

9. Must I check every PHP-FPM pool and website?

Map every site to its pool and PHP service, then check each distinct runtime. Several pools can share a fixed service, while another service on the same machine runs a different PHP branch. Pool configuration can also supply settings that differ between sites. PHP's FPM configuration reference documents global and pool settings. Use shared evidence where it actually covers several sites, and retain individual application checks where their behavior differs.

10. How should I verify PHP inside a container?

Record the running container's image identity, the fixed PHP build in that image and the deployment that created the current container. Docker documents how inspection returns container information and how digests identify image content. An image name alone leaves important details unresolved. Use existing authorized operator access; the Docker security guidance warns that Docker group membership grants root-level privileges. This workflow does not require giving a site owner Docker access.

11. Will a web application firewall make an unpatched server safe?

PHP says its temporary measures reduce particular attack paths and that updating is the complete solution. A firewall rule needs its own supplier guidance, scope and validation. Record which requests it covers and whether any route reaches the origin server without it. Treat it as an interim control while arranging the fixed runtime. The PHP security announcement describes the limits of temporary measures.

12. Should I copy temporary PHP settings from an online guide?

Have the responsible administrator review the official guidance against the application's settings and resource limits first. For example, PHP's advisory discusses removing its own memory limit alongside other limits and an external availability boundary. That changes failure behavior and needs operational review. Use PHP's current out-of-memory advisory when planning an approved interim change.

13. What if my site still needs PHP 7 or PHP 8.1?

Identify the vendor maintaining that build and check for a documented backport covering both CVEs. Upstream PHP support has ended for those branches. Ubuntu lists a standard-support fix for its PHP 8.1 package on Ubuntu 22.04 in USN-8948-1. Its fixes for older Ubuntu releases in USN-8948-2 use specific Ubuntu Pro coverage. Availability depends on the release, package and maintenance entitlement. Alongside any supported vendor fix, plan application compatibility work toward a branch covered by PHP's current support schedule.

14. How can I tell whether someone attacked the server before patching?

Open a separate investigation with the person responsible for security. Define the period when an affected runtime was reachable and preserve relevant web, PHP, host and deployment records before retention policies remove them. Ask the investigator to assess unexpected files, account changes, process activity and available logs in context. Package checks and ordinary page loads leave earlier compromise unresolved.

15. Can I verify remediation without running an exploit?

Use the documented fixed build, a complete runtime inventory, evidence that affected workers were replaced, and agreed application checks. Record limits such as an inaccessible backend or a vendor build still awaiting confirmation. If your organization requires further security validation, have its security lead define the authorized scope and method separately. Keep the resulting conclusion tied to the CVEs, systems and checks actually covered.