PHP Web Shell Attack Explained: How to Spot and Remove One

A PHP web shell attack is when someone uploads a small PHP file to a web server and then uses it, from an ordinary browser, to run commands, read files and plant more malware on that server. It usually gets in through an upload form that accepts any file, an outdated WordPress plugin or theme, or a stolen admin or hosting password. The giveaway is almost always a .php file sitting somewhere it has no business being, like an images or uploads folder, often with a random name and a recent modified date.

If you run a website, manage a small company's hosting, or you're studying for a security or IT support job, this is one of the most common things you'll actually run into. Here's how it works, how to check for it, and what to do in the first hour if you find one.

What is a PHP web shell?

A web shell is a script that gives a remote person a control panel for a server through the website itself. PHP is the language behind a huge share of websites (WordPress, many shared hosting plans, older custom sites), so PHP web shells are the most common kind you'll see.

Some are a single line hidden inside a normal-looking file. Others are full file managers with a login page, a file browser and a command box. Either way, the attacker doesn't need your SSH password anymore. They just visit a URL like yoursite.com/wp-content/uploads/2026/10/thumb.php, and the server does what they ask, with the same permissions your website has.

That's why it's serious. With those permissions an attacker can usually:

• Read your config files, including database passwords
• Change your pages to redirect visitors to scam or gambling sites
• Upload more shells so deleting one doesn't kick them out
• Send spam from your server, which gets your domain blacklisted
• Use your server to attack other sites

How does a web shell get onto a server?

The attacker has to write a PHP file somewhere the web server will run it. The usual doors:

1. An upload form that trusts the file. A "send us your resume" or "upload a profile photo" form that checks only the file name, or nothing at all, will happily accept photo.php. Some attackers use tricks like photo.php.jpg or a fake image header to slip past weak checks.
2. An outdated plugin, theme or CMS. Many WordPress compromises trace back to a plugin with a known vulnerability that nobody updated. "Nulled" (pirated) premium themes and plugins are worse, because some come with a backdoor already inside.
3. Stolen or weak passwords. A reused admin, FTP or cPanel password gives the attacker a legitimate way to upload anything.
4. A vulnerability in the code itself. Custom PHP that builds file paths or commands from user input can let someone write a file or include one from elsewhere.

On shared hosting, one compromised site can sometimes affect other sites on the same account, which is why a client's cheap "all my sites on one plan" setup is a common place to find these.

What are the signs of a PHP web shell?

You usually notice the damage before you notice the file. Common symptoms:

• Visitors (especially on mobile or from Google) get redirected to a site you don't own
• Google Search Console warns about hacked content, or search results show pages in a language you never published
• Your host suspends the account for sending spam or using too much CPU
• New admin users appear in WordPress that nobody created
• Files you didn't touch have a modified date from the last few days

When you go looking, the file itself tends to have a few tells:

• A .php file inside uploads, images, cache or tmp folders, where only images and documents should be
• A random or almost-legit name, like wp-1ogin.php, class-cache.php in the wrong folder, or x.php
• Long unreadable strings, because the code is hidden with base64_decode, gzinflate, str_rot13 or similar
• Functions that run commands or code: eval, assert, system, shell_exec, passthru, exec, popen, proc_open
• Code that reads input straight from the request, like $_POST, $_GET, $_REQUEST or $_COOKIE, and passes it to one of those functions

None of those prove a file is malicious on its own (legit plugins use some of them), but a combination in an uploads folder almost always is.

How do you check a server for web shells?

If you have SSH access, you can do a first pass in a few minutes. Run these from your website's root folder. They only read files, they don't change anything.

Find PHP files modified in the last 7 days:

find . -name "*.php" -mtime -7 -type f

Find PHP files inside folders that should only hold uploads (adjust the path for your site):

find ./wp-content/uploads -name "*.php" -type f

Search for the most common suspicious patterns:

grep -rlE 'eval\(base64_decode|eval\(gzinflate|shell_exec\(|passthru\(|assert\(\$_(POST|GET|REQUEST)' --include='*.php' .

Then look at your web server's access log for POST requests to odd PHP files. On many Linux servers that's /var/log/nginx/access.log or /var/log/apache2/access.log, and on cPanel there's a raw access log viewer. A file in your uploads folder getting POST requests from the same few IP addresses is a strong signal.

