If your site has been hacked, or you think that it may have been hacked, then follow our site cleaning guide here.

Scan Results Actions

A number of different actions can be taken on each type of scan result.

When using the actions to “repair” or “delete” a file we recommend that you create a backup of the file first unless you are familiar with the file.

To understand which scan results trigger scan stages to show a yellow warning triangle then you can see the conditions that would need to be met by viewing our scan stages documentation here.

REPAIR

The “repair” action will only be available for modified WordPress core files and files belonging to plugins and themes available from the wordpress.org repository. Clicking the button to repair a file will replace it with an original copy of that file. Note that if any legitimate code customization of any files on your site has been carried out then you will lose any custom functionality. For example, if legitimate code has been added to your theme’s “functions.php” file then this custom code will be lost if you repair this file. By default, you will be prompted to download a backup of files that you repair individually.

IGNORE

Choosing to “ignore” a scan result means it will not appear in subsequent scans under the “Results Found” tab. Ignored scan results instead appear under the “Ignored Results” tab.

Scan results for files have two further “ignore” actions available that apply as follows:

“Ignore until file changes”: This will cause the scan result to reappear in “Results Found” the next time the file changes. Use this action if you have added custom code to a file such as your theme’s “functions.php” file. It will then be ignored until further code modifications are detected.

“Always ignore”: This option will ignore the file permanently, regardless of any further file changes.

HIDE FILE

The “hide file” button will appear when a scan result shows that a publicly accessible configuration, backup, or log file is found. You can use this action to prevent the file from being publicly accessible. Note that some web server configurations may require this to be fixed manually, either by changing permissions on the file or blocking access to it via a configuration file such as “.htaccess”. Please refer to the Publicly accessible config, backup, or log file found section below for more information on how to do this.

DETAILS

This option will expand the scan result and provide further information about the scan result. At the bottom of the details section there will be further actions as follows:

VIEW FILE

This will open a new browser tab allowing you to inspect the code in the file.

DELETE FILE

This allows you to delete the file. Be very cautious of deleting files. If you are not sure whether a file should be deleted then create a backup of the file first. Running a HIGH SENSITIVITY scan can generate false-positive scan results and you could potentially delete legitimate theme or plugin files.

MARK AS FIXED

This button will remove the scan result from the current list of scan results. Scan results that have been marked as fixed will reappear in subsequent scans. This action is useful when you have a long list of scan results. For example, you could “mark as fixed” all results for plugins that have an update available. This will tidy up the list and help you to concentrate on the other scan results that you want to investigate.

VIEW DIFFERENCES

This action will only be available for WordPress core files and files belonging to themes and plugins that are available in the WordPress.org repository. It allows you to view the code that contains modifications and compare it to the code in the original copy of that file. File changes are color-coded as follows:

• Green – Code added to your modified version of the file will be highlighted in green.
• Yellow – Code that has been changed in an existing section of code in your modified version of the file will be highlighted in yellow.
• Red – Code that has been removed from your modified version of the file will be highlighted in red.

VIEW UPDATES

This action is only available in scan results that indicate an update is available for a theme or plugin in the WordPress.org repository. This button will take you to your WordPress administration “Updates” page so that you can view all available updates.

MANAGE PLUGINS

This action will be present when an installed theme or plugin appears to have been abandoned or has been removed from the WordPress.org repository. Please refer to the Plugin appears to be abandoned and Plugin has been removed from WordPress.org sections below for more information.

Scan results can require some interpretation, and you might need to take different actions depending on how you run your WordPress site. Below are details of some of the scan results.

Admin user with a suspicious username

This scan checks for suspicious users with usernames that may be used on hacked sites.

Example scan result
An admin user with a suspicious username wp.service.controller.x was found.
An admin user with a suspicious username wp.service.controller.x was found. Administrator accounts with usernames similar to this are commonly seen created by hackers. It's possible a plugin could have created the account, but if you do not recognize the user, we suggest you remove it.

