A back door left on your site? A web shell self-check
Patched PHP but worried someone got in first? Save your logs today, check users, files and scans yourself, and know what to do before deleting anything.
By Jeensuk Yang
PHPFree · Web security · Fix series 03
?Who this is for
- PHP is patched, but you wonder whether someone got in before that
- You can't log into your server, but you want to check what you can
- You found a strange file and aren't sure whether to delete it
!What you'll learn
- What a web shell is, and why patching PHP doesn't remove one
- The one thing to do today, and what you can check yourself
- Where to hand off to an expert, and what to do before deleting anything
What if someone copied a key before you changed the lock?
Patching PHP replaced a broken lock. But if a burglar came by before that, there may be a hidden back door somewhere in the house. I'm not saying this to scare you. Most owners can't see deep inside a server, and don't need to. This article draws the line between what you can check yourself and what to hand to an expert.
What is a web shell, and why does it survive a PHP patch?
A web shell is a file an intruder hides on your server so they can control it from outside. Patching PHP closes the way in, but files already planted don't disappear on their own.
CISA, the US cybersecurity agency, defines it this way: "A web shell is a script that can be uploaded to a web server to enable remote administration of the machine." With one, an attacker can add, delete and run files and harvest data such as passwords.1
Closing the vulnerability does not remove persistence or malicious code already present. — ThreatLocker, Oct 21, 2026
Think of your house. Once you change the lock, the old key won't open the front door. But if the burglar cut a small side door by the backyard before that, the new lock knows nothing about it.2
- Save the logs: download your access logs from your hosting dashboard today
- Check the dashboard: look at WordPress's user list and Site Health screen
- Check file dates: in the file manager, look for PHP files that are new or recently changed
- Use the official scan: turn on the scanner your host provides
- If something's off: record it before deleting anything, and contact your host and an expert
Step 1 can't wait: logs disappear over time. The rest can follow once step 1 is done. This checklist is as of October 25, 2026.
Jeensuk's takeA self-check isn't a certificate of safety. It's a search for warning signs. If you find one, call an expert. If you don't, change the keys anyway.
What's the first thing to do today?
Download your access logs from your hosting dashboard to your own computer. Logs are deleted after a set period.
A shop's security camera records over old footage after a few days. If you want to see what happened, you have to copy the footage before it's overwritten. Your server's access log (the visitor record of who came to which address, and when) works the same way. TechTarget's advice: "Preserve all server logs from Oct. 20 onward before restarting or rebuilding servers."3
How long logs are kept varies a lot by host.
| Host | Logs you can get |
|---|---|
| Kinsta | Sites → your site → Logs. Kept "for up to 4 days"; save them through the File Manager or over SFTP from the logs folder4 |
| SiteGround | Site Tools shows the latest 300 entries; earlier files go back "up to 30 days" in the domain's logs folder5 |
| Bluehost | cPanel → Raw Access. Logs are archived only if you tick the archive box, and a second box deletes last month's logs at the end of every month6 |
WordPress.org also says the first step after a suspected hack is documentation: what you're seeing, when you noticed it, and what you changed recently.7
Jeensuk's takeYou don't have to read the logs now. Just download them, and an expert can read them later. Logs belong to whoever saves them.
What can you check without logging into the server?
Your WordPress dashboard, your host's file manager, the logs you downloaded, and your host's official scanner.
You can take your temperature without going to the hospital. A thermometer won't name the illness, but it tells you whether to go. The checks below are thermometers.
- User list: look for admin users you don't recognize. WordPress.org lists "creation of new users" among clear signs of a hack.7
- Site Health: under Tools → Site Health → Info, review the installed plugins, themes and user count. It's read-only, so looking changes nothing.8
- File dates: in the file manager, look at modified dates. A PHP file in the uploads folder (
wp-content/uploads), or recently changed PHP files or.htaccess, is a warning sign. WordPress.org singles out.htaccess,index.php,header.phpandfooter.phpas files to watch.7 - Access logs: look for unusual file-upload requests (multipart requests) followed by memory errors or repeated HTTP 500 errors.9
- Official scanners: Hostinger's Malware Scanner (Websites → Dashboard → Malware Scanner) checks files automatically on its Web and Cloud Hosting plans.10 WordPress.org also lists established scanners such as Wordfence and Sucuri, and remote checkers such as Sucuri SiteCheck.7
Jeensuk's takeIf you see something you don't understand, stop there and take a screenshot. A self-check's job is to notice, not to judge.
What's hard to check on your own?
Programs running inside the server right now, files the file manager doesn't show, and traces left in memory. On shared hosting, a regular account can't see these.
CISA says to watch for "PHP worker processes launching shells or downloading tools."11 CybelAngel adds unexpected child processes of the web server and unusual outbound connections, and suggests looking back to at least June 2026.12 Not seeing something in the file manager doesn't mean it isn't there.
| You can do | Leave to an expert |
|---|---|
| Download access logs | Check running processes and outbound connections |
| Review users and Site Health | Investigate session files and request contents |
| Check file dates, take screenshots | Preserve memory evidence, trace how they got in |
| Turn on your host's scanner | Decide on deletion, rebuild or restore point |
Jeensuk's takeYou don't have to see everything yourself. Your job is to protect the records and decide who to hand this to.
If you find a suspicious file, should you delete it right away?
Don't delete it yet. Record it, protect the logs, and contact your host first. Then clean up.
At a crime scene, you take photos before you clean. Once it's cleaned, there's no way to tell how they got in, and they can come back the same way.
The guidance differs a little. CISA's 2015 alert says to "simply delete the file from the server" once a web shell is found.1 ThreatLocker says that if compromise is suspected, isolate the system, preserve evidence and rotate exposed credentials,2 and WordPress.org recommends taking "one more snapshot of the environment" before cleaning.7 So this article puts it in this order:
- Record: write down what you saw and when, and take screenshots.7
- Preserve: download the logs and take a backup snapshot, even of the infected site.3·7
- Contact your host: on shared hosting, other sites on the same server may be affected.7
- Report: in the US, you can report to the FBI's Internet Crime Complaint Center (IC3), "the central hub for reporting cyber-enabled crime," and to CISA at cisa.gov/report.13·14
- Clean up: then delete, rebuild or restore from a backup taken before the break-in.
- Change the keys: change database, admin, FTP/SFTP and hosting passwords and API keys, and change them again once the site is clean.2·7
Jeensuk's takeDeleting takes five minutes, and you can't undo it. Hurry to save the records. Take your time with deleting.
Should you use the "checker scripts" going around online?
It's better not to run scripts from sources you don't know. Something that looks like a checker can become a new way in.
A study of GitHub proof-of-concept repositories found that about 2.5% may be malicious.15 You wouldn't try a stranger's "master key" on your own front door. Use your host's official scanner, or established tools that WordPress.org points to.7
Jeensuk's takeWhen you're anxious, "fix it fast" is tempting. Pausing for a moment is the best security there is.
Frequently asked questions about self-checking for web shells
If my self-check finds nothing, am I safe?
You can't be sure. A clean file scan doesn't rule out problems in the database, so change your passwords and API keys anyway.
If there's a PHP file in my uploads folder, was I hacked?
It's a warning sign, but not proof on its own. Don't delete it; take a screenshot and ask your host or whoever built the site to look.
I'm on Kinsta. What should I do first?
Save the logs you can get today. Kinsta keeps them for up to four days, so ask support right away if you need older records.
SOURCES
- CISA, "Compromised Web Servers and Web Shells - Threat Awareness and Guidance" (TA15-314A, Nov 10, 2015; revised Aug 9, 2017) cisa.gov
- ThreatLocker, "PHP2Shell: Why organizations must patch critical PHP vulnerabilities now" (Oct 21, 2026) threatlocker.com
- TechTarget, "PHP2Shell: 22M exposed servers at risk as emergency patches released" (Oct 21, 2026) techtarget.com
- Kinsta Docs, "Server Logs" (updated Jun 19, 2026) kinsta.com
- SiteGround, "How to Find the Raw Access Logs for my website?" (updated Apr 22, 2026) siteground.com
- Bluehost, "How to Access and Configure Raw Access Logs in cPanel" (updated Nov 9, 2025) bluehost.com
- WordPress.org, "FAQ My site was hacked" (updated Jul 26, 2026) wordpress.org
- WordPress.org, "Site Health screen" (updated Jul 12, 2026) wordpress.org
- Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet" (Oct 21, 2026) wiz.io
- Hostinger, "How to use the Malware Scanner at Hostinger" (updated Oct 19, 2026) hostinger.com
- CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (Oct 21, 2026; revised Oct 23) cisa.gov
- CybelAngel, "2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming: What We Know About php2shell" (Oct 21, 2026) cybelangel.com
- FBI, "Internet Crime Complaint Center (IC3)" ic3.gov
- CISA, "Report a cyber issue" cisa.gov
- El Yadmani et al., "SecurePoC: A Helping Hand to Identify Malicious CVE Proof of Concept Exploits in GitHub" (USENIX WOOT '25) usenix.org
The fix guide covers the whole order; each article goes into one step. More English editions are on the way.
- PHP vulnerability fix guide: from checking to moving off PHP (coming soon)
- White screen after a PHP upgrade? How to fix and roll back (coming soon)
- Where to check and change your PHP version, host by host (coming soon)
- A back door left on your site? A web shell self-check (this article)
- Moving WordPress to a static site: how and what it costs (coming soon)
To understand what went wrong, start with risk series part 1, "What is PHP2Shell?" More articles on the ATATAKAI Digital blog.
Want fewer doors to guard?
Enter your site address and we'll tell you right away whether it runs on PHP and where your host stands. If you're not affected, we'll say so plainly: "No need to move right now."
Run the free 30-second checkWant to talk it through after you see the result? Contact ATATAKAI Digital
Updated Oct 26, 2026
