A PHP shell is a malicious script that can give an attacker remote control over parts of a compromised website. Depending on its capabilities and permissions, it may allow someone to run commands, upload or modify files, steal data, create hidden administrator accounts, redirect visitors, or install additional malware.

PHP shells are not limited to one platform. They can be planted in Magento or Adobe Commerce, WordPress, custom PHP applications, upload directories, writable cache folders, or other locations accessible to the web server. A suspicious file is a warning sign—not proof by itself—so investigate it carefully before deleting anything.

Important: If you believe a live site is compromised, preserve logs and a snapshot first, restrict access where practical, and involve your hosting provider or a qualified incident-response professional. Removing one file without finding the original entry point may leave the attacker with another way back in.

What is a PHP shell?

A PHP shell is a script that exposes powerful server-side functionality to an unauthorized user. It may be disguised as an image, a cache file, a plugin, a normal-looking PHP file, or code injected into a legitimate file. Some backdoors are tiny; others are heavily obfuscated.

Common warning signs

• Unexpected PHP files appear in media, image, cache, upload, or temporary directories.
• Files change even though nobody deployed code or updated the site.
• New administrator accounts, API tokens, cron jobs, or scheduled tasks appear without authorization.
• The website redirects visitors, injects spam or unfamiliar JavaScript, or sends unexpected email.
• CPU usage, outbound connections, or PHP worker activity suddenly increases.
• Security scanners report obfuscated code, web shells, suspicious file uploads, or modified core files.
• Access logs show unusual requests followed by newly created files or unexpected PHP execution.

None of these indicators alone proves a shell is present. Legitimate plugins and applications may also contain encoded strings or generate PHP files. Compare findings with a trusted source and investigate context.

Step 1: Contain the incident before cleaning

1. Preserve evidence. Save a snapshot of the affected files and database, plus web-server, PHP, SSH/SFTP, control-panel, and application logs. Keep a copy offline and record the time and time zone.
2. Limit exposure. If the site is actively harming visitors or leaking data, put it into maintenance mode or restrict access at the web server or firewall. Do not destroy logs or immediately wipe the server.
3. Contact the host. Ask whether other sites under the same account or server may be affected and request relevant access, authentication, and process logs.
4. Use a clean device. Change credentials from a trusted computer, not a workstation that may itself be infected.
5. Assess data exposure. Determine whether customer records, passwords, order data, payment integrations, or API credentials may have been accessed. Follow applicable notification and compliance requirements.

Step 2: Find suspicious files safely

Start with files changed around the time the incident began. Review web-server access logs and compare the production code against a trusted Git commit or official release package. Search for unexpected files in writable directories and inspect changes to entry-point files, configuration files, themes, plugins, and server rewrite rules.

# Review recently modified PHP files (adjust path and time window)
find /path/to/site -type f -name '*.php' -mtime -7 -print

Find PHP-like files in a directory intended for uploads
find /path/to/site/public/uploads -type f \
  \( -iname '.php' -o -iname '.phtml' -o -iname '*.phar' \) -print
Search for high-risk patterns for manual review
grep -RInE 'eval[[:space:]]\(|base64_decode[[:space:]]\(|gzinflate[[:space:]]\(|shell_exec[[:space:]]\(|passthru[[:space:]]\(' \
  /path/to/site --include='.php'

Use these commands as triage, not as a verdict. They may return legitimate code, miss obfuscated malware, or scan generated/vendor files. Review results with file ownership, timestamps, hashes, logs, and a trusted clean copy. Avoid posting secrets or customer data into public scanning services.

Step 3: Clean a Magento or Adobe Commerce store

1. Check the exact version and security advisories. Apply the latest supported security patches for that release and review Adobe's current security bulletins.
2. Compare application code with trusted sources. Restore Magento core files from the correct official release and redeploy custom code from a reviewed repository. Do not overwrite custom modules blindly; inspect them for unexpected changes.
3. Inspect writable directories. Review pub/media, import/export locations, generated content, and other writable paths for executable files. Check upload locations used by custom options and extensions.
4. Prevent script execution in uploads. Configure the actual Nginx/Apache and hosting rules so user-upload directories cannot execute PHP. Test the rule on the deployed server; a rule in the wrong directory or virtual host may not apply.
5. Audit admin and integration access. Remove unknown administrator accounts, review admin action logs, rotate admin credentials, API/integration tokens, SSH/SFTP keys, database credentials, and payment or shipping secrets that may have been exposed.
6. Review database and configuration changes. Check for unexpected admin users, injected content, unfamiliar scripts in header/footer settings, altered configuration, and suspicious scheduled jobs.
7. Run a security scan and monitor after redeployment. Use Adobe's Commerce Security Scan and monitor file integrity and logs for new changes.

Read the Adobe Commerce incident-response guide and Commerce security guidance.

Step 4: Clean a hacked WordPress website