Resolution
If you do not recognize the user, it is likely to be malicious. If you have other administrators on the site, and you know their full names but might not remember the username they have on your site, it is best to check with them first. Keep in mind that this result is based on malicious usernames we have seen before, and there is a chance that someone has chosen a similar username by chance in some cases.

File appears to be malicious or unsafe

Wordfence detects known malicious files and files that have suspicious code. In most cases, you will want to repair or remove the file, but you should investigate the contents first.

Example scan result
File appears to be malicious or unsafe: wp-content/uploads/footer.php
This file appears to be installed by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The text we found in this file that matches a known malicious file is: "(example)". The infection type is: Example Infection.

Resolution
If you do not know what the file is, we recommend making a backup before you remove it, in case it was a false positive. Some plugins could create files containing code that appears similar to malicious files but is not actually malicious, especially backup plugins that produce an installer that you could use to restore the backup. We always recommend saving a backup copy of the file first, whether by making a full backup of the site or by saving only the file and the location where it belongs, so you can replace it if necessary.

Option contains a suspected malware URL

Some attacks affect WordPress options or options from plugins and themes that are stored in the WordPress “options” table. This result indicates that an option contains a potentially malicious URL, which could be the result of an infection.

Example scan result
Option contains a suspected malware URL: td_011
This option contains a URL that is currently listed on Wordfence's domain blocklist. It may indicate your site is infected with malware.

Resolution
To clean affected options, you will need to determine which plugin, theme, or core feature uses the option listed in the scan results.

The most likely case is an option with a name like “td_###” (any three digits) and a URL including “traffictrade”, which is related to an issue with the Newspaper theme and derived themes. These themes had a vulnerability in July/August 2017. To remove the affected code, go to the Newspaper theme’s menu, click the “Theme Panel” submenu, click the “Ads” tab, and go through the list of ad positions to find and remove the “traffictrade” scripts that do not belong there. Be sure to also update the theme to the latest version and clean any additional affected files.

Also, check the WordPress “Settings” > “General” page. Two options may have been changed. The “Anyone can register” checkbox should be disabled if you do not allow user registration on your site, and the “New User Default Role” should not be set to “Administrator” as the default setting is “Subscriber” on single-site WordPress installations.

Plugin has a security vulnerability

This scan checks for plugins that do not have a pending update but have known security issues.

Example scan result
The Plugin "Plugin Name" has a security vulnerability
To protect your site from this vulnerability, the safest option is to deactivate and completely remove "Plugin Name" until a patched version is available.

Resolution
Plugins with known vulnerabilities can leave your site open to attack. The safest solution is to deactivate and remove the affected plugin. If you are running an older version of WordPress or PHP, you may need to update WordPress or PHP in order to use the newer version of the plugin where the security issue has been fixed. You can check the plugin’s requirements on wordpress.org to see which WordPress and PHP versions it supports, and can also see if the plugin author has released a newer version.

Plugin needs an upgrade

This scan result means that a plugin has an update available. There are two types of alerts for plugins with an update available, “Medium” and “Critical”. A plugin with an update available will generate a Medium alert. If the plugin also has unpatched security vulnerabilities, the scan result will be Critical.

Example Medium scan result
You need to upgrade "Plugin Name" to the newest version to ensure you have any security fixes the developer has released.

Example Critical scan result
Update includes security-related fixes.
You need to upgrade "Plugin Name" to the newest version to ensure you have any security fixes the developer has released.

Resolution
Plugins with unpatched vulnerabilities should always be updated. If you are certain that the plugin is still safe, and the scan result does not show unpatched security issues, you can continue to use it. Some small plugins may remain safe and may not need any compatibility changes for new WordPress versions. However, in most cases, we recommend that you consider updating all plugins, and this includes installed themes too.

Plugin appears to be abandoned

This scan result means that a plugin has not been updated in 2 years or more. This can be a problem because it means that the plugin author has not made any changes for a long period of time. Sometimes that means it will not be fully compatible with newer WordPress versions, reported bugs may not be fixed, and new security issues might not be addressed.

