SMEPlan Security Shield

No. Files at the “malicious” level are moved into quarantine ( wp-content/uploads/smeplan-security-shield/quarantine/ ) rather than deleted, and can be rolled back with 1 click. Files at the “suspicious” level are only recorded, waiting for manual review on the Findings page.

Quarantined files are kept for a limited time: once a session is older than the retention period set under Policies (14 days by default), it is removed automatically to stop the quarantine folder growing without bound. Roll back anything you want to keep before that window closes, or raise the retention setting.

Deleting the plugin removes every option it created, its scheduled events, and the three custom capabilities it grants. It deliberately does not remove its storage folder at wp-content/uploads/smeplan-security-shield/ , which holds the quarantine, the file baseline, the event log and any component backups.

This is a deliberate choice, not an oversight. Quarantined files are moved , not copied — the folder holds the only remaining copy of anything the plugin took out of the site. Deleting a plugin is easy to do in the middle of handling an incident, or by someone who is not the person investigating, and having that click silently destroy both the only rollback path and the only forensic evidence would be the wrong default for a security plugin. Reinstalling brings the previous quarantine and logs straight back.

To remove it, delete that folder yourself over SFTP or your host’s file manager once you are sure nothing in it is still needed. Read the caution first: the quarantine/ subfolder can contain live malicious files that were pulled off the site. Delete them, do not move them back into place.

No. Every finding in the database or in configuration files (.htaccess/.user.ini) is only reported, never auto-fixed, to avoid breaking a site’s legitimate functionality.

No. It never supplies its own update source: there is no bundled update checker, no third-party update server, no filtering of the plugin-information API, and nothing written to the transients core caches available updates in. Everything WordPress installs still comes from WordPress.org, fetched and verified by WordPress itself.

What it does offer — off by default, and only if you switch it on in Policies — is control over when an update WordPress has already found and verified gets applied. Using core’s own public auto_update_core / auto_update_plugin / auto_update_theme filters, it can hold an update back until the low-traffic window you configure, skip it while the site is under load, and skip any plugin or theme directory that is under version control (updating those breaks a deploy). It only ever delays WordPress’s own updates; it never substitutes them.

Since 0.7.32 it can also refuse one: a plugin or theme package is scanned while still in its temporary folder, and if a file in it matches malware detection the install is stopped before anything is written. A manual update can be allowed through once from the dashboard notice; an automatic one is refused and reported. This uses core’s own upgrader_source_selection filter, changes nothing about where updates come from, and can be switched off in Policies.

Automated scanners flag any use of those filters for a human to look at, which is why this is spelled out here.

WordPress 6.1+, PHP 7.4+. Works best when WP-Cron runs normally; if the site has DISABLE_WP_CRON set or blocks loopback requests, use system cron/WP-CLI following the instructions on the Wizard page.