1. Take a snapshot and review logs. Record the incident timeline, recently installed plugins/themes, suspicious logins, and file changes.
2. Update WordPress core, plugins, and themes. Remove software that is abandoned, untrusted, nulled, or no longer required. Patch the entry point that allowed the compromise.
3. Reinstall core files from a trusted source. Replace WordPress core files with clean copies of the correct release. Do not rely on overwriting alone to remove every unknown file.
4. Reinstall extensions and themes cleanly. Obtain them from their official vendor or repository. Carefully review custom code before restoring it.
5. Inspect high-impact files and database content. Check wp-config.php, .htaccess, index.php, theme functions.php, unfamiliar PHP files under wp-content/uploads, scheduled tasks, and administrator accounts.
6. Rotate all access. Change WordPress administrator, hosting, SSH/SFTP, database, and deployment credentials. Regenerate WordPress authentication salts to invalidate existing sessions. Revoke exposed application passwords and API tokens.
7. Scan and monitor. Use a reputable security scanner, review login and server logs, and verify that redirects, spam, and suspicious files do not return.

Use the official WordPress hacked-site recovery guide for additional steps. A security plugin can help detect issues, but it cannot replace clean restoration and root-cause analysis.

Step 5: Secure a custom PHP website

• Restore from a known-clean release. Compare deployed files with version control and rebuild from reviewed source. Avoid manually repairing every file if the scope of compromise is unknown.
• Keep dependencies current. Update PHP to a supported release and patch Composer packages, frameworks, libraries, and custom components.
• Validate uploads. Allow only required file types, inspect actual content rather than trusting the filename or browser-provided MIME type, generate server-side filenames, store uploads outside the executable web root where possible, and enforce size limits.
• Block execution in upload directories. Use the correct web-server configuration to prevent PHP and other scripts from executing in directories containing user-supplied files.
• Use least privilege. The web process should not have unnecessary write access to application code, configuration, or deployment files. Grant write access only to directories that genuinely need it.
• Harden secrets and sessions. Keep credentials out of the public web root and source control. Rotate secrets after a breach and use secure session settings, CSRF protection, authorization checks, and parameterized database queries.
• Review dangerous patterns. Treat user-controlled input passed to command execution, dynamic code evaluation, or unsafe deserialization as a serious risk. Remove unsafe patterns rather than relying on simple string filters.

Step 6: Prevent PHP shell reinfection

• Patch the application, plugins, themes, server packages, and exposed services promptly.
• Use unique passwords, MFA, restricted admin access, and SSH keys with appropriate permissions.
• Separate unrelated websites and customers into isolated hosting accounts or containers where practical.
• Use version control and automated file-integrity monitoring to detect unexpected changes.
• Keep encrypted, off-site backups and test restoration regularly.
• Restrict database access to the application and approved administration paths.
• Review scheduled tasks, startup scripts, unfamiliar accounts, SSH keys, and outbound network activity after an incident.
• Run recurring malware and vulnerability scans, then investigate findings instead of simply dismissing or deleting them.

Common mistakes to avoid

• Deleting one suspicious file without checking for other backdoors.
• Restoring an infected backup without validating it.
• Changing only the WordPress or Magento admin password while leaving hosting, database, SSH, and API credentials unchanged.
• Assuming a malware scanner finding is always malicious—or assuming a clean scan proves the server is clean.
• Keeping the original vulnerable plugin, upload endpoint, or writable-permission setup that allowed the attack.
• Running broad deletion commands against production before preserving evidence and verifying file paths.

PHP shell security checklist

• Document the incident and preserve a clean copy of logs and a snapshot.
• Identify the likely entry point and scope of compromise.
• Compare files against trusted releases or reviewed version control.
• Rebuild or reinstall affected code from clean sources.
• Disable script execution in upload directories.
• Remove unauthorized users, tasks, keys, and integrations.
• Rotate all potentially exposed credentials and tokens.
• Patch the vulnerability and tighten permissions.
• Scan again and monitor for file changes or repeated suspicious requests.
• Test backups and document lessons learned.

Need help securing your website?

Molla Web Design helps businesses maintain and improve e-commerce and PHP websites, including Magento, WooCommerce, WordPress, and custom PHP applications. If your site is showing signs of compromise, begin with containment and evidence preservation, then arrange a structured security review and cleanup.

Contact: Molla Web Design

Frequently asked questions

Can I remove a PHP shell by deleting the suspicious file?

Sometimes that removes one component, but it does not prove the site is clean. Investigate how it arrived, look for additional backdoors, restore trusted files, rotate exposed credentials, and monitor for reinfection.

Are files containing base64_decode or eval always malware?

No. These patterns deserve review, but legitimate code may use encoding or dynamic behavior. Use context, file provenance, trusted-source comparisons, and logs to decide whether a file is malicious.

Should I restore a backup?

A known-clean backup can be useful, but validate it first and patch the original entry point before bringing the site back online. Otherwise, the same compromise may happen again.

Does a security plugin guarantee that my site is clean?

No single scanner catches everything. Combine application scanning, server and authentication logs, code comparison, credential rotation, and ongoing monitoring.