The scan result also shows if this plugin has a known security issue that has not been fixed. If that is the case, it is recommended that you remove the plugin as soon as possible, and replace it with a different plugin if you need the same functionality.

There are two types of alerts for abandoned plugins, “Medium” and “Critical”. An abandoned plugin will generate a Medium alert. If the plugin also has unpatched security vulnerabilities, the scan result will be Critical. Plugins that are abandoned should be evaluated in terms of what risk they may pose. Unless you know that the code in the plugin is safe, you should start looking for a replacement. Plugins with unpatched vulnerabilities should always be removed.

Example scan results
The Plugin "Plugin Name" appears to be abandoned (updated April 20, 2015, tested to WP 4.1.18).
It was last updated 2 years 2 months ago and tested up to WordPress 4.1.18. It may have compatibility problems with the current version of WordPress or unknown security issues.

Resolution
If you are certain that the plugin is still safe, and the scan result does not show unpatched security issues, you can continue to use it. Some small plugins may remain safe and may not need any compatibility changes for new WordPress versions. However, in most cases, we recommend that you consider replacing it with a plugin that is being actively maintained.

Plugin has been removed from WordPress.org

This means that a plugin is no longer available to install from WordPress.org. Plugins can be removed from WordPress.org for a variety of reasons, including that the author intentionally stopped its development or converted it to a “paid only” plugin. A plugin can also be removed if it violates the WordPress.org terms of service, or if it contains vulnerabilities. If it contains vulnerabilities, it may be restored to the repository within a few days. As a general recommendation, unless you are familiar with the code in the plugin, we suggest that plugins that have been removed from the WordPress.org repository are removed from your site.

Example scan result
Your site is still using this plugin, but it is not currently available on wordpress.org. Plugins can be removed from wordpress.org for various reasons. This can include benign issues like a plugin author discontinuing development or moving the plugin distribution to their own site, but some might also be due to security issues. In any case, future updates may or may not be available, so it is worth investigating the cause and deciding whether to temporarily or permanently replace or remove the plugin.

Resolution
In most cases, we recommend removing the plugin and finding a similar plugin that is being actively maintained. Some hosts pre-install some plugins on all new WordPress sites, so if you have a plugin installed that you have never used, and it is no longer available on WordPress.org, it is best to remove it.

If the removal was at the plugin author’s request, we recommend following up with them on their site so that the plugin remains updated and supported. If updates will no longer be available on wordpress.org, you may need to install a new copy of the plugin from the author’s site.

Note that there may also be rare cases where a plugin you have from another source shares a name with a WordPress.org plugin, so if you know that is the case, it would not be necessary to remove it.

Modified plugin file

Sometimes a plugin author will make changes to one or more files for their plugin but without committing a new tag version number for that new modified version of the plugin. The WordPress “Updates” and “Plugins” page will have notifications that a new version of the plugin is available to install. If you install that new version and run a scan then you may get a scan result that a file or files have been modified because our mirror copy of the plugin for that same version number differs due to the changes the plugin author made without committing a new tag version number.

Example scan result
Modified plugin file: wp-content/plugins/plugin-slug/file.php
This file belongs to plugin "Plugin Name" version "X.X.X" and has been modified from the file that is distributed by WordPress.org for this version. Please use the link to see how the file has changed. If you have modified this file yourself, you can safely ignore this warning. If you see a lot of changed files in a plugin that have been made by the author, then try uninstalling and reinstalling the plugin to force an upgrade. Doing this is a workaround for plugin authors who don't manage their code correctly.

Resolution
You can try uninstalling and reinstalling the plugin to force an upgrade, but you may still get a scan result or multiple results that a file or files have been modified until our mirror copy of the plugin has been updated to match the newer updated version at the WordPress.org plugin repository.

Modified theme file

