Ensomedia Security powered by shieldwave.io

A must-use loader checks requests before normal plugins load. The optional Load before WordPress setting adds a marked entry to .user.ini on PHP CGI/FastCGI hosts and refuses to replace another auto_prepend_file; the firewall screen shows whether early loading ran. Named password fields and authentication headers are not inspected. History stays on your site for up to 30 days and records metadata, not query strings or submitted values. Reducing protection, adding an exception, clearing history or lifting a block asks for your password or an authenticator code. If the firewall blocks you, replace wp-content/ensomedia-security-firewall.php with an empty PHP file and remove only the marked .user.ini entry, and keep the empty file until PHP's configuration cache expires. Without early loading, define SHIELDWAVE_FIREWALL_OFF in wp-config.php to turn the loader off. The firewall adds protection; it does not replace updates or fix vulnerable code. Its rules ship with plugin updates and are separate from the virtual patches and the malware feed.

No. All 25 checks, scheduled scans, email alerts and the vulnerability lookup work without one, with no limits.

Yes. Under ShieldWave > Settings > Toolbar, turn off "Show ShieldWave in the toolbar". The choice is per administrator. Visitors never see it.

It trusts the files WordPress.org can vouch for, needs real evidence before it calls something malware, and emails only about problems that are new or got worse. The goal is that every alert you get is one you would want.

The scanner found something unusual that is often harmless: for example a new PHP file in a premium plugin without an update. It is listed so someone who knows the site can look at it, and it never sends an email on its own. Problems under "Fix now" are the ones with clear evidence.

Open the item and press "Ignore". It stays out of the score and the alerts, and an ignored file comes back by itself if it changes again. Ignored items stay under the "Ignored" link below the to-do list, where "Restore" brings one back.

Scans and settings, and also sign-ins, new and deleted accounts, role changes, who edited, published or trashed a post or page, plugin and theme installs, updates, switches and removals, and changes to the site addresses, the administration email, "Anyone can register" and the new user role. A post is named by its title and number, never its text. Sign-ins and edits are written once per person in a short window, at most 300 a day together. The History screen filters by type and person, and the CSV export holds every entry.

No. The Backups check looks for a switched-on backup plugin, a few hosts that back up themselves and archives in the usual folders, and reads the date of the last backup from their settings and files without running them. It says so when the newest backup is older than 7 days. When it cannot read a date, it marks the check as not assessed and does not raise an alarm.

No. Scans never run while a visitor's page loads: they work in the background in steps of a few seconds, and later scans skip files that were clean and did not change. On a busy shared host you can choose the low scan speed in Settings.

It stays on the hour you chose, in the time zone set under Settings > General, and it follows a change of that time zone at once. On the one day a year the clocks skip the chosen hour, the scan runs right after the skipped hour. On the day an hour happens twice, it runs once, the first time the clock shows it.

Only when scans run: to WordPress.org for checksums, theme packages, plugin information and the list of WordPress releases, and to your own site. With the vulnerability lookup, live threat feed or AI second opinion on: to shieldwave.io, once an hour from WP-Cron and after scans. With an account connected: to shieldwave.io, also once an hour. With the breached password check: to api.pwnedpasswords.com. With Cloudflare Turnstile: to challenges.cloudflare.com. Each of those is off until you turn it on, and the External services section below lists exactly what is sent. Requests to your own site: the XML-RPC, debug output and exposed files checks request xmlrpc.php, the debug.log URL, backup files found on disk and the uploads folder; the HTTPS check asks for the home page over http and https and the security headers check once over https. "Check now" for PHP in uploads writes two harmless test files there, requests them and deletes them. After a file is moved to quarantine or replaced with its original, or after a security update, the plugin requests the home page and the login page to see that the site still answers. The check of what visitors and search engines see requests the home page and the WooCommerce checkout with a browser user agent, as Googlebot and with a Google search referrer. A running scan calls your own admin-ajax.php to continue in the background.

The AJAX action shieldwave_worker lets a running scan continue in the background; it does nothing without the random token of the running scan. The plugin's REST routes answer administrators only.

With login protection on, the REST API user list answers only logged-in requests, so an anonymous request for an author gets an error. To keep the list public, add add_filter( 'shieldwave_hide_user_list', '__return_false' ); to a small plugin or to your theme's functions.php. The same filter also brings back the author fields in embeds and the users sitemap.

Yes, network-wide. It is activated for the whole network (Network Activate): two-factor login and login protection need that, because one sign-in works on every site. Scanning, the schedule, alerts, the settings screens and the optional ShieldWave account all live on the main site, in the Network Admin, for network administrators only. Every other site of the network enforces the same choice made there: when login protection, two-factor or a hardening switch is on, it is on for that site too, with no separate settings screen to set up. A lockout after failed logins is shared by the whole network, not counted per site, so an address cannot dodge the limit by trying a different site.

Yes. If WP-Cron is disabled or loopback requests are blocked, scans still run while the ShieldWave screen is open, and scheduled scans run whenever your server cron calls wp-cron.php.

