You Patched PHP2Shell. Were You Hacked Before You Did?

The PHP2Shell security update is installed. The website loads. The developer says the emergency work is complete.

That is good news, but it answers only one question: is the vulnerable PHP version still running? It does not answer the follow-up that matters just as much: did someone get in before the patch was applied?

PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The PHP project rated both CVSS v4.0 9.2 and said they could allow unauthenticated remote code execution. In plain English, a remote attacker could potentially run code on an exposed server without logging in. The official PHP security advisory lists affected web-serving setups and says updating is the only complete fix.

For a business owner, the job is not finished when a developer reports that the update is complete. The remaining work is to verify the running system and investigate the period when it was exposed.

Why PHP2Shell needs a second check

The dates matter. On 17 October 2026, Amazon Threat Intelligence recorded an exploitation attempt against an AWS honeypot. That was four days before public disclosure. PHP published fixes on 21 October, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The AWS report recommends starting investigations from 17 October, not from the day the patch appeared.

A patch released on Wednesday cannot protect a server that was exposed the previous Saturday. If the update was installed on 24 October, the review should cover 17 October until the vulnerable PHP workers were actually replaced or restarted.

The threat picture continued to develop. On 26 October, CISA added both CVEs to its Known Exploited Vulnerabilities catalog, with 29 October as the remediation deadline for US federal civilian agencies. On 29 October, Palo Alto Networks Unit 42 reported active exploitation against internet-exposed PAN-OS management interfaces and said it had independently verified an attacker campaign chaining PHP2Shell with a Linux kernel privilege-escalation flaw. That is evidence of exploitation in that specific appliance context; it is not proof that every WordPress, Laravel or Symfony site was breached. See The Register's report on CISA's listing and Unit 42's 29 October update.

Unit 42 also retracted a 25 October attribution: it could not confirm that PHP2Shell caused an intrusion at a European government agency. An attack attempt, exploitation and a confirmed breach of a particular organization are different claims. Careful investigation matters.

Three questions to ask your developer or host today

A business owner does not need to run server commands. The developer or hosting provider should answer these questions clearly, preferably in writing.

1. What exact PHP build is handling live website requests now?

Ask for the PHP version, the runtime (PHP-FPM, Apache mod_php, CGI, FrankenPHP or another setup) and the package vendor. The fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux vendors may backport a fix without changing the version string, so request the relevant PHP or vendor advisory.

The command-line version may differ from the web runtime. phpinfo() reports the configuration of the PHP instance in which it runs, so the developer must verify the web-serving SAPI, not just run php -v in a shell.

2. Have all live instances been updated and restarted?

Include production, staging, replicas, PHP-FPM pools, containers and old sites on the same hosting account. A patched image does not update an existing container: it must be rebuilt or pulled and redeployed. Serversideup's release notes document patched images; verify the running container afterwards. See also the Arc AI guide to production-only container traps.

3. Has someone checked for compromise from 17 October until the patched workers were running?

Ask who reviewed web, PHP and system logs; files, accounts, scheduled tasks, processes and outbound connections; and whether logs cover the whole period. “No alerts” is not an investigation.

For managed hosting, ask what was patched, when, whether workers restarted and what evidence is available. Hostinger says it rolled out patched PHP versions on 22 October and disabled session upload progress on 21 October; that statement applies to its own platform only (Hostinger update).

On self-managed hosting, the developer or operations team must do the checks. If the original maintainer has left, regain control of the code, hosting, domain and deployment process first; see the Arc AI guide to taking over a software project.

How to check if a website was hacked before the patch

Ask the technical team to compare the server with a known-good deployment or backup and review:

• Unexpected PHP files. Check the document root, plugins, caches, temporary locations and especially upload folders, where executable PHP files should not normally appear. Match changes to legitimate deployments.
• New accounts or SSH keys. Compare application administrators, hosting-panel and operating-system users with an approved list.
• New scheduled tasks. Review cron jobs, system timers and hosting-panel tasks; identify who created them and what they run.
• Unusual processes. Check for unexpected child processes spawned by PHP or the web server, and verify whether they belong to the application.
• Outbound connections. Investigate connections from the web server or PHP workers to destinations the application does not normally use.
• Logs. Preserve access, error, PHP-FPM, authentication and available firewall logs from 17 October onwards. Look for suspicious requests, unexplained HTTP 500 responses, memory errors and worker crashes or restarts.

These checks reflect defensive advice from Amazon Threat Intelligence and Wiz Research. A suspicious request or crash is not proof of compromise; an absence of obvious traces is not proof of safety either.

