Was My PHP Website Compromised? What to Look Into After an PHP2Shell Exposure

It can be disturbing to discover that your website makes use of vulnerable PHP. At that point you might ask yourself if someone has accessed your server, altered the files, or stolen information.

The fact that PHP2Shell has been exposed doesn't mean that your website has necessarily been hacked. Moreover, the fact that you have installed an update doesn't prove that the previous exposure had no consequences.

They are different questions; one is about whether there was vulnerable software, and the other is about what actually took place when the software was accessible.

On 26th October 2026, CISA stated that CVE-2026-109618 and CVE-2026-109619, the two initial PHP2Shell vulnerabilities, had been included in its Known Exploited Vulnerabilities catalog; this provides website owners with a clear reason to check that remedial action has been taken and to consider the possibility of having been compromised earlier.

The guide outlines the way to carry out an investigation, the kinds of records that should be asked for, and how to describe the findings accurately. The information specific to each incident is based on the advisories available on October 30, 2026.

The following examples of the investigation are general advice for defensive measures and do not state that each of the listed behaviours has been observed in attacks on PHP2Shell.

Start by Separating Exposure From Compromise

A website can fall into several different categories:

Such categories serve to prevent two errors: making a decision about a breach based simply on the version number, or assuming that the system is safe since the homepage continues to function.

For example, a hosting record which shows the affected PHP package indicates that there is a maintenance problem; it does not indicate that an attacker has successfully used it.

Similarly, a website that appears normal doesn't reveal much regarding unexpected processes, accessible credentials, or activity beyond what is visible in the application.

What PHP2Shell Exposure Means

The announcement by PHP relates to vulnerabilities which may allow unauthenticated remote code execution. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed are included within the scope of the issue.

To carry out an investigation, you should determine the real PHP service which handled the requests.

Don't base your decisions solely on the version available on the developer's laptop, on a package installed somewhere else on the server, or on a label in the hosting dashboard which fails to include the patch revision.

Record:

-The website or service that is affected.

• Its hosting environment.

The PHP handler and the active package.

• It is possible that untrusted requests could get to it.
• The fixes became active.
• What is the evidence for those answers?

Make sure that the unknowns are visible, since a review is more useful if it makes its limitations clear.

What to Do First if You Suspect an Active Attack

Get in touch with the individual or group who is in charge of the hosting environment and appoint an incident coordinator.

Describe the reason for the concern. Make sure to mention the domain in question, the time involved, the behaviour that was observed, and any recent changes.

If signs of a continuing intrusion or data loss are present, the operator should prioritize containment and evidence collection should be carried out in such a way as to support that response rather than allow the harmful activity to continue indefinitely.

Do not carry out a number of separate changes while different people are carrying out investigations.

Each of a developer removing files, a host restarting services, and an owner restoring a backup has the ability to change the evidence that is available to the others.

Make it clear who has the authority to approve changes and maintain a common record of actions.

Preserve Evidence Before Broad Cleanup

A restart, a rebuild, or a cleanup procedure can eliminate information that is useful to an investigation.

The forensic guidelines issued by NIST state that volatile data from an operating system is only available while the system is still running and that the process of collecting the data can in turn affect the system's state; decisions regarding the preservation of this information therefore need to be based on a timely evaluation of the situation.

Find out from the hosting or response team what can be safely preserved before the major changes.

The kind of material that is useful will depend on the environment and might consist of the existing logs, the deployment records, the relevant snapshots, and details regarding the active processes and connections.

It would be wrong to suppose that a disk snapshot includes memory or all of the external log sources; you should find out exactly what is contained in the snapshot.

Make a record of who collected the material, when it was collected, where it came from, and where it is stored. Access should be restricted since incident records may contain confidential information.

Do not post full logs, configuration files, or database exports in public forums.

Step 1: Establish the Exposure Window

Create a timeline showing when the website was deployed and when it was remediated.

Ask:

1. What time was the PHP package that was affected deployed?
2. At what time could the service be accessed by users who were not trusted?
3. At what time were the temporary restrictions put in place?
4. When was the fixed package installed?
5. When did the running services start using it?
6. Was it the case that any earlier instances were still active?

You should not begin the investigation on the date of the public announcement. The previous deployment history might be relevant, and the disclosure date does not indicate when the attackers first tried to exploit the system.

Moreover, you shouldn't simply stop when the package has been installed. You should check when the change took effect throughout the deployment.

When the exposure window is still uncertain, you should record that uncertainty and the records required to make it narrower.

Step 2: Identify Available Records and Their Limits

Before you look for any suspicious activity, first establish what evidence there is.

A practical inventory might look like this:

What processes and file operations were observed in the host or at the endpoint?