Similar to modified plugin files above, sometimes this can be caused by a theme author modifying a theme after a release, without changing the version number. Sometimes hosts with Managed WordPress plans will install a pre-release version of a theme, which will have minor differences from the official version available on wordpress.org. Additionally, this scan result can also be caused by yourself or a developer who works on your site modifying theme files, so that they no longer match the official versions.

Example scan result
Modified theme file: wp-content/themes/theme-slug/functions.php
This file belongs to theme "Theme Name" version "1.2" and has been modified from the original distribution. It is common for site owners to modify their theme files, so if you have modified this file yourself you can safely ignore this warning.

Resolution
Make sure that you have a backup of your theme files if you plan to make any changes. Since a developer working on your site might have modified a theme, you should be sure that nobody working on your site has intentionally made the changes, before repairing any theme files. Ideally, developers should use “child themes” if they need to make changes to a theme from WordPress.org since this still allows the theme to be updated while having all of the customizations in separate files.

If you are sure that no one has intentionally modified your theme, you can try repairing theme files, or uninstalling and reinstalling the theme to get the current version, but you may still get scan results that a file has been modified until our mirror copy of the theme has updated to match the newer updated version at the WordPress.org repository. Again, be sure that you have a backup that you can restore before making any changes.

If your site is hosted on a “Managed WordPress” host, and the host manages themes, it is possible you may not be able to repair theme files. In this case, you can still use the “View Differences” button to see what has changed.

Publicly accessible config, backup, or log file found

This result shows files that may contain sensitive information that can be served by the web server. This may be backup copies of files, like a copy of “wp-config.php” under another name, log files, or configuration files.

Example scan result
Publicly accessible config, backup, or log file found: .user.ini
http://example.com/.user.ini is publicly accessible and may expose sensitive information about your site or allow administrative functions to be performed by anyone. Files such as this one are commonly checked for by both attackers and scanners such as WPScan and should be made inaccessible. Alternately, some can be removed if you are certain your site does not need them. Sites using the nginx web server may need manual configuration changes to protect such files.

Resolution
If you know that the file is not needed by your site, you can simply remove the file. This is often the case with files like “wp-config.bak”, which may be a backup copy of your “wp-config.php” file. Do not remove files like “.user.ini” that may be required for your site to work properly.

If in doubt, the scan result includes the option to hide the file, which will add a section of code to your “.htaccess” file to prevent your web server from serving this file, if you leave the file in place. This is recommended for “.user.ini” and similar files. You can run another scan after making the change, to make sure your server correctly blocks public access.

If you need to manually add the .htaccess code, this should work for Apache 2.2 and 2.4:

<Files ".user.ini">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

Note that the scan option to hide a file may not work on some hosting provider server configurations.  For example, the option to hide a “.user.ini” file on an AWS Lightsail/WordPress deployment will not work as expected.  The block of code above would need to be manually added to these custom Apache configuration files below:

/opt/bitnami/apache/conf/vhosts/wordpress-https-vhost.conf
/opt/bitnami/apache/conf/vhosts/wordpress-vhost.conf

If your site uses the NGINX web server, then you or your host may need to configure NGINX to block access to the file, whether NGINX is set up as a reverse proxy in front of Apache or if NGINX handles all requests directly. The method of blocking these files in NGINX varies depending on your current configuration, but one simple example is placing a “location” block like this, in the same file as your other “location” blocks:

location ~ \.user\.ini$ {
deny all;
}

Make sure to restart NGINX or reload its configuration after making any changes to its configuration files, and then check that the “.user.ini” file is no longer visible in a web browser.

Skipped Paths / 1 path was skipped for the malware scan due to default scan settings

By default, Wordfence scans WordPress-related directories only if the option “Scan files outside your WordPress installation” is not enabled. This scan result shows if you have any additional directories that you might want to scan. You should not scan additional WordPress sites that are in the same hosting account that have their own Wordfence installation, but you or your host may have added other directories that could be useful to scan.

This scan result was first added in Wordfence 7.4.3 in early 2020, though the option to scan all directories had already existed.

