How to Remove Suspicious WordPress Files: A Practical Cleanup Guide for 2026

Written by: Abigail Ivy
Published on:

How to remove suspicious WordPress files safely

Suspicious WordPress files often appear after a plugin vulnerability, weak credentials, or a compromised admin account.

This guide explains how to remove them carefully, protect legitimate site files, and reduce the chance of reinfection.

The key is not to delete everything that looks unfamiliar.

Many WordPress installs contain custom code, cache files, and server-generated assets that are easy to mistake for malware.

What counts as a suspicious WordPress file?

A suspicious file is any file that does not match the expected structure, purpose, or origin of your WordPress installation.

Malware authors often hide code in places that administrators rarely inspect, such as uploads directories, theme files, and wp-content subfolders.

Common warning signs include:

  • File names that look random, such as abc123.php or class-cache1.php
  • PHP files inside wp-content/uploads, where images and documents usually live
  • Recently modified core files that should not have changed
  • Obfuscated code using functions like eval(), base64_decode(), or gzinflate()
  • Files with unusual permissions or ownership
  • Duplicate files pretending to be WordPress core files

Not every unfamiliar file is malicious.

Backup tools, page builders, security plugins, and caching systems can create files that seem odd but are normal for that environment.

Prepare before deleting anything

Before removing suspicious WordPress files, take a full backup of both the database and the file system.

If you delete a legitimate file by mistake, a backup is the fastest way to restore the site.

Use a secure working method:

  • Put the site in maintenance mode if possible
  • Change passwords for WordPress admin accounts, hosting accounts, FTP, SFTP, and the database
  • Enable two-factor authentication on critical accounts
  • Record the current file structure so you can compare changes later

If the site is still active, consider isolating it on a staging copy.

That lets you inspect and clean files without affecting live traffic.

Find suspicious files in the most common hiding places

Most malicious files are placed where they are less likely to be reviewed.

Start with directories that should not normally contain executable PHP.

Check wp-content/uploads

The uploads directory should usually contain images, PDFs, audio, video, and other media files.

PHP files in this location deserve immediate review because they are a common persistence mechanism for attackers.

Inspect active themes and child themes

Attackers frequently modify functions.php, header files, and template files.

Compare active theme files against clean copies from the original theme vendor or repository.

Review plugins

A compromised plugin may contain backdoors, especially if it is outdated or downloaded from an untrusted source.

Look for new files inside plugin folders, unexpected admin helpers, or code that loads from remote domains.

Scan the WordPress root

Core files such as wp-config.php, index.php, wp-settings.php, and .htaccess are high-value targets.

Any unexpected modifications in these files should be treated as serious.

Verify files against known-good sources

The safest way to identify suspicious WordPress files is to compare them with trusted originals.

Download fresh copies of the same WordPress version, plugin version, and theme version from official sources such as WordPress.org or the vendor’s website.

Use comparisons to look for differences in:

  • File names
  • File size
  • Last modified timestamps
  • Code structure
  • Unexpected external links or script loaders

On Linux servers, tools like diff, find, and grep are useful for identifying changes.

Security plugins and malware scanners can help, but manual verification is still important because attackers often disguise malicious code to evade automated detection.

How to remove suspicious WordPress files without causing damage

Once a file is confirmed malicious, remove it carefully and document what you changed.

If the file is part of a core, theme, or plugin package, replace the entire package rather than editing the infected file line by line.

A practical removal workflow looks like this:

  1. Quarantine the suspicious file by renaming it or moving it outside the web root.
  2. Confirm the site still loads and note any broken functionality.
  3. Replace the affected WordPress core, theme, or plugin files with clean copies.
  4. Delete the quarantined file after you verify it is not needed.
  5. Rescan the site for additional infections.

For files in uploads, deletion is usually appropriate if the file is a PHP script or another executable artifact.

For theme or plugin files, reinstalling from a clean source is usually more reliable than manual cleanup.

Inspect for persistence mechanisms

Attackers often leave more than one malicious file behind.

After the first cleanup pass, search for persistence mechanisms that can restore the infection.

Look for:

  • Unknown admin users in WordPress
  • New scheduled tasks or cron jobs
  • Hidden database injections in posts, widgets, or options tables
  • Injected JavaScript in header or footer areas
  • Suspicious redirects in .htaccess or server config files
  • Modified wp-config constants or unusual include statements

Also review access logs and error logs.

They may show how the attacker uploaded the files, which helps you close the original entry point.

Use security tools, but do not rely on them alone

WordPress security plugins such as Wordfence, Sucuri, and iThemes Security can speed up detection and scanning.

Hosting-level malware scanners can also identify common signatures and known backdoors.

However, scanners can miss:

  • Newly created malware with no known signature
  • Files intentionally placed in legitimate-looking directories
  • Code hidden inside database content
  • Backdoors embedded in otherwise normal plugin code

For best results, combine scanning with a manual review of recent file changes, unfamiliar PHP files, and any code that handles remote requests or file uploads.

When should you replace the entire site?

Sometimes the safest path is to rebuild from clean components instead of trying to repair every file.

This is often the better choice when the site has multiple infections, repeated reinfections, or a long history of outdated plugins and weak credentials.

Consider a full rebuild if:

  • Core files keep changing after cleanup
  • The same malware returns after removal
  • Multiple plugins or themes are compromised
  • You cannot verify the source of key files
  • The site handles sensitive customer data

A full rebuild usually means reinstalling WordPress, then adding only trusted themes, plugins, and uploads that have been inspected or restored from a clean backup.

Prevent suspicious files from returning

Cleaning infected files is only part of the job.

Long-term prevention depends on tightening access, reducing software risk, and monitoring for changes.

  • Keep WordPress core, plugins, and themes updated
  • Remove unused plugins and inactive themes
  • Use strong passwords and two-factor authentication
  • Disable file editing in the WordPress dashboard
  • Restrict PHP execution in upload directories
  • Run regular malware scans and file integrity checks
  • Use trusted backups with version history
  • Limit FTP access and prefer SFTP or SSH

For high-value sites, file integrity monitoring is especially useful.

It alerts you when key files change so you can investigate quickly before an intrusion spreads.

Signs that cleanup is complete

You are closer to a clean site when the following are true: no suspicious files remain in web-accessible directories, WordPress core matches the official release, active themes and plugins come from trusted sources, and the site behaves normally after rescanning.

A final review should also confirm that no unauthorized admin accounts remain, no malicious redirects are active, and no unknown cron jobs or database injections are still present.

At that point, you can restore normal traffic and continue monitoring closely for a few days.