PHP2Shell Incident Response: What to Do in the First Hours and Days When a PHP Site May Be Compromised Suspect PHP2Shell hit your PHP site? First-hours steps: isolate without powering off, preserve evidence, hunt web shells, rotate secrets, rebuild, notify PDPC.
PHP2Shell Incident Response: What to Do in the First Hours and Days When a PHP Site May Be Compromised
The PHP update is done. The open question is whether anyone got in before it was.
If you can't answer that yet, this order does the least damage: restrict the server's connections but leave it running, preserve evidence before destructive cleanup, compare files with a verified baseline, revoke every secret the app could read, and rebuild on fixed PHP. In Thailand, the PDPA's 72-hour clock starts when you become aware of a personal data breach, including reasonable grounds to believe one occurred, not when you find vulnerable PHP or first suspect an intrusion.
Why assume the worst? Amazon Threat Intelligence saw a first PHP2Shell exploitation attempt on 17 October 2026, four days before patches shipped, and says it's unclear whether any succeeded. A successful attack runs code as the PHP worker account, no login needed. For the flaws and fixed versions, see the main article in this series .
Take the site offline, or just isolate it?
CISA's incident response playbook weighs the impact on services, the time and people containment needs, and the effect on evidence; one step it lists is temporarily disconnecting public-facing systems from the internet. The UK NCSC says that if you can't update and PHP's mitigations aren't feasible in time, consider taking the system offline.
Isolating is not powering off: CISA's AA20-245A warns that acting too early loses volatile data such as memory. Pulling the server from the load balancer only stops app traffic; it doesn't contain the host. Restrict ingress, egress and lateral connections, verify the restrictions hold, and keep one controlled path for evidence collection. On AWS, a security group change doesn't cut tracked connections immediately; AWS points to network ACLs for that. Nor is an IP block a fix: blocking without knowing how the attacker got in leaves their access intact, and Amazon calls its published IPs shared anonymization infrastructure, to investigate rather than blindly block.
Preserve evidence before destructive cleanup
Restoring a backup over the affected server can overwrite evidence on it. CISA's playbook says to collect logs at several layers, capture memory and a disk image when forensic analysis is needed, and record how, when and by whom each item was acquired. For a PHP site we'd add web server, PHP-FPM and app logs, a snapshot or container export, a hashed web root listing, and running processes and connections. Amazon says to start from 17 October, so check whether log rotation already discarded that window.
Whoever controls a compromised host can edit its logs; logs shipped off the box beforehand are worth more. That's the job of zcrLog , which keeps logs for 90 days to 2 years with MD5, SHA-1 and SHA-256 integrity checks and AES-128 encryption. This article doesn't claim zcrLog reads Apache or PHP-FPM logs; you can look back only through what you send it, such as firewall logs.
Hunting for web shells: what do you compare against?
MITRE ATT&CK describes web shells as a way to backdoor web servers for persistent access. NSA recommends comparing production with a "known-good" fresh install of the same application, updates applied, and vetting every added or changed file. A deployed release counts as known-good only if obtained from outside the suspected host and verified independently, with the repository and build pipeline checked for tampering; review every difference. Then check:
Directories PHP can write to: uploads, tmp, framework cache (our addition)
The web user's crontab; MITRE lists cron for recurring malicious execution
New OS accounts and new admins in the app database
Processes the web server spawned; NSA notes benign web servers rarely launch ipconfig
Outbound connections from PHP or the web server, which the Canadian Centre for Cyber Security says to investigate
The sources we reviewed publish no PHP2Shell-specific web shell name or hash, so the baseline comparison matters more. For the log side, see hunting PHP2Shell in server logs .
Which secrets need rotating?
Every one the app can read: database passwords, API keys in .env, cloud keys, payment credentials. Code with the app's privileges reads what the app reads, the CVE-2026-109619 advisory also lists memory disclosure, and CISA calls for rotating secrets where compromise is suspected.
Our suggested order: revoke old values at the source now, and put new ones only on the rebuilt host. Invalidate all sessions too, since Sansec reports PHPSESSID cookies can carry leaked memory. For an exposed cloud key, check the audit log back to 17 October, in zcrLog if you already send it AWS CloudTrail or Google Cloud audit logs.
Why rebuild instead of cleaning in place?
Deleting one web shell doesn't rule out a second. CISA notes attackers often keep more than one backdoor and slip back into "clean" areas, so it calls for reimaging from "gold" sources or rebuilding from scratch.
Rebuild on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and later, or backported distribution packages (8.1 and older need a vendor backport or an upgrade). Restart every worker, pull code from a verified source, check restored uploads for stray .php files (our suggestion), and test before reconnecting, as CISA advises. After reconnection, keep watching for re-entry; AWS recommends full PHP error logging but warns that the absence of errors is not proof of safety.
Who has to be notified in Thailand?
PDPA Section 37(4) requires the controller to notify the PDPC Office without delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to risk people's rights and freedoms; if the risk is high, data subjects must be told too, with remedial measures. The DPO should assess alongside the investigation.
The PDPC's 2022 rules list what the notice covers: the breach, DPO contacts, likely impact, measures taken. If a delay is unavoidable, notify promptly and no later than 15 days after becoming aware, with reasons; the PDPC may then consider an exemption. It is not a routine extension. Under clause 8, contracts must require processors such as hosts and agencies to notify the controller without delay and, where feasible, within 72 hours of their own awareness; notifying the PDPC stays the controller's duty. Notices go on form ตข. 001 to saraban@pdpc.or.th ; the form says to file a police complaint if a crime is found. This is what the texts say, not legal advice.
ThaiCERT, under the National Cyber Security Agency, monitors, analyses, alerts on and coordinates responses to cyber threats: thaicert@ncsa.or.th or 02 114 3531 (24 hours).
The first stretch at a glance
When What Done when you have On suspicion Restrict connections, don't power off; tell the DPO Incident detection time (not yet the 72-hour start) Before cleanup or reimaging Logs, memory, snapshot, hashes Who collected what, when Day one Verified-baseline comparison; cron, accounts, processes since 17 Oct Findings, or "nothing found" with limits Day one Revoke secrets at source; kill sessions List of revoked secrets Reasonable grounds to believe personal data was breached DPO risk assessment Breach-awareness time (72-hour clock starts) Before go-live Rebuild on fixed PHP, new secrets Tests passed Within 72 hours of breach awareness File form ตข. 001 if it applies Copy of the notice After reconnection Watch errors, new files, outbound traffic Monitoring with an owner, coverage, review period and escalation criteria
When several responders hand this off and you need a record of who approved each step, compare the plans on the pricing page .
The sequence above is our recommendation, and the next incident will need it again; rebuilding it from memory under pressure is where steps slip. zcrSOAR can keep it in its playbook library with versions, approval and dry-runs, and set each step to Autonomous, Approval or Blocked, so data gathering runs alone while cutting a host off waits in one approvals queue; every run records timestamp, user, action and result. It is sold separately from zcrSIEM and doesn't detect PHP2Shell: the fix is still patching PHP.
To see the screens first, try the live demo .
What free tools do well, and this article's limits
Free tools handle baseline comparison: sha256sum against a verified release, git --no-optional-locks status --ignored --untracked-files=all on a preserved copy rather than the live host, and NSA's free scripts. None alone proves a host is clean. Whether a checklist or SOAR fits depends on incident complexity, responder capability, coordination needs and evidence obligations.
This isn't a forensics guide. Evidence-grade memory capture takes skilled people; without them, CISA and NCSC recommend an external incident response provider. And "nothing found" is not "not compromised."
Related reading
Which PHP version does every host run? · Ransomware containment with an approval gate · Evidence auditors ask for after an incident · PDPA: 8 things organizations must do
Get in touch
Want a second opinion on which steps your response playbook needs, and which should wait for a person to approve? Talk to our team — the consultation is free. zcr supplies the software; hands-on investigation, evidence acquisition, containment and recovery are delivered through partners.
Sources
Amazon Threat Intelligence — PHP2Shell exploitation prior to public disclosure — first attempt 17 Oct 2026, success unclear, start investigations from 17 Oct, IPs are shared anonymization infrastructurePHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — unauthenticated code execution as the web worker account; memory disclosurePHP.net — 2026 news archive — fixed versions, PHP 8.1 and older, restarting workersCISA — Cybersecurity Incident & Vulnerability Response Playbooks — evidence collection, containment options, secret rotation, reimaging from gold sources, testing and monitoringCISA AA20-245A — Technical Approaches to Uncovering and Remediating Malicious Activity — collect before mitigating, loss of volatile data, IP blocking, third-party IR supportUK NCSC — Critical security issue affecting PHP — consider taking systems offline; incident response providersCanadian Centre for Cyber Security AL26-026 — what to investigateAWS — Using AWS WAF to apply mitigations for PHP2Shell — error logging; "the absence of errors is not proof of safety"Sansec — PHP2Shell — PHPSESSID cookies carrying leaked memoryNSA Cybersecurity — Mitigating Web Shells — known-good comparison; unusual processes launched by the web serverMITRE ATT&CK T1505.003 Web Shell and T1053.003 Cron Personal Data Protection Act B.E. 2562 (2019), unofficial translation published by the PDPC — Section 37(4)PDPC Notification on Criteria and Methods for Personal Data Breach Notification B.E. 2565 (Thai) — clauses 5, 6, 7, 8PDPC — Personal data breach notification form ตข. 001 (Thai) — submission address and police-complaint noteThaiCERT and About ThaiCERT — role and reporting contactsAWS — Amazon EC2 security group connection tracking — changing a security group rule doesn't immediately interrupt tracked connections; network ACLs break them at once Products | Pricing | Resources | Insights | Contact 