Was My Site Hacked Through PHP2Shell? Signs to Check and What to Do

As of 23 October 2026, security firms report widespread attempts to exploit PHP2Shell (CVE-2026-109618 and CVE-2026-109619), but no successful compromises have been publicly documented, and no official indicators of compromise have been published. So you can't run a single check that proves your site was or wasn't hacked. You can look for the warning signs that security firms have named, starting from at least 17 October 2026.

Most sites that were probed will show nothing worse than failed requests. watchTowr, quoted by SecurityWeek, says the exploits being sprayed around "either don't work at all, test for timing-based differences, or crash the target." But a quiet log is not a clean bill of health. Bitdefender warns that "A successful exploit can return HTTP 200 and leave the worker running."

This guide covers what to look for, from simple signs any owner can spot to the technical checks for your developer or host, plus what to do if you find something.

What Is Known About Attacks So Far

This is a moving story, and reports differ. As of 23 October 2026:

• Amazon says it found "a PHP2Shell exploitation attempt dating to Oct. 17, 2026," four days before public disclosure, and later that PHP2Shell "is now seeing broad exploitation attempts in the wild." Amazon added that "it's unclear if any of these attempts would have succeeded in real-world systems."
• Cloudflare says it "observed attack traffic targeting our customers," and watchTowr says it has seen exploitation in its honeypots since 21 October.
• Bitdefender said on 22 October that its telemetry "shows no PHP2Shell exploitation attempts." CISA's alert said CISA had not observed exploitation at the time of publication, and as of 23 October 2026 neither CVE was listed in CISA's Known Exploited Vulnerabilities catalog.

For the dated, sourced record, see our PHP2Shell exploitation status tracker.

How Far Back to Look

Amazon's advice is direct: "Start investigations from the earliest known exploitation, not from the disclosure date. For PHP2Shell, investigate from at least starting on October 17th." Bitdefender also says "Start the lookback at 2026-10-17."

The Sophos advisory goes further for one check. It suggests reviewing "successful administrative logins to affected applications since August 1, 2026," which covers the months when the flaws were known privately. If your logs don't go back that far, note the gap. Servers often delete old logs on a schedule, so copy them now.

Signs Any Site Owner Can Check

You don't need server access for these. They don't prove PHP2Shell specifically, but they are reasons to dig deeper.

• Admin logins you don't recognize. Sophos names successful admin logins since 1 August 2026 as something to review. In WordPress and most CMSs, check the user list and any login history your security tools keep.
• Admin or user accounts nobody created. watchTowr says to check for "newly created accounts tied to PHP processes."
• Bursts of errors or outages. Wiz and Beazley name repeated HTTP 500 responses after unusual requests. If visitors or your uptime monitor reported "500 Internal Server Error" pages since 17 October, ask your host about them.
• Files or content that changed without explanation. Sophos names "newly created or modified PHP files that may indicate web shells." A web shell is a file an attacker plants to control the server later.
• The usual signs of a hacked site. Spam pages, redirects, browser warnings or a host suspension notice. Our guide to checking whether your website has been hacked covers these.

Technical Signs for Your Developer or Host

These are the behavioral signals named in public advisories. None is an official indicator of compromise. Where each one shows up depends on what your server logs.

For a file check, a generic illustration (not a PHP2Shell indicator) is a command that lists PHP files changed since 17 October. Change the folder to your own web root:

find /var/www -name "*.php" -newermt "2026-10-17"

Updates to plugins, themes and the CMS will show up too, so compare the results against what you know you changed.

How to Read What You Find

The signals are not equal. Treat them like this:

• Crash and memory errors mostly measure attempts. Bitdefender says: "Crash logs measure attempts, not compromises." A burst of memory errors tells you someone tried. It does not tell you they succeeded.
• A worker that starts a shell is the strongest sign. Datadog says: "A web worker that spawns a shell is the most direct evidence of successful exploitation." Unexpected new PHP files and new cron jobs come close behind.
• No signs is not the same as safe. php2shell.com, the researchers' site, says the signals "do not establish exploitation on their own. Their absence does not establish that a system is unaffected." It also warns that some attacks "can disclose sensitive memory without executing malicious code on the server."
• Logs may be incomplete. The CVE-2026-109619 advisory notes that historical logs may have excluded relevant messages and that "A failure may also happen before PHP writes the message."

That memory disclosure point matters. Wiz says leaked memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself." Beazley's advice is to "treat secrets held by an affected PHP process as potentially exposed" when signs appear.

About Published IP Addresses and "Exploit Checkers"

Amazon published six IP addresses tied to the attempts it saw. Read its caveat before you use them. Amazon says they "include shared anonymization infrastructure and are not exclusive to this threat activity. Organizations should investigate any observations involving these addresses as opposed to blocking." If one appears in your logs, look at what that request did. Don't treat a match as proof, and don't treat no match as safety. The list is in Amazon's PHP2Shell post.

Be careful with tools claiming to test your site. Bitdefender reports that some GitHub repositories claiming to host PHP2Shell proofs of concept are pranks, and says: "Treat every unofficial PoC as untrusted code." Never run a downloaded exploit or "checker" script on your server.

What to Do If You Find Signs

1. Preserve evidence first. Beazley says to "Preserve web, PHP, application, and host logs before restarting or rebuilding a suspect system." Copy logs somewhere off the server. Don't delete suspicious files yet; note their names, paths and dates.
2. Contain. If you can't patch right now, restrict access. Beazley advises using "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials." Our interim mitigations guide covers what helps in the meantime.
3. Patch and restart. Install a fixed build from our PHP2Shell fixed versions list and restart every PHP worker.
4. Investigate from 17 October onward, using the signals above. Bring in your host or a security team if you see shells, unknown files or new accounts.
5. Clean or rebuild. If the server shows signs of compromise, rebuilding from a known-good state is usually safer than hunting for every planted file. Our guides to removing malware and backups and recovery explain the trade-offs. Pick a backup from before the suspected intrusion.
6. Rotate secrets. Bitdefender says to "rotate the secrets the PHP process could read: application database credentials, API keys in environment variables or configuration files, and cloud credentials present on the host." Also reset admin passwords and sign out all sessions.
7. Monitor. Bitdefender suggests continued "alerting on child processes of web workers." Watch your logs, file changes and admin accounts for the following weeks.

For the first hour of any incident, our website incident response plan gives a step-by-step checklist, and Website Hacked? Start Here covers the basics.

Do You Need to Notify Anyone?

It depends on what data your site holds, where your users are and what your contracts say. If customer or resident data may have been exposed, including passwords or payment details, talk to a lawyer about notification duties before you contact anyone else. Government organizations should also follow their own incident reporting rules. This section is general information, not legal advice.

Conclusion

As of 23 October 2026, PHP2Shell attempts are widespread, confirmed compromises are not publicly documented, and there are no official indicators of compromise. Patch first, then review your logs and files from at least 17 October for the behavioral signs security firms have named. Treat a PHP worker spawning a shell, unknown PHP files or new accounts as serious, and remember that clean logs are not proof. If you find something, or want a second pair of eyes, our website security team can help you investigate and recover. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions