--- title: "PHP2Shell Compromise Checks: What to Review After Patching" url: "https://healywebdesign.co.uk/news/php2shell-compromise-checks-what-to-review-after-patching/" type: "post" published: "2026-10-26T09:00:00+00:00" modified: "2026-10-23T21:36:52+00:00" author: "leehealy" --- **Information checked: 23 October 2026.** PHP2Shell compromise checks require evidence from the individual environment. This guide helps business owners organise observations and obtain appropriate help; it does not diagnose a website or replace incident-response expertise. When a hosting provider confirms a PHP fix, one important question has been answered: what has been done to address the vulnerability? Another question remains separate: what happened before that work was completed? Patching and investigating earlier activity serve different purposes. Confusing them can produce both unnecessary alarm and unjustified reassurance. A useful review starts with precise language, a timeline and a named person responsible for assessment. Our [PHP2Shell background guide](https://healywebdesign.co.uk/news/php2shell-security-alert-uk-website-owners/) explains the original alert. Here, the focus is how to handle possible compromise after remediation without destroying evidence, inventing conclusions or treating a quick scan as an all-clear certificate. ## Separate vulnerability, attempt and compromise A vulnerability is a weakness that may be exploitable under relevant conditions. An attack attempt is activity intended to use a weakness. A successful compromise means an attacker obtained unauthorised access or influence. Evidence of one does not automatically establish all the others. A website can have required a patch without any confirmed successful intrusion. Equally, a blocked request is evidence about that request and the control that blocked it. It does not establish that all earlier requests were blocked, that every route passed through the same protection, or that no other weakness existed. Ask the reviewer to state the scope of each observation and the conclusion it supports. Data impact needs its own assessment. Code execution, account access, altered content and exposure of customer information are related possibilities, but they are not interchangeable findings. Avoid telling customers that information was stolen, or that no information was affected, before the evidence supports that statement and the appropriate advisers have assessed the situation. ## Preserve a clear timeline Record when the business first became aware of the issue, when the host was contacted, when any temporary measures were applied and when remediation became active. Include timezones. A sequence of messages saying “this morning” or “last night” becomes difficult to interpret when several suppliers operate in different locations. Add the time each suspicious symptom was first noticed and who observed it. Separate observation time from the time the underlying event may have occurred. A redirect discovered on Friday might have been introduced earlier. A log entry created on Wednesday may only have been reviewed on Friday. Preserving those distinctions prevents accidental certainty. [Amazon’s incident research](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) describes attempts observed before public disclosure and notes uncertainty about whether the earliest attempts would succeed against real systems. Its findings justify taking historical activity seriously, but do not prove that your own site was compromised. Ask the investigator to select a review window based on your environment and available evidence. ## Document symptoms before changing everything Write down exactly what you see. Useful observations include an unfamiliar administrator account, an unexpected redirect, changed payment details, unrecognised files or a host’s malware warning. Record the relevant page address, time and visible behaviour. Avoid vague statements such as “the website looks hacked” when more specific information is available. The [WordPress incident guidance](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) recommends documenting symptoms and recent changes. A screenshot can preserve what a visitor saw, while a technical reviewer may need logs or file information to explain it. Keep originals available and let the responsible person decide what evidence needs preservation. Do not repeatedly delete unfamiliar files, reinstall components or restore backups before obtaining advice when compromise is suspected. Those actions may remove clues or change the timeline. Urgent containment can still be necessary; the point is to coordinate it with evidence preservation rather than have several people making unrelated changes without a record. ## Ask about log availability early Different evidence may be held by the hosting provider, application, firewall, identity service or integration supplier. Ask who has access to each source and how long it is retained. Some logs rotate quickly, so a delayed request can leave a gap that cannot be repaired later. The business owner does not need to interpret every entry to arrange preservation. Request an explanation of the coverage. Web access logs may show requests but not every action performed after a compromise. Application logs may omit events that happened before application code ran. A firewall record may cover only traffic passing through that service. No single log should be assumed to provide a complete history. Handle logs as potentially sensitive material. They can contain identifiers, addresses, request details or personal information. Use the authorised secure channel agreed with the reviewer and share only what is needed. Do not paste a full production log into a public forum or send it to an unknown person offering a free diagnosis. ## Review accounts and permissions in context An unexpected privileged account deserves investigation. Ask who created it, when it appeared, what permissions it has and whether it corresponds to authorised supplier work. A legitimate maintenance account may be unfamiliar to the business owner, but that explanation should be verified rather than assumed. Consider access beyond WordPress. Hosting panels, domain services, deployment tools and connected systems may have separate identities. The incident lead should determine which accounts need review and which credentials may require controlled replacement. Avoid changing everything at random while the host or investigator is trying to preserve access and establish what happened. Document access changes that are made during the response. Record the reason and the responsible person without storing passwords in the incident notes. This helps distinguish defensive actions from suspicious activity and makes it easier to hand the work over if another specialist becomes involved. ## Assess file and content changes carefully Files can change for legitimate reasons: updates, uploads, cache generation and normal development all leave traces. An unfamiliar filename or recent modification time is a lead to investigate, not a final diagnosis. The reviewer needs context, trusted reference material and knowledge of how the application is deployed. Visible content is only part of the picture. Unexpected links, scripts, redirects or administrative changes may appear selectively. A site can look normal to a logged-in owner while visitors experience something different. Report the conditions under which the behaviour occurs rather than assuming that a single clean page load disproves it. Do not download and open suspicious files on an ordinary work computer to see what they do. Let the responsible specialist handle potentially malicious material through an appropriate process. Business staff can still contribute useful evidence by noting what changed, who reported it and whether there was authorised work at the same time. ## Understand what a clean scan can and cannot mean A scan is a tool with a defined method and coverage. It may inspect public pages, compare files, search for known patterns or assess installed components. Ask which type was performed, what it could access and when it ran. “Scan passed” is incomplete without that context. A clean result does not prove that no attacker ever accessed the system. Some activity may leave limited traces, use legitimate accounts or fall outside the scanner’s checks. Conversely, a detection may need investigation before it can be classified accurately. A responsible review neither ignores alerts nor treats every automated label as a confirmed incident. Keep scan findings alongside other evidence, such as patch status, access records, unexplained changes and the exposure timeline. The investigator should explain how those pieces support a conclusion. If evidence is missing, the report should say so. An honest limitation is more useful than a guarantee the available records cannot justify. ## Choose specialist help when the evidence demands it Routine website maintenance and incident response are not necessarily the same service. A developer may coordinate with the host and perform application checks while a specialist investigates possible intrusion. Agree the scope before assuming that a monthly maintenance arrangement includes forensic work or continuous incident monitoring. The [NCSC guidance for this incident](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) includes assessing possible compromise where prompt update or disabling is not possible, and points to assured incident-response providers when organisations lack confidence in performing that work. Use that guidance to support an appropriate escalation decision for the actual situation. When requesting help, provide a concise summary: affected services, observations, timeline, known remediation, available evidence and immediate business impact. Ask what access is required, how information will be protected and what outputs the investigation will provide. Do not grant broad access to an unverified contact merely because the issue feels urgent. ## Coordinate containment with business continuity The incident lead may recommend restricting access, disabling affected functionality or isolating a service. The right action depends on the findings and exposure. A business owner should understand what customers will experience and which established contact methods remain available. Avoid a blanket assumption that every PHP website must be taken offline. Containment should be technically meaningful. Hiding a page or changing a menu does not necessarily disable the underlying vulnerable service. Ask the host to explain the scope of the action in plain language and record the conditions required before restoring normal operation. Keep temporary measures visible in the task list. Maintain one source of coordination. If the host, developer and business each make changes independently, they may interfere with one another’s work. A shared timeline and named incident lead help balance urgent protection, evidence preservation and service recovery without losing accountability. ## Recover from an understood state Restoration is more than making the homepage reappear. The recovery team should address the route used by the attacker where it can be established, remove or replace affected components through an appropriate process and verify the relevant security fixes. Otherwise the same problem may recur after the visible symptom disappears. Choose backups carefully. A recent backup may already contain unwanted changes, while an older one may omit legitimate orders or enquiries. The technical and business owners need to agree how records will be reconciled. Preserve evidence separately where needed before overwriting the environment. After recovery, verify critical journeys: enquiries, account access, bookings, checkout and integrations. Those functional checks support business continuity, but do not replace the incident assessment. Record the difference between restored service, completed remediation and the investigation’s conclusions about what happened. ## Keep current advisories in the response record PHP issued an additional [session upload-progress notice on 23 October](https://www.php.net/archive/2026.php#2026-10-23-1). Ask the host and developer to assess its applicability under the current guidance. A record showing completion of the original fixes should not be interpreted as an assessment of every later issue. Maintain a dated advisory list within the response record. Record who reviewed each notice and whether it changes the planned work. That avoids both repeatedly reopening resolved questions without reason and overlooking a genuinely new condition because the incident was marked complete too early. For broader planning after the immediate response, the maintenance responsibilities associated with your website should be clear. Our [web design services](https://healywebdesign.co.uk/services/web-design/) are a starting point for discussing the site and its support needs. Specialist investigation requirements should be agreed explicitly rather than inferred from a general service description. ## Report findings with the right level of certainty A useful conclusion identifies the systems examined, time period covered, evidence sources, findings and limitations. “No evidence found in the records reviewed” is a scoped finding. “Nothing could have happened” is a much stronger claim and may not be supportable. Ask for language that reflects the evidence. If customer information or other regulated data may be involved, obtain appropriate incident-response and legal advice about the circumstances. This article does not determine notification duties or deadlines for an individual business. Avoid copying a generic statement into customer communications before the facts and applicable responsibilities are understood. Close with actions, owners and dates. Separate completed remediation from remaining investigation, recovery and longer-term improvements. That gives the business a practical record of progress without requiring a misleading all-clear label. ## Frequently asked questions ### Does a PHP2Shell patch remove an existing backdoor? Do not assume so. Patching addresses the relevant vulnerability in the runtime. Existing unauthorised changes require separate assessment and remediation based on the evidence found in that environment. ### Does an attack request in a log prove compromise? No. It establishes observed activity, subject to the log’s coverage. A reviewer must assess whether it succeeded and what followed. Preserve the evidence and avoid turning an attempted request into an unsupported data-breach claim. ### What should I do first if I see an unfamiliar administrator? Document the observation and promptly contact the responsible technical or incident-response owner. Have them assess legitimacy, risk and containment while preserving relevant evidence. Avoid assuming that the account is either harmless or malicious without investigation. ### Can a clean malware scan prove the site is safe? No scan gives that universal assurance. Ask what was checked, which parts were accessible, when it ran and what limitations remain. Combine the result with the wider evidence rather than treating it as a certificate. ### Should I immediately restore the newest backup? Not without considering compromise and business records. The backup may include unwanted changes or omit later legitimate transactions. Let the recovery owner select and verify the appropriate restore approach. ### Can ordinary maintenance replace specialist incident response? Only if the agreed service actually includes the necessary expertise and scope. Clarify responsibilities. A maintainer can help coordinate evidence and suppliers while a specialist handles work beyond routine application support.