Security release, recommended for everyone. Fixes a re-validation pass that could never finish after 0.7.36 (and re-scanned three components every minute meanwhile), a failed quarantine that looked successful and let a live file be whitelisted, directory quarantines restored without any checksum, a purge that followed a planted symlink, site administrators on multisite changing files shared by every site, and a scanner that could freeze on one database row while the dashboard stayed green.<\/p>","0.7.37":"
Fixes three ways a defence could be switched off without anyone seeing it: database findings collapsing to a single index entry (which an attacker can steer), one partial settings write turning off fourteen hardening flags at once, and a cron_secret rotation silently blanking the whole event log. Settings changes are now recorded.<\/p>","0.7.36":"
Security fix, recommended for everyone. Four backdoor patterns were invisible to the detector in 0.7.35 and earlier \u2014 anything whose payload sits inside a string literal, including preg_replace with the \/e modifier and ini_set('auto_prepend_file', ...). Also fixes a login block that renewed its own expiry, which let anyone lock any account out permanently without credentials, and restores the cap on how many files a single scan may quarantine.<\/p>","0.7.35":"
Plugins are now verified against WordPress.org's official per-file checksums, including files added to a plugin that are not part of the official release. Also flags plugins removed from the directory or abandoned, and makes trust revocable so future detection improvements apply retroactively.<\/p>","0.7.34":"
Closes a critical hole: anything able to write into the uploads folder could forge a component backup and have it extracted over a plugin directory on the next Restore. Backups, baselines and scan checkpoints are now signed. Recommended for all sites.<\/p>","0.7.32":"
Fixes four ways this plugin could itself lose data or take a site down (a core-file restore leaving the file missing, a rollback overwriting the destination, a backup restore running with the site live, and a stranded .maintenance file after uninstall), stops one large file stalling the scanner, and restores quarantine recovery on sites upgraded from 0.7.26-0.7.30. Adds a Trusted components screen. Recommended for all sites.<\/p>","0.7.31":"
Follow-up fixes to 0.7.30: restores legacy-quarantine recovery after a reinstall, stops the scanner from restarting without ever finishing, and hardens the 0.7.30 alert and cron-example fixes. Recommended for all sites.<\/p>","0.7.30":"
Fourteen security and correctness fixes from a full review of 0.7.29, several affecting multisite recovery, quarantine rollback, and automatic backups. Recommended for all sites.<\/p>","0.7.29":"
Stops WordPress 6.7+ logging a "translation loaded too early" notice on every admin page load. Recommended if your debug log is filling up.<\/p>","0.7.28":"
Removes a debug warning added in 0.7.25 that flooded the log on sites with WP_DEBUG enabled. No behaviour change otherwise.<\/p>","0.7.27":"
Stops WordPress 6.7+ filling the debug log with a "translation loaded too early" notice on every request. No behaviour change otherwise; 0.7.26's security fix is included.<\/p>","0.7.26":"
Security release. Fixes an arbitrary file write inside the WordPress root: a forged quarantine session could make Rollback overwrite wp-config.php. Affects 0.7.24 and 0.7.25. Update, then review the Remediation screen before clicking Rollback if the site may have been compromised.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3675151,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3675151,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3675151,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3675151,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["0.7.31","0.7.32","0.7.34","0.7.35","0.7.36","0.7.37","0.7.38"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3675151,"resolution":"1","location":"assets","locale":"","width":1616,"height":779}},"screenshots":{"1":"SMEPlan Security Shield Dashboard and Security Scanner Overview."}},"plugin_section":[],"plugin_tags":[8646,1174,31093,163531,600],"plugin_category":[54],"plugin_contributors":[278558],"plugin_business_model":[],"class_list":["post-345738","plugin","type-plugin","status-publish","hentry","plugin_tags-backdoor","plugin_tags-firewall","plugin_tags-hardening","plugin_tags-malware-scan","plugin_tags-security","plugin_category-security-and-spam-protection","plugin_contributors-solotop","plugin_committers-solotop"],"banners":{"banner":"https:\/\/ps.w.org\/smeplan-security-shield\/assets\/banner-772x250.png?rev=3675151","banner_2x":"https:\/\/ps.w.org\/smeplan-security-shield\/assets\/banner-1544x500.png?rev=3675151","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/smeplan-security-shield\/assets\/icon-128x128.png?rev=3675151","icon_2x":"https:\/\/ps.w.org\/smeplan-security-shield\/assets\/icon-256x256.png?rev=3675151","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/smeplan-security-shield\/assets\/screenshot-1.png?rev=3675151","caption":"SMEPlan Security Shield Dashboard and Security Scanner Overview."}],"raw_content":"\n
SMEPlan Security Shield is a free, open-source security plugin built around a practical WordPress operations checklist: it watches the 3 most common attack surfaces (OWASP-class attacks plus WordPress-specific ones, persistence mechanisms, and entry vectors), detects issues with baseline\/checksum + signature + thresholded heuristics, and remediates safely (quarantine instead of outright deletion; 1-click rollback).<\/p>\n\n
mu-plugins<\/code>, drop-ins, the active theme\/plugins, and uploads<\/code>; never loads the whole file tree into RAM at once.<\/li>\n- Safe database scanning<\/strong>: keyset pagination (no
OFFSET<\/code>) over options<\/code>\/posts<\/code>\/postmeta<\/code>; only flags a row when it decodes into an actually executable PHP\/JS token, skipping image data URIs.<\/li>\n- Configuration checks<\/strong>:
.htaccess<\/code>\/.user.ini<\/code> rules that map media extensions to PHP, auto_prepend_file<\/code>, file\/directory permissions, weak salts\/keys, unusual cron entries.<\/li>\n- Baseline\/integrity<\/strong>: compares core files against WordPress.org's official checksums; automatically builds a SHA-256 baseline for every plugin\/theme on install\/update; 1-click restore of any mismatched core file from a signature-verified WordPress.org package, with the current file quarantined first.<\/li>\n
- Quarantine & rollback<\/strong>: moves suspicious files aside (never deletes), with a full transaction log and 1-click rollback.<\/li>\n
- Per-component backups<\/strong>: a \"last confirmed good\" snapshot of each plugin\/theme, refreshed on every trusted update, checksum-verified before every restore, with a best-effort local tamper-resistance layer.<\/li>\n
- Maintenance mode with a TTL<\/strong> that turns on automatically when remediation touches a hot path or a large batch, and turns itself off once a health-check passes.<\/li>\n
- Hardening<\/strong>: login rate-limit\/lockout by IP + IP\/username (real IP behind a CDN via trusted proxies), disables XML-RPC pingback + caps
system.multicall<\/code>, security headers (HSTS\/X-Frame-Options\/CSP Report-Only), controlled auto-updates (low-traffic time window, skips VCS-managed sites, health-check after updating).<\/li>\n- Multi-layer scan scheduling<\/strong>: WP-Cron + an internal watchdog + an HMAC-signed REST endpoint (for system cron\/remote pings) + a WP-CLI command \u2014 the schedule keeps running even when WP-Cron is unreliable.<\/li>\n
- Multisite<\/strong>: enumerates every site by
blog_id<\/code>, scanning each site's own uploads<\/code> folder and tables.<\/li>\n<\/ul>\n\nTwo hardening behaviours worth knowing about before you enable them, because they change how the site answers requests that are not this plugin's own:<\/p>\n\n
\n- User-enumeration blocking is on by default.<\/strong> For visitors who are not signed in, the core
wp\/v2\/users<\/code> REST routes stop being served and ?author=<id><\/code> links redirect to the home page. This is a deliberate part of the login-hardening layer, but it is a change to an API this plugin does not own \u2014 a headless front end, a mobile app or a third-party integration that reads the public user list will see it disappear. Turn it off under Hardening if something depends on it. (rc-47)<\/li>\nwp smeplan-ss scan run<\/code> exits 75 when a scan is already running.<\/strong> 75 is EX_TEMPFAIL<\/code> \u2014 \"temporary failure, try again\" \u2014 rather than 0, so a wrapper running under set -e<\/code> will treat a busy lock as a failed command. Handle 75 explicitly if you schedule the command that way. (rc-49)<\/li>\n<\/ul>\n\nNot yet in this release (planned for later versions)<\/h4>\n\n\n- 2FA (TOTP) and CAPTCHA for the login page.<\/li>\n
- Anonymous telemetry (opt-in).<\/li>\n
- Translations (every string is already wrapped in
__()<\/code>, ready for translators via translate.wordpress.org \u2014 no translation is bundled with the plugin itself).<\/li>\n- Action Scheduler integration for enterprise-grade durable queuing.<\/li>\n<\/ul>\n\n
Privacy Policy<\/h3>\n\n
By default, this plugin does not send any data outside of the site it is installed on. Everything it collects (scan findings, logs, baseline data) stays in the local WordPress database and in a protected local storage folder inside the uploads directory (wp-content\/uploads\/smeplan-security-shield\/<\/code>, blocked from direct web access).<\/p>\n\nTwo features send data off-site, and both are entirely opt-in \u2014 off unless the site admin explicitly sets them up:<\/p>\n\n
\n- Alert email<\/strong>: if enabled, a summary of new findings is emailed to the site's configured admin email address (
admin_email<\/code>) using WordPress's own wp_mail()<\/code>.<\/li>\n- Alert webhook<\/strong>: if the admin enters a Webhook URL in Policies, a summary (site URL, alert subject, malicious\/suspicious counts, timestamp \u2014 no personal or visitor data) is sent as JSON to that admin-provided URL whenever new findings are detected. Nothing is sent anywhere unless the admin fills in this field themselves.<\/li>\n<\/ul>\n\n
That storage folder outlives the plugin on purpose: deleting the plugin removes its options, cron events and capabilities, but leaves the folder in place so a quarantined file is never destroyed by an uninstall performed mid-incident. See the FAQ entry \"What is removed when I delete the plugin?\" for the reasoning and for how to remove it yourself.<\/p>\n\n
The plugin does not phone home to any SMEPlan-operated server, does not track usage\/analytics, and does not include any third-party tracking or advertising code.<\/p>\n\n\n
\n- Upload the plugin to
wp-content\/plugins\/<\/code> or install it through the Plugins screen.<\/li>\n- Activate the plugin.<\/li>\n
- Go to Security Shield \u2192 Wizard<\/strong> to check WP-Cron\/loopback and configure trusted proxies if the site sits behind a CDN.<\/li>\n
- See Security Shield \u2192 Policies<\/strong> to turn hardening features on\/off as needed.<\/li>\n<\/ol>\n\n\n
\nDoes the plugin delete suspicious files automatically?<\/h3><\/dt>\nNo. Files at the \"malicious\" level are moved into quarantine<\/strong> (wp-content\/uploads\/smeplan-security-shield\/quarantine\/<\/code>) 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.<\/p>\n\nQuarantined 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.<\/p><\/dd>\n
What is removed when I delete the plugin?<\/h3><\/dt>\nDeleting 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<\/strong> at wp-content\/uploads\/smeplan-security-shield\/<\/code>, which holds the quarantine, the file baseline, the event log and any component backups.<\/p>\n\nThis is a deliberate choice, not an oversight. Quarantined files are moved<\/em>, not copied \u2014 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.<\/p>\n\nTo 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:<\/strong> the quarantine\/<\/code> subfolder can contain live malicious files that were pulled off the site. Delete them, do not move them back into place.<\/p><\/dd>\nDoes the plugin automatically edit database content or the .htaccess file?<\/h3><\/dt>\nNo. 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.<\/p><\/dd>\n
Does this plugin change how WordPress updates itself?<\/h3><\/dt>\nNo. 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.<\/p>\n\n
What it does offer \u2014 off by default, and only if you switch it on in Policies<\/strong> \u2014 is control over when<\/em> an update WordPress has already found and verified gets applied. Using core's own public auto_update_core<\/code> \/ auto_update_plugin<\/code> \/ auto_update_theme<\/code> 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.<\/p>\n\nSince 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<\/code> filter, changes nothing about where updates come from, and can be switched off in Policies.<\/p>\n\nAutomated scanners flag any use of those filters for a human to look at, which is why this is spelled out here.<\/p><\/dd>\n
What environment does it need?<\/h3><\/dt>\nWordPress 6.1+, PHP 7.4+. Works best when WP-Cron runs normally; if the site has DISABLE_WP_CRON<\/code> set or blocks loopback requests, use system cron\/WP-CLI following the instructions on the Wizard page.<\/p><\/dd>\n\n<\/dl>\n\n\nNewest release only \u2014 WordPress.org truncates this section at 5,000\ncharacters. The full history is in changelog.txt<\/code>, shipped with the plugin.<\/p>\n\n0.7.38<\/h4>\n\n
Security release, recommended for everyone. A third full-codebase review of 0.7.37 found sixteen critical findings; this release fixes all sixteen.<\/p>\n\n
\n- The rules re-validation pass could never finish.<\/strong> Every page view re-seeded the queue, so after 0.7.36's rules bump a site re-scanned the same three components every minute forever and never re-scored its accepted files. The pass now leaves a queue in progress alone.<\/li>\n
- The same pass signed any baseline it found<\/strong>, including one written by whoever can write to uploads. It now refuses one it cannot authenticate and lets the scanner rebuild it.<\/li>\n
- A failed quarantine left a session that looked like a successful one<\/strong>, and \"Restore and accept\" on it whitelisted the still-live file. A failed move now takes its session with it, and \"already restored\" is only reported when the file at the original path is the one recorded.<\/li>\n
- A directory quarantine had no checksum<\/strong>, so anything added to it in uploads was restored into the plugins directory as the original. Directory sessions now record a tree digest and are refused when it no longer matches.<\/li>\n
- Purge followed a symlink planted in the quarantine folder<\/strong> and deleted its target. It no longer does.<\/li>\n
- On multisite, any site administrator could move or restore files shared by every site.<\/strong> Actions that change files now require a super admin on a network; single sites are unaffected.<\/li>\n
- \"Allow this update once\" could be spent by WP-Cron<\/strong> installing a different package of the same component with no scan. An unattended install never uses the override.<\/li>\n
- A form path lost its percent-encoded bytes<\/strong>, so the file accepted or quarantined could differ from the one shown. Paths are now validated without being rewritten.<\/li>\n
- A backup containing accepted files was never re-checked on restore<\/strong>; it is now, so a file whose acceptance the rules have since revoked is caught before extraction. A re-check cut short by its time cap no longer counts as clean, and the pseudo-component
plugin_.<\/code> (the whole plugins directory) is rejected.<\/li>\n- Three \"checked, clean\" stamps could be earned by a failure<\/strong>: an unreachable checksum API, a failed database query and an unreadable subdirectory each now report as incomplete instead of verified. A rules-driven revoke that lost its write is now logged rather than counted as done.<\/li>\n
- A database row that kept killing the scan tick froze the scanner<\/strong> at that row while the dashboard stayed green. A position that fails three ticks in a row is now reported and skipped, so the file, config and core checks run again.<\/li>\n
- Behind a trusted proxy, a client-settable header chose the lockout bucket<\/strong>, and every new value left two rows in the options table forever. The proxy's own X-Forwarded-For entry now wins, and stale rate-limit rows are cleaned up daily.<\/li>\n
- Core repair re-downloaded the 10\u201325 MB package on every click<\/strong> and usually died inside the download on shared hosting. The verified package is now kept between clicks; every file taken from it is still checked against the official checksum before it is written.<\/li>\n<\/ul>\n\n
0.7.37<\/h4>\n\n
Observability, and three ways a defence could be switched off without anyone seeing it.<\/p>\n\n
\n- Every database finding shared one index key<\/strong>, so however many injected rows a scan found, the index kept one \u2014 and which one is steerable by anyone who can write postmeta. Records without the file-shaped fields now key on the fields they actually carry.<\/li>\n
- One partial write could switch off fourteen hardening flags at once<\/strong>, because the boolean branch of the settings sanitiser was the only one with no
isset()<\/code> guard and the only one that reset rather than preserved. A marker submitted by the Policies form now tells a form save apart from a programmatic write.<\/li>\n- A settings change now leaves a trail.<\/strong> Nothing recorded one before, so there was no way to show when a site stopped being hardened \u2014 or that a fix had taken effect. Secrets are recorded as changed, never quoted.<\/li>\n
- Rotating cron_secret made the entire event log unreadable<\/strong>, silently blanking Findings, the badge and the REST listing while the history sat intact on disk under its old name. Reads now fall back to the previous generation.<\/li>\n
- \"Trust this IP\" no longer claims more than it does<\/strong> \u2014 a username lockout is a separate bucket it never cleared \u2014 and the exemption is now recorded with the actor.<\/li>\n<\/ul>\n\n
Older releases: see changelog.txt<\/code>, included with the plugin.<\/p>","raw_excerpt":"Scheduled security scanning (files\/DB\/config), baseline\/integrity checks, safe quarantine & rollback, and hardening for WordPress.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/345738","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=345738"}],"author":[{"embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/solotop"}],"wp:attachment":[{"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=345738"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=345738"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=345738"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=345738"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=345738"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/fa.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=345738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}