Example scan result
2 paths were skipped for the malware scan due to default scan settings
The option "Scan files outside your WordPress installation" is off by default, which means 2 paths and their files will not be scanned for malware or unauthorized changes. To continue skipping these paths, you may ignore this issue. Or to start scanning them, enable the option and subsequent scans will include them. Some paths may not be necessary to scan, so this is optional.
The paths skipped are ~/.cache/ and ~/testing/.


Resolution
You should decide whether the additional files should be scanned. In general, additional WordPress sites in a subdirectory of the main site should not be scanned if they have their own Wordfence installation, since they will run their own scans more efficiently. If you do not know what the additional directories contain, it is generally okay to scan them, but your scans may take longer, and in some cases, there may be false positives. If you find suspicious files only after enabling this additional scan, be sure to confirm that they are malicious before removing them. The support team can help if you are unsure.

If you do not want to scan the listed directories, click the “Ignore” icon on the scan result, so it will not appear in future scans. You can remove it from the “Ignored Results” tab later if you decide that you want to check for additional directories again.

If you would like to enable scanning the directories listed in the scan result, click the “GO TO OPTION” button and enable the option “Scan files outside your WordPress installation” on the Scan options page. They will be included the next time a scan runs.

If you want to scan only some of the directories that are found, you can enable the above option, and also add some paths to the “Exclude files from scan that match these wildcard patterns” field on the Scan options page. For example, if you have a second site in the directory “another-site/” and it has its own Wordfence installation, you can enter “another-site/*” in the main site’s “Exclude files…” field, to exclude that directory and all of its contents.

Unknown file in WordPress core

This scan checks your WordPress core files and notifies you about files that do not match the current version of WordPress that you have installed.

Example scan result
Unknown file in WordPress core: wp-includes/js/info.php
This file is in a WordPress core location but is not distributed with this version of WordPress. This scan often includes files left over from a previous WordPress version, but it may also find files added by another plugin, files added by your host, or malicious files added by an attacker.

Resolution
If you already know about the listed file, you can click the link to ignore the file until it changes. If you do not know what the file is, it may require some investigation to find out if your host has placed it there, or if it may have been created by your FTP application or server operating system, or if it is malicious.

Some “Managed WordPress” hosting plans do not allow you to change core files, and on some hosts, if a new version of WordPress no longer includes a particular file, it may be left in your site’s files after they update WordPress. In this case, it is generally safe to ignore the file, or you can contact the host if you believe it should be removed.

In a few cases, we have seen that a host’s support staff or a host’s control panel may place “php.ini” files in every subdirectory of WordPress’s core directories. Typically, this is to change PHP settings throughout the site. Since this can generate a lot of scan results, we combine results for php.ini files into a single result with a note like “(22 more similar files were found.)”

• If that occurs, we recommend checking the contents of some of these files to make sure they are safe. If you are not sure if the files are safe, please reach out to our support staff, either in the free forums or the ticketing system for Premium users.
• Assuming that they are safe, your host may have a better way to set the same PHP settings without adding additional files. Depending on the server configuration, it is usually done through the PHPRC environment variable or by using “.user.ini”.
• Alternatively, if you are sure they are safe, you can use the “ignore” option, to hide the result unless there are future changes.

Update Check Encountered Error

When Wordfence checks for updates, it includes checking the WordPress plugins API. Plugins from sources other than wordpress.org can hook into the plugins API, in order to show their updates as well, but when those plugins have bugs in their update check, Wordfence cannot detect their updates. In some cases, those plugins could cause fatal errors, especially if they have not been updated for PHP 8. Wordfence now catches these errors so that scans can continue, but the plugin may still need a manual update if it is out of date, or the plugin author may need to fix the plugin’s update functionality.

Example scan result
Update Check Encountered Error on 'plugin-slug'
The update check performed during the scan encountered an error: Attempt to assign property "name" on null [plugin-slug] Wordfence cannot detect if this plugin/theme is up to date. This might be caused by a PHP compatibility issue in the plugin.

Resolution
The “plugin slug” listed in the error message shows which plugin triggered the error. You may need to check if the plugin has an update at the source where you got it, since this is most likely caused by a plugin that is not available on wordpress.org. If the plugin previously had PHP 8 compatibility issues, and your site had been upgraded to PHP 8 before the plugin was compatible, it may not be able to check for its own updates.

If the plugin is already up to date, the plugin author may need to update the plugin to prevent the error that is shown in the scan result. This type of error is most likely preventing the plugin from checking for its own updates as well.

If there is no plugin slug shown in the scan result, you can try temporarily disabling plugins that did not come from wordpress.org, and running another scan to see if the issue still occurs. If the issue is resolved, then one of those plugins has likely caused the error. The error message shown in the scan result can also help determine the cause.

Web Application Firewall is disabled

If a file permissions issue or other server problem causes the firewall’s files to be unreadable, this scan will notify you about it. This scan was added in Wordfence 7.2.3 in early 2019, so you may see this result for an existing file-related issue that was not related to the upgrade.

Example scan result
Web Application Firewall is disabled
Status: Disabled
Details: Wordfence's Web Application Firewall has been unexpectedly disabled. If you see a notice at the top of the Wordfence admin pages that says "The Wordfence Web Application Firewall cannot run," click the link in that message to rebuild the configuration. If this does not work, you may need to fix file permissions.


Resolution
The problem can generally be fixed by logging into your site and clicking the link in the WordPress administration notice about this issue to “rebuild” the configuration file. If the result still occurs after rebuilding the configuration and running another scan, you may need to fix permissions on the directory at “wp-content/wflogs/” and its contents. This scan result should be uncommon. If you see it more than once, your server may have an issue with locking files or general stability.

More details on handling issues with firewall files can be found here.

If your server has an unusual setup and you see this scan result even while the firewall is working normally, you can disable the scan option Monitor Web Application Firewall status on the scan options page.

Your WordPress version is out of date

This result appears when a major or minor WordPress release is available for your site. Beginning in February 2024, the scan result’s severity will be adjusted depending on the importance of the update, and minor releases will be shown if it is not necessary to upgrade to a major release in order to get the latest security fixes. High severity is shown when updates include a security fix, Medium severity is shown for minor updates without significant security fixes, and Low severity is when you are using the latest version of a branch that has no significant security issues while a major release is also available.

Example scan result
Your WordPress version is out of date
Type: Core Upgrade
Current WordPress Version: 6.1.5
New WordPress Version: 6.4.3

Details: WordPress version 6.4.3 is now available. Please upgrade immediately to get the latest fixes and compatibility updates from WordPress.


Resolution
Upgrading WordPress to the latest version resolves this issue. You can also apply minor updates if they are recommended, without updating to the latest major version, though you will generally get a low severity scan result showing the latest version. Ignoring WordPress version scan results will ignore only the target version, so that you will still be notified of future updates.

In general, minor WordPress updates (like 6.4.2 to 6.4.3) will fix important bugs or security issues, and usually they have minimal compatibility issues. Ideally, you should always apply minor updates, whether using automatic updates or manual updates. Major WordPress versions (like 6.3.2 to 6.4 or 6.4.3) are somewhat more likely to have compatibility issues with plugins or themes that have not been tested by the developer with the new version, though we recommend making sure your site is compatible and applying these updates when possible. In either case, you should make sure that you have backups of the site in case an update causes any issues, and if possible, test the update on a “staging” copy of the site first.

Note that in some cases, we have seen the WordPress updates API offer only a major version, even when a minor version is still available for a site. This occurred shortly before a new WordPress version was released, so you may see a major version in the scan result if you delay applying minor releases that had already been available. A list of released WordPress versions is available on wordpress.org, where you can find the latest version for the branch your site is using, if you are unsure.

WordPress also has a guide to updating WordPress here, with details about the various methods you can use.