The logging advice from OWASP focuses on application events, useful event attributes, and the need to protect logs; web access logs and application logs have different purposes and therefore one should not be taken as a substitute for the other.

For every source, record the retention period, time zone, coverage, and the gaps.

Turning on extra logging at this time might enhance future visibility, but it won't be able to reproduce events from the past that were never logged.

Step 3: Review Requests Alongside Server Behavior

While request logs can give rise to leads they seldom tell the entire story.

Search for any activity that is different from the kind of use the website usually has and check it in conjunction with other records.

For instance, a possible sequence could involve unusual requests, a worker failure, and an unexpected process event all occurring in close proximity.

The sequence warrants more attention than does any single event considered by itself.

Yet an error does not prove that the code has been executed. A successful HTTP response doesn't show that the attack has either succeeded or failed. The fact that a request has been blocked at one layer does not mean that all routes to the backend have been blocked.

You should also think about whether the recorded client addresses identify the original client or an intermediary, and the request tracing must take into account the actual proxy configuration.

Take what the records show rather than deciding what they mean.

Step 4: Investigate Unexpected Processes and Connections

It is recommended by the Canadian Centre for Cyber Security that unexpected processes, commands, files, accounts, and outgoing connections linked to PHP or web-server services should be investigated.

Have the response team compare the behaviour that has been observed with that of the application under normal conditions.

Relevant questions include:

• Was an unfamiliar program launched by a web-service worker?

Was that action carried out as part of an approved job or integration?

• Were the connections directed to the places that the application usually uses?
• Do the process, request, and connection records all follow the same timeline?

Certain valid applications invoke external tools. The fact that a child process exists should not be enough to reach a conclusion.

On the other hand, evidence from the historical process can be important even if no suspicious process is still active at the time of the review.

Make it clear that something is not running at the moment as opposed to having never run.

Step 5: Compare Files With a Trusted Baseline

Check the changes in the file against the approved deployments, application packages, and the known-good source.

Request that the person in charge should explain any unexpected additions or changes.

You should focus on the areas where the application has the right to write files, as well as on the executable code and the configuration.

A file which has recently been discovered isn't automatically malicious, and a recent modification time doesn't prove when an attacker carried out their actions, nor does an old timestamp prove that the file can be trusted.

Take the content, the provenance, the permissions, the deployment history, and the surrounding activity into account together.

You should not carry out an unfamiliar PHP file just to find out what it does; instead, any suspicious material should be examined via the response team's controlled process.

Do not delete it until the team has decided which evidence to keep.

Step 6: Review Accounts and Ways to Maintain Access

The investigation needs to look into whether unauthorized access could still take place after the initial vulnerability has been patched.

Check the application accounts, the hosting access, the service configuration, the scheduled tasks, and the administrative credentials.

Compare the changes with those in the approved requests and with the normal maintenance activity.

Ask:

• Were accounts that were unfamiliar created?
• Has there been any change to the existing permissions?

— Did tasks that were scheduled appear without an owner?

• Were the credentials for deployment or hosting used by accident?

— Was there a change to the configuration outside of the usual release process?

These are general investigation questions and not specific signatures for PHP2Shell.

What we want to do is to evaluate the level of trust within the affected environment, not to eliminate a single suspicious file and then consider the job finished.

Step 7: Assess Accessible Data and Credentials

Find out what the affected process was able to access and what evidence indicates that it actually did access it.

Those are separate questions.

For example, a hypothetical application might have credentials which allow it to access a customer database. This raises a question for impact assessment; it does not prove that the customer records have been stolen.

Look through the database activity, storage access, integration usage, and network records where they are available.

Make it clear that there are limitations regarding the evidence. In some cases the system will not record enough details to verify each read operation.

An investigation report should distinguish:

• Resources potentially accessible.
• Access directly observed.
• Changes directly observed.
• Evidence showing that information has left the environment.
• Questions that remain unanswered due to the missing records.

Do not treat uncertainty as if it were a guarantee of safety or as a statement of theft.

Step 8: Build a Timeline With Confidence Levels

Put the findings in a timeline.

When giving examples, label them as examples.

You should distinguish between having confidence in an observation and having confidence in the explanation it receives; a log can reliably show that a process took place while still leaving the reason uncertain.

Before treating events as if they occur at the same time, you must take into account any differences in time zones and with regard to clock discrepancies.

A clear timeline usually shows which further record would answer an important question.

What a Clean Scan Cannot Prove

The security scan itself gives information based on the scope and ability of the tool to detect flaws.

One cannot automatically conclude that there was no unauthorized execution, that no accessible secret was disclosed, or that no suspicious activity took place before the scan.

Find out what the tool looked at and which evidence sources were beyond its scope.

Similarly, a review that finds no suspicious items should indicate the scope of its coverage.