Record the dates and systems checked, findings, exclusions and evidence gaps. “No evidence found in the available logs” is more defensible than “definitely not hacked” when logs are missing.

If the investigation finds something suspicious

Do not simply delete the unfamiliar file; that may destroy evidence while leaving other access in place. A qualified team should coordinate the response:

1. Isolate the affected site or server from public traffic and other systems where practical. Preserve relevant logs and evidence before making changes.
2. Restore from a known-good backup taken before 17 October, after checking that the backup itself is clean.
3. Rotate credentials and secrets that may have been exposed: administrator and hosting passwords, database credentials, API keys, deployment credentials, SSH keys and other tokens accessible to the application.
4. Patch and verify the rebuilt environment before returning it to service, then monitor for repeated suspicious activity.

For sites holding customer data, handling payments or connecting to internal systems, use professional incident-response support. Legal or regulatory notification duties may depend on what data was accessed and where affected people are located.

PHP end of life is the next risk

PHP2Shell exposed a longer-running maintenance problem: many sites still use PHP versions that no longer receive normal security releases.

PHP 8.1 and older no longer receive regular project updates. Minimal source backports exist for PHP 7.4, 8.0 and 8.1, but are a stopgap, not a support plan; PHP 7.3 and older have no PHP-project fix. Some Linux and commercial vendors provide their own packages, so ask for the exact vendor advisory. See CERT-EU's summary.

Qualys found 110 million (71%) of 156 million installations with known versions were on end-of-life branches PHP 5.4–8.1; only 199,000 were patched in the first 12 hours. These are telemetry figures, not a count of breached sites (Qualys analysis).

PHP 8.2 has a nearer deadline: it reaches end of life on 31 December 2026. A site running 8.2.35 has fixed PHP2Shell, but still needs an upgrade plan before that date. Businesses with older applications should budget for compatibility work. Arc AI offers legacy application modernization, rescuing, repairing and rebuilding existing software rather than defaulting to a rewrite.

A separate issue also needs attention. On 23 October, PHP published an informational advisory for CVE-2026-115560, involving session upload progress. As of 3 November, the PHP advisory still says a full fix is due in a future regular release. It requires an unusual combination of session settings and application code; PHP recommends session.upload_progress.enabled=0 until then. It is separate from PHP2Shell, so ask the developer to verify the setting and restart workers.

Forward this to your developer

PHP2Shell verification and compromise review

• Confirm the PHP version and vendor security package used by every live web-serving process; do not rely on CLI php -v alone.
• Confirm fixed upstream versions (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or provide the exact vendor backport advisory.
• Rebuild/pull and redeploy patched container images; restart PHP workers and verify the running instances.
• Inventory production, staging, replicas, secondary domains and forgotten PHP sites; record each one's patch status.
• Review PHP files (especially in upload folders), administrator and system accounts, SSH keys, cron jobs and scheduled tasks for unexplained changes since 17 October.
• Review web server, PHP/PHP-FPM, authentication and system logs from 17 October through the patch/restart time; check unusual processes and outbound connections.
• Confirm session.upload_progress.enabled=0 is applied while CVE-2026-115560 remains unfixed, then document the PHP 8.2 upgrade plan before 31 December 2026.

PHP2Shell: frequently asked questions

Does updating PHP remove a backdoor if an attacker already installed one?

No. The update fixes the vulnerable PHP code, but does not automatically remove unauthorized files, accounts or scheduled tasks, or recover stolen credentials. Patching and compromise investigation are separate jobs.

How do I know if my website was hacked through PHP2Shell?

No single check proves a site is clean. Review logs, files, accounts, scheduled tasks, processes and outbound connections from 17 October, and document evidence gaps.

Is PHP-FPM affected, or only Apache mod_php?

PHP's advisory lists PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed among the web-serving setups at risk. The PHP team identified mod_php as the highest-risk setup, but PHP-FPM should not be treated as automatically safe.

Is PHP 7.4 protected by the PHP2Shell patch?

PHP 7.4 did not receive a normal upstream release, but the PHP security team published a minimal source backport. A distribution or hosting vendor may also provide a patched package; ask for the exact vendor advisory and plan to move to a supported PHP branch.

Is PHP 8.2 safe after installing 8.2.35?

PHP 8.2.35 fixes the two PHP2Shell vulnerabilities, but PHP 8.2 reaches end of life on 31 December 2026. Treat 8.2.35 as an immediate security fix, not a reason to postpone upgrading.

A successful patch is necessary. A documented check of the live runtime and the pre-patch exposure window gives a business a defensible answer to the question that matters: not only whether the vulnerability is closed, but whether anything happened while it was open.