It starts at 100. For each check, the most serious open issue takes off points: critical 30, high 15, medium 8, low 3. The most serious issue on the site then sets the range, as in the outside scan on shieldwave.io: 0-39 with a critical issue, 40-59 with a high one, 60-100 with neither. Ignored issues, hints and checks that could not run take nothing off.

English, Arabic, Chinese (Simplified), Dutch, French, German, Indonesian, Italian, Japanese, Korean, Polish, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish and Vietnamese. The screens, the login protection and the alert emails follow the language of your WordPress admin, and Arabic gets a right-to-left layout. Regional variants such as Spanish (Mexico), German (Switzerland) or French (Canada) use the main language. For these languages the plugin's own translation is used, and a translate.wordpress.org pack fills only what it lacks; other languages use the pack from translate.wordpress.org once one is complete.

Builds downloaded from shieldwave.io before the directory listing were called ShieldWave Security, numbered up to 3.6.6, and live in the folder shieldwave-security. They cannot update themselves to this plugin. Keep Ensomedia Security active, deactivate ShieldWave Security, then delete it on the Plugins screen: the settings, results and two-factor set-ups carry over, because Ensomedia Security keeps them while the old copy's clean-up runs. The Plugins screen shows a notice while an old copy is installed.

A finding of medium severity or higher about one file can move that file into quarantine. The file is stored encoded, so it cannot run, in a folder the web server refuses. wp-config.php, the main .htaccess, WordPress's own files and files the site loads on every request are never moved, and if the site stops working after a move, the file goes back. Nothing is moved unless you press the button. Restore puts back the same bytes, with their date and permissions, where the file was. Quarantined files are kept in a folder inside wp-content that is removed, with the files the plugin put there, when the plugin is deleted, so restore what you want to keep before you delete the plugin.

All of them are under ShieldWave > Settings > Sign-in checks and Spam traps, and all are off until you turn them on.

• Sign in with a passkey, without a password. The login page gets a button. The passkey checks your fingerprint, face or device PIN, so it stands for both the password and the code. Needs passkeys on, and a passkey your device keeps for the site; one added only as a second step may need adding again. Your password keeps working.
• Bot check. The browser solves a small puzzle (a proof of work) before the login, registration or reset form is sent. It needs JavaScript and sends nothing anywhere. Cloudflare Turnstile is the other choice, with the keys of your own Cloudflare account. Record only writes to History what Block would stop. Trusted addresses are never checked, and if Cloudflare cannot be reached the form goes through. To turn it off without the dashboard, add define( 'SHIELDWAVE_BOT_CHECK_OFF', true ); to wp-config.php or run wp shieldwave bot-check off.
• Breached passwords. A new password is refused if the Pwned Passwords service of Have I Been Pwned knows it. Only the first 5 characters of its SHA-1 hash are sent. At sign-in an account with such a password is asked to change it, never blocked. If the service does not answer, the password is accepted.
• Hidden login address. The login page moves to an address you choose and wp-login.php shows "not found". This hides the login page, it does not secure it: login protection and two-factor login still do that. The new address is emailed to you when you set it. If you lose it, add define( 'SHIELDWAVE_LOGIN_URL_OFF', true ); to wp-config.php or run wp shieldwave login-url off, and the login page is back at wp-login.php. Not available on multisite or beside another plugin that moves the login page.
• Spam traps. Comments, registration, Contact Form 7 and WPForms get a hidden field and a signed time stamp. A form filled in by a program, or sent within 3 seconds, is caught. With Block, a caught comment goes to the Spam folder, where you can approve it. Signed-in visitors and trusted addresses are never checked. Clear the page cache once after turning it on.

When logins are paused after too many failed attempts, the plugin records the IP address and the typed user name (the name only when the account exists). After a successful login it sets a cookie whose name starts with shieldwave_kd_. It holds only a random identifier, lets that browser keep signing in while someone else guesses the password for the same account, expires after 90 days and stops working when the password changes.

The plugin removes its settings, results, tables, scheduled tasks, user settings, two-factor and passkey data, the quarantine folder and its block in the uploads .htaccess file. If the site is connected to shieldwave.io, it first asks shieldwave.io to remove the site and its results.

It shows the site in your shieldwave.io dashboard with its score and open problems, next to the outside scan of shieldwave.io, and confirms that the domain is yours, which the full outside scan needs. Every site you connect shows up, on the free plan too. Everything in the plugin works the same without it.

Open a topic in this plugin's support forum with the check name and what you see. False positives are treated as bugs.

When the plugin finds signs of a break-in, the Overview links to an order form for a one-time cleanup by ENSOMEDIA, the maker of this plugin, at shieldwave.io/cleanup, and the link sends nothing from your site.

Follow https://shieldwave.io/legal/en/vulnerability-disclosure?utm_source=wordpress&utm_medium=plugin&utm_campaign=readme. Please do not post it in the public support forum.

The admin screens use the Inter typeface by The Inter Project Authors, licensed under the SIL Open Font License 1.1 (assets/fonts/inter-license.txt). It is loaded from the plugin itself, only on the ShieldWave screens.