Title: SMEPlan Security Shield
Author: solotop
Published: <strong>1. 9. 2026</strong>
Last modified: 21. 9. 2026

---

Prohledat pluginy

![](https://ps.w.org/smeplan-security-shield/assets/banner-772x250.png?rev=3675151)

![](https://ps.w.org/smeplan-security-shield/assets/icon-256x256.png?rev=3675151)

# SMEPlan Security Shield

 Autor: [solotop](https://profiles.wordpress.org/solotop/)

[Stáhnout](https://downloads.wordpress.org/plugin/smeplan-security-shield.0.7.39.zip)

 * [Podrobnosti](https://cs.wordpress.org/plugins/smeplan-security-shield/#description)
 * [Hodnocení](https://cs.wordpress.org/plugins/smeplan-security-shield/#reviews)
 *  [Instalace](https://cs.wordpress.org/plugins/smeplan-security-shield/#installation)
 * [Vývojáři](https://cs.wordpress.org/plugins/smeplan-security-shield/#developers)

 [Podpora](https://wordpress.org/support/plugin/smeplan-security-shield/)

## Popis

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).

#### Key features

 * **Batched, checkpointed file scanning**: prioritizes `mu-plugins`, drop-ins, 
   the active theme/plugins, and `uploads`; never loads the whole file tree into
   RAM at once.
 * **Safe database scanning**: keyset pagination (no `OFFSET`) over `options`, `
   posts`, `postmeta`, `usermeta`, `comments`, `commentmeta` and `termmeta`; only
   flags a row when it decodes into an actually executable PHP/JS token, skipping
   image data URIs.
 * **Configuration checks**: `.htaccess`/`.user.ini` rules that map media extensions
   to PHP, `auto_prepend_file`, file/directory permissions, weak salts/keys, unusual
   cron entries.
 * **Baseline/integrity**: 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.
 * **Quarantine & rollback**: moves suspicious files aside (never deletes), with
   a full transaction log and 1-click rollback.
 * **Per-component backups**: 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.
 * **Maintenance mode with a TTL** that turns on automatically when remediation 
   touches a hot path or a large batch, and turns itself off once a health-check
   passes.
 * **Hardening**: login rate-limit/lockout by IP + IP/username (real IP behind a
   CDN via trusted proxies), disables XML-RPC pingback + caps `system.multicall`,
   security headers (HSTS/X-Frame-Options/CSP Report-Only), controlled auto-updates(
   low-traffic time window, skips VCS-managed sites, health-check after updating).
 * **Multi-layer scan scheduling**: WP-Cron + an internal watchdog + an HMAC-signed
   REST endpoint (for system cron/remote pings) + a WP-CLI command — the schedule
   keeps running even when WP-Cron is unreliable.
 * **Multisite**: enumerates every site by `blog_id`, scanning each site’s own `
   uploads` folder and tables.

Two hardening behaviours worth knowing about before you enable them, because they
change how the site answers requests that are not this plugin’s own:

 * **User-enumeration blocking is on by default.** For visitors who are not signed
   in, the core `wp/v2/users` REST routes stop being served and `?author=<id>` 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 — 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)
 * **`wp smeplan-ss scan run` exits 75 when a scan is already running.** 75 is `
   EX_TEMPFAIL` — „temporary failure, try again“ — rather than 0, so a wrapper running
   under `set -e` will treat a busy lock as a failed command. Handle 75 explicitly
   if you schedule the command that way. (rc-49)

#### Not yet in this release (planned for later versions)

 * 2FA (TOTP) and CAPTCHA for the login page.
 * Anonymous telemetry (opt-in).
 * Translations (every string is already wrapped in `__()`, ready for translators
   via translate.wordpress.org — no translation is bundled with the plugin itself).
 * Action Scheduler integration for enterprise-grade durable queuing.

### Privacy Policy

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/`, blocked from direct web access).

Two features send data off-site, and both are entirely opt-in — off unless the site
admin explicitly sets them up:

 * **Alert email**: if enabled, a summary of new findings is emailed to the site’s
   configured admin email address (`admin_email`) using WordPress’s own `wp_mail()`.
 * **Alert webhook**: if the admin enters a Webhook URL in Policies, a summary (
   site URL, alert subject, malicious/suspicious counts, timestamp — 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.

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.

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.

## Snímky obrazovky

[⌊SMEPlan Security Shield Dashboard and Security Scanner Overview.⌉⌊SMEPlan Security
Shield Dashboard and Security Scanner Overview.⌉[

SMEPlan Security Shield Dashboard and Security Scanner Overview.

## Instalace

 1. Upload the plugin to `wp-content/plugins/` or install it through the Plugins screen.
 2. Activate the plugin.
 3. Go to **Security Shield  Wizard** to check WP-Cron/loopback and configure trusted
    proxies if the site sits behind a CDN.
 4. See **Security Shield  Policies** to turn hardening features on/off as needed.

## Nejčastější dotazy

### Does the plugin delete suspicious files automatically?

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.

### What is removed when I delete the plugin?

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.

### Does the plugin automatically edit database content or the .htaccess file?

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.

### Does this plugin change how WordPress updates itself?

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.

### What environment does it need?

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.

## Recenze

Pro tento plugin nejsou žádné recenze.

## Autoři

SMEPlan Security Shield je otevřený software. Následující lidé přispěli k vývoji
tohoto pluginu.

Spolupracovníci

 *   [ solotop ](https://profiles.wordpress.org/solotop/)

[Přeložte “SMEPlan Security Shield” do svého jazyka.](https://translate.wordpress.org/projects/wp-plugins/smeplan-security-shield)

### Zajímá vás vývoj?

[Prohledejte kód](https://plugins.trac.wordpress.org/browser/smeplan-security-shield/),
podívejte se do [SVN repozitáře](https://plugins.svn.wordpress.org/smeplan-security-shield/),
nebo se přihlaste k[ odběru protokolu vývoje](https://plugins.trac.wordpress.org/log/smeplan-security-shield/)
pomocí [RSS](https://plugins.trac.wordpress.org/log/smeplan-security-shield/?limit=100&mode=stop_on_copy&format=rss).

## Přehled změn

Newest release only — WordPress.org truncates this section at 5,000
 characters.
The full history is in `changelog.txt`, shipped with the plugin.

#### 0.7.39

Security and reliability release. Works through the high-severity findings of the
same full-codebase review that 0.7.38 began: answers that meant „checked, clean“
when nothing had been checked, places the scanners never looked, and ways stored
evidence could be lost. Detection changed, so trusted components are re-scored once
after the update (three per minute, in the background).

**Places that were never looked at.** A PHP file under any folder named `node_modules`
or `.git` was only token-matched; it now gets the full analysis. A file that opens
with a PHP tag is reported whatever its extension (as suspicious — never auto-quarantined).
A handler file mapping an arbitrary extension to PHP (`AddType application/x-httpd-
php .abc`) matched no rule and now does; handler files are read to 1 MB, not 64 
KB. The database scan covers `usermeta`, `comments`, `commentmeta`, `termmeta` and
non-public post types, checks every base64 run in a value rather than the first,
and inspects both ends of an oversized value. Executable files planted in this plugin’s
own storage folder are reported. `languages/` in a verified plugin is exempt for
translation files only.

**„Clean“ that was not.** An aborted package walk, a backup re-check with no temp
folder, and an unreadable handler file each used to read as clean. The lock’s read-
back guard could not fail (it read its own cached write), so two scan ticks could
run at once. Maintenance was treated as active for 900 s although WordPress stops
honouring it after 600 s.

**Evidence and data.** The scheduled purge acts only on metadata this site signed,
has a time budget, and removes a session atomically. Reinstalling over a kept storage
folder no longer purges old sessions on the first tick (a one-week grace; the Purge
button is unaffected). Quarantine metadata is bound to its session id. Backups are
verified and extracted from one private copy, written under unique temp names, and
their metadata is swapped in only after the archive. Baselines are signed over what
was written, not what is found after publishing; revoking trust removes the signature
too.

**Smaller fixes.** REST `/findings` no longer returns file excerpts to review-only
users and `include_resolved` is a true superset; the replay nonce is claimed atomically;
a stale Policies tab can no longer overwrite newer settings; the self-signed-certificate
loopback option has a checkbox again; package-controlled text in the update-blocked
message is escaped; `wp smeplan-ss scan run` exits non-zero when the site does not
exist; network activation no longer stalls when WP-Cron is disabled; uninstall only
removes a maintenance file it can prove is its own.

Older releases: see `changelog.txt`, included with the plugin.

## Meta

 *  Verze **0.7.39**
 *  Poslední aktualizace **před 3 dny**
 *  Aktivních instalací **Méně než 10**
 *  Verze WordPressu ** 6.1 nebo novější **
 *  Testováno až do WordPressu **7.1.2**
 *  Verze PHP ** 7.4 nebo novější **
 *  Jazyk
 * [English (US)](https://wordpress.org/plugins/smeplan-security-shield/)
 * Štítků
 * [backdoor](https://cs.wordpress.org/plugins/tags/backdoor/)[firewall](https://cs.wordpress.org/plugins/tags/firewall/)
   [hardening](https://cs.wordpress.org/plugins/tags/hardening/)[malware scan](https://cs.wordpress.org/plugins/tags/malware-scan/)
   [security](https://cs.wordpress.org/plugins/tags/security/)
 *  [Podrobnosti](https://cs.wordpress.org/plugins/smeplan-security-shield/advanced/)

## Hodnocení

Zatím nebyly zadány žádné recenze.

[Vaše hodnocení](https://wordpress.org/support/plugin/smeplan-security-shield/reviews/#new-post)

[Zobrazit všechny recenze](https://wordpress.org/support/plugin/smeplan-security-shield/reviews/)

## Spolupracovníci

 *   [ solotop ](https://profiles.wordpress.org/solotop/)

## Podpora

Potřebujete pomoc?

 [Fórum podpory](https://wordpress.org/support/plugin/smeplan-security-shield/)