No SSH? A security plugin like Wordfence can scan a WordPress site, and most hosting panels have a malware scanner (often ImunifyAV on cPanel hosts). Treat a clean scan as "nothing obvious", not "definitely clean".

What should you do if you find one?

Don't just delete the file and move on. If an attacker had a web shell, assume they also had time to plant others, add users and read your passwords. A calm first hour looks like this:

1. Take a copy before you change anything. Download the suspicious file and note its path, size and modified time. You'll want this to work out how they got in.
2. Put the site in maintenance mode or take it offline if it's redirecting visitors or sending spam.
3. Change every password: hosting panel, FTP/SFTP, SSH, database, CMS admins and email accounts tied to the site. Do it from a clean computer.
4. Find the way in. Check the access log for the first request to the shell, then look at what happened just before: an upload request, a plugin URL, a login. Fix that door, or the shell comes back.
5. Restore from a known-good backup made before the first sign of compromise, or reinstall the CMS and plugins fresh from official sources and copy back only your content.
6. Update everything and remove plugins and themes you don't use.
7. Watch it for a few weeks. Re-run the checks above and keep an eye on Search Console and your host's alerts.

If the site handles customer data, payments or anything regulated, bring in the hosting provider's security team or a professional, and check whether you have a duty to report the breach. In the Philippines, the National Privacy Commission (privacy.gov.ph) has guidance on personal data breaches. Confirm the current rules there rather than guessing.

How do you prevent PHP web shells?

Most of this is boring maintenance, which is exactly why it gets skipped.

• Update your CMS, plugins and themes, and delete the ones you don't use
• Never install nulled themes or plugins, no matter how much they cost legit
• Block PHP from running in upload folders. Your host or an .htaccess/nginx rule can make the server treat files there as downloads, not code
• Check uploads properly: allow only the file types you need, check the real file type, rename files on upload and store them outside the web root if you can
• Use unique, long passwords and two-factor authentication for hosting, CMS and email
• Give the website the least access it needs. The web server user shouldn't be able to edit its own core files
• Keep backups off the server, and test that a restore actually works

Is this the kind of thing an IT job will ask you about?

Yes, more often than people expect. In a SOC, a Tier 1 analyst might get an alert for a suspicious file write or odd POST traffic and be expected to triage it. In IT support or as a junior sysadmin, you might be the person a manager calls when "the website is showing a casino". In interviews for security, support and web roles, "how would you check if a website was hacked?" is a fair question, and walking through the steps above calmly is a strong answer.

You can learn the investigation side for free. TryHackMe and Hack The Box have beginner rooms on web shells and log analysis, and the OWASP website explains the upload vulnerabilities behind most of these attacks. For the bigger picture of starting in security, read our beginner guide to a cybersecurity career in the Philippines.

Most people don't land in a SOC on day one, though. The usual route goes through IT support or helpdesk or network support first. That's the part the Career Shifter Track is built around: picking the right first role, a resume a coach marks up line by line, a portfolio project you can talk about, and two mock interviews where you practice answers like this one out loud before a real panel hears them. You can try the free preview lessons first, no account needed, or start with the free IT Job Starter Kit.

Frequently asked questions

What is a PHP web shell in simple terms?

It's a small PHP file an attacker puts on a web server so they can control that server from a browser. Once it's there, they can run commands, read files and change the website with the same permissions the site has.

Can a website be hacked through an upload form?

Yes. If an upload form doesn't check what kind of file it receives, an attacker can upload a PHP file instead of an image or document and then open it in a browser to run it. Allowing only specific file types and blocking PHP from running in upload folders closes that door.

Is deleting the web shell file enough?

Usually not. Attackers often leave more than one backdoor, add admin users and copy passwords. Change all passwords, find and fix how they got in, and restore from a clean backup or reinstall from official sources.

How do I check if my WordPress site has a web shell?

Look for PHP files in the uploads folder, recently modified PHP files and code with eval and base64_decode, then run a scan with a security plugin like Wordfence or your host's malware scanner. Check your access logs for POST requests to unfamiliar PHP files.

Do I need to know PHP to work in cybersecurity?

Not to start. Reading a little PHP helps when you investigate web attacks, but entry-level security and IT support jobs care more about networking, operating systems, logs and a clear process. You can pick up enough PHP to recognize suspicious code as you go.