A useful conclusion might say:

No signs of compromise were found in the records that were reviewed. The assessment included the systems and dates in question, and the following logging gaps were identified.

That gives more information than an assertion that the whole environment had never been hacked.

Verify Patching Separately From Investigation

The PHP releases that include the two original fixes are 8.5.12, 8.4.27, 8.3.36, and 8.2.35; furthermore, its announcement recommends that people check the distribution and long-term support vendors for updated packages.

Consider those to be reference points specific to each incident and then review the subsequent relevant releases.

Request that the operator check the current runtime across the relevant workers, containers, and instances.

Keep two outcomes separate in the incident record:

• It was checked that runtime protection was in place.
• The earlier compromise was evaluated in accordance with the scope that had been stated.

You don't replace one with the other.

What to Do if Compromise Is Confirmed

Have the incident lead coordinate the containment, remediation, credential review, and recovery.

Determine which credentials and tokens need to be replaced and carry out the sensitive recovery procedures from a trusted environment. Also consider if active sessions or any other access methods need to be cancelled.

The incident-response guidelines issued by NIST suggest that restoration assets should be checked to see if they have been compromised or corrupted and that the systems that have been recovered should be verified before they are used in a production environment. It also stresses the importance of confirming that essential services are operating and of keeping an eye on the restored operations.

A recent backup should therefore be examined rather than being automatically trusted.

When it comes to material compromise, one should consider whether it is more defensible to rebuild the system using known-good components than it is to try to clean the system which is currently in place.

Make sure that the business stakeholders are kept up to date with regard to the confirmed impact and any unresolved questions. The relevant organizational advisers should assess whether there are any reporting or notification duties.

What to Ask Your Hosting Provider

Send a specific request:

It is possible that my website came into contact with CVE-2026-109618 and CVE-2026-109619. Could you please let me know when the appropriate fixes for PHP were put into action? I would also like you to keep any available records and to explain whether your team is able to evaluate the possibility of an earlier breach. Please specify the systems involved, the time period in question, the sources of the evidence, and the limitations of that assessment.

Make it clear whether the provider's review includes the underlying server or only the files in your account.

Ask for a written result and tell the difference between an investigation that has been completed and one that is merely a support ticket confirming the installation of a patch.

PHP2Shell Investigation Checklist

• Assign an incident coordinator.
• Deal with the signs of actively harmful behaviour.
• Arrange for the preservation of evidence before carrying out a wide-scale cleanup.
• Determine the likely exposure period.
• Find the available records and identify any gaps in the logging.
• Match requests to the behaviour of the host and the application.
• Look over any unexpected files, accounts, tasks, and connections.
• Evaluate the available resources and the confirmed impact independently.
• Check runtime fixes in every deployment.
• Record the findings, the level of confidence, the limitations, and the further work to be carried out.

Frequently Asked Questions

Will the use of a vulnerable version of PHP show that my website has been hacked?

Far from it; it sets up a concern regarding vulnerability, since successful compromise would need supporting evidence.

Should I restart the server right away?

Talk to the operator; in the case of active harm there may be a need for immediate action, whereas a restart can eliminate volatile evidence. The response team should achieve a balance between containment and preservation.

Should I get rid of the suspicious files?

Make sure that relevant evidence is preserved and have the response team examine the files before carrying out extensive cleanup.

Does changing passwords eliminate an attacker?

It doesn't have to be the case; coordination is required between the replacement of credentials and the containment and remediation of the other access paths.

Can the absence of logs prove that nothing had happened?

The fact that some records are missing means that the investigation cannot reach any definite conclusions. It is important to clearly document these limitations.

Can I determine the exact CVE from a PHP crash?

Just having an accident is not enough; supporting evidence is required both for the cause and for the security outcome.

Aim for a Defensible Answer

The question of whether my PHP website has been hacked doesn't have an immediate yes-or-no answer.

A useful investigation will show what has been revealed, what evidence is available, what took place, and what is still uncertain.

Keep records, co-ordinate any changes, check that the fixes have been properly implemented, and describe the findings together with their practical limitations. This in turn provides website owners with a more solid basis for making recovery decisions and for future maintenance.

Sources

1. PHP security advisory: CVE-2026-109618 — RCE via OOM corruption.
2. PHP security advisory: CVE-2026-109619 — RCE via stale global state.
3. CISA: Known Exploited Vulnerabilities Catalog.
4. CISA bulletin: October 26, 2026 KEV additions.
5. Canadian Centre for Cyber Security: AL26-026 — Critical vulnerabilities impacting PHP.
6. NIST: SP 800-61 Rev. 3 — Incident Response.
7. NIST: SP 800-86 — Integrating Forensic Techniques into Incident Response.
8. OWASP: Logging Cheat Sheet.