Ensomedia Security powered by shieldwave.io

Istoric modificări

1.1.28

• WP-CLI: the rescue commands wp shieldwave login-url off, wp shieldwave bot-check off and wp shieldwave two-factor disable now run under the names the readme and the Settings screen give.
• Sign-in: an account whose only second step is a passkey sees on the second step how to get back in if the device is lost.
• Custom login address: the notice says the address was emailed only when the email went out; otherwise it asks you to write the address down.
• Firewall: country blocking behind Cloudflare works without typing in the Cloudflare ranges; the plugin now ships them as the default list, and your own list replaces it. Ordinary traffic (WooCommerce, the block editor, REST, comments, contact forms, sign-in) is covered by tests and passes with every rule on.
• Translations reviewed in all 16 shipped languages.

1.1.27

• Sign-in: optional passwordless sign-in with a passkey, an optional bot check on login, registration and password reset (proof of work in the browser, or Cloudflare Turnstile with your own keys), an optional check of new passwords against known breaches (only 5 characters of a hash leave the site), and an optional custom login address with a way back through wp-config.php or WP-CLI. All start off.
• Spam traps: hidden fields and timing on registration and comments, and on Contact Form 7 and WPForms when they are active. Off until you turn them on.
• Activity log: successful sign-ins, accounts created and deleted, role changes, post and page edits (who and when, no content), plugin and theme installs, updates and deletions, and changes of key settings. Filter by type and person; the CSV export includes them.
• Backup check: the plugin looks for a backup plugin and the date of its last backup, and reports when there is none from the last 7 days. If the date cannot be read, the check says so instead of raising an alarm.
• When a break-in is found, the overview links to ordering a cleanup from ENSOMEDIA.

1.1.26

• Request firewall (opt-in): local attack rules, IP/range and trusted-country blocks, request and 404 limits, must-use and optional pre-WordPress loading, scoped exceptions and a local history. All settings use a separate option, start off and do not change virtual patches. Includes translations in all 16 shipped languages and tests for normal forms, forged sessions, uploads, concurrent storage, early loading and safe removal.

1.1.25

• Turn on protection: after activation, and once after this update, the plugin asks whether to turn on vulnerability alerts, the threat feed and virtual patches in one step, and says what leaves the site and where it goes. Nothing that sends data is turned on without your consent. The AI second opinion stays a separate choice. An update does not change your settings.
• Virtual patches that need no connection are on for new installs.
• Cleanup of injected code: when a scan finds code injected into a theme, a custom plugin or uploads, or a script or hidden link injected into posts or options, the plugin shows the exact change, makes a backup and applies it only when you approve it. Every cleanup can be undone. New administrator accounts it cannot explain are reported, never deleted.

1.1.24

• PHP version check: php2shell (CVE-2026-109618 and CVE-2026-109619, rated 9.2 of 10, remote code execution without logging in; PHP fixed it on 2026-10-21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35). The check compares your web server’s exact PHP version with the fixed release of its branch. Branches 8.1 and older get no fix from the PHP project. The finding is high, because the flaw is critical. Linux distributions and hosts often ship the fix without changing the version number, so it tells you to ask your host whether the fix is installed and does not say the site is vulnerable.

1.1.23

• Updating this plugin by uploading its ZIP over the old version (Plugins > Add > Upload > Replace current with uploaded) no longer reports the plugin as changed without an update. The checksum check no longer moves the change time of files the earlier scan saw, which made the recorded update look older than the files. Found on a hand check of 1.1.22 on a real site, where it showed as high until WordPress.org published the version.
• The virtual patches loader the plugin writes into the must-use plugins folder is no longer reported as a new file in a highly trusted location.
• Caching, object cache and query plugins write advanced-cache.php, object-cache.php and db.php into wp-content. When an active plugin that ships or generates such a file names itself in it, the change is low and names the plugin, not high. Any other drop-in stays high.
• The handler cPanel writes for the account’s PHP version on LiteSpeed and CloudLinux (ea-php82___lsphp, as AddHandler or AddType) is no longer counted as a rule that runs files as PHP in .htaccess.
• A change to wp-config.php that only adds plain settings, such as WP_CACHE or FORCE_SSL_ADMIN written by a caching, security or SSL plugin, is low and names the settings. The plugin remembers which lines the file had as hashes only, never as text. Code, includes and changes to the database or site address settings stay medium. The advice never says to delete wp-config.php.
• A script found by reading a public page is high, not critical: the page is read from outside and matched by signatures, so critical stays for what the files or the database prove.
• Advice no longer tells you to delete or remove something you cannot identify (odd file names and links, a changed PHP file, an unknown file in the site folder, a new plugin folder, a hidden administrator). It says to ask your developer or host to look at it and to keep a copy first. The warning about a break-in stays where a malware signature or a known bad file is the evidence.
• The content check no longer takes more than a minute on a very large post on PHP 8.2 and older. A post of 1.6 MB with 120,000 paragraphs took 80 seconds on PHP 7.4 to 8.2 and under a second on 8.3 and 8.4.
• Unused themes can be deleted from their finding, as unused plugins already could. Only themes the finding lists are offered, never the active theme, its parent, a theme another site of a network uses or the default fallback theme, and WordPress’s own delete function does the work.
• Password hints on the settings screen are no longer cut off, and the decoy login checkbox is aligned.
• Before release, the plugin was run through a test site with every optional feature switched on (baseline, features on, two rescans), through an update from 1.1.18, 1.1.19 and 1.1.20, through a two-site network, through PHP 7.4 to 8.4, and through the 200 most popular WordPress.org plugins.

1.1.21

• The content check now reads every site option, not only widgets, theme settings and header code, as well as the snippets of the Code Snippets plugin and account data. In those places it reports only what a real setting never carries: a script from a bare IP address or a throwaway domain, a hidden decoded loader, a card skimmer or code the malware signatures call malicious. Cached answers of other services, this plugin’s own data and the signature stores of other security plugins are left out, and a value of many megabytes is read as its beginning and its end. Such findings go to „Ask your developer”.
• An administrator that code on the site hides from the list of users is reported. The administrators are now read from the database and compared with the list WordPress gives. Two new signatures look for code that leaves a named account out of that list or lowers the administrator count above it.
• A new administrator made by an administrator who signs in with a password alone is now a low, unscored item to confirm instead of a note: the record alone does not show who used that password.
• New application passwords of administrators, changes of the site address, the WordPress address and the administration email address, scheduled tasks whose code lives in the uploads folder, has no file of its own or is a PHP command function, and database triggers on WordPress tables are reported. A change made by an administrator who signs in with a second factor is not.
• Decoy login names and the decoy path lock an address out only on its second use within an hour, and never a signed-in visitor, a request another website made the browser send or the shared address of a CDN that is not set as a trusted proxy.
• Turning off the threat feed, the vulnerability lookup, the AI second opinion, the decoy path lockout or security updates of a plugin, and ignoring a whole group of findings, now ask for your password or a code.
• The threat feed never takes a feed older than the one it has, also right after a plugin update.
• The suggested WP-CLI commands for a vulnerable plugin quote its folder name and version.
• A changed core, plugin or theme file can be replaced with its original: one button on the finding downloads that file of the installed version from WordPress.org, uses it only when it matches the official checksum and keeps the changed file in quarantine, where restoring it undoes the repair. If the site answers with an error afterwards, the changed file is put back at once.
• A new check, What visitors and search engines see, reads the home page and the checkout as a visitor, as Googlebot and as a visitor from Google search, and reports injected scripts, redirects only search visitors get and links only Googlebot gets. It also looks for folders of spam pages, sitemaps of other sites and extra Google verification files in the site folder.
• Scripts that load code from an address hidden in encoded text are reported, in files and in published posts, as is PHP that shows search engines other content.
• With a connected account, decoy hits appear in the shieldwave.io dashboard. Only a keyed hash of the address is sent.
• Virtual patches also run on the sites of a multisite network and on the login page, XML-RPC, WP-Cron, robots.txt and the sitemaps. They read the body of PUT, PATCH and DELETE requests and JSON sent with any content type, compare a value also the way plugins clean it, and keep working for 14 days when the threat feed cannot be refreshed. A large post saved in the block editor is no longer blocked.
• A finding is never lost because its text is too long for the database. Stored content made to slow the scan down, exhaust its memory or hide deep inside page builder data is read in small parts and to the end.
• An administrator whose role is stored in a form WordPress never writes is found.
• No login name or post title goes to shieldwave.io with a finding.
• Replace with the original also works for the WordPress files in the site root, checks that the installed version is still the scanned one, and says so when it cannot confirm the new file. Putting a kept copy back needs the same update permission as the repair.
• Security updates install only offers from WordPress.org, and never one that WordPress.org, the host or another plugin turned off.
• Decoy records cannot push lockout records out of the history, a decoy hit never locks out the address of a proxy or CDN, a ShieldWave scan reaching the decoy path is written to the history without a lock, and taking a name off the decoy list asks for your password.
• Ignoring a critical finding, or more than five findings one by one within an hour, asks for your password.
• What visitors and search engines see follows redirects within the site, says when a page could not be read in full and keeps the earlier findings about that page open until it can.
• Files made to slow down the malware rules or exhaust their memory are read in linear time and small memory. A file that stops the scan twice is skipped and reported instead of stopping every scan. A permission check that every user passes no longer hides request input that reaches code.
• The suggested privacy policy text says which decoy details go to shieldwave.io with a connected account.

1.1.20

• The check for PHP printing errors on pages no longer reports display_errors as on when the server’s php.ini turns it on and the site turns it off for its own folder (php_flag in .htaccess, .user.ini or the PHP-FPM pool). Checks started with the Run checks button and the scheduled scans now use the value a normal admin page sees. Until an admin page has been opened after the update, the check says the setting could not be assessed.
• A server configuration file is no longer reported as changed when WordPress rewrote only its own block of it, on a site where the plugin was installed before version 1.1.10 or where an earlier report kept no copy of the lines outside the blocks. Such a file was reported on every scan, for example after the site address moved to https. A rule outside the blocks that runs files as PHP, prepends a PHP file or sends visitors to another site is still reported. The finding for a changed configuration file now lists the lines added and removed outside the blocks of WordPress and plugins, and no longer says that it disappears after a new scan.

1.1.19

• Decoys, off until you turn them on under Settings: login names no account has and one Disallow line for a random path in the robots.txt that WordPress serves. A use of either is refused, written to the history and mailed once a day per address, and can lock the address out with the login protection. Nothing is created: no user, no file.
• Detects four kinds of script that attackers put into hacked sites to attack visitors: a fake CAPTCHA that asks the visitor to paste a command (ClickFix), a fake browser update page, a loader that reads its code from a blockchain contract (EtherHiding) and a card skimmer that sends payment card fields to an outside host. Plugin and theme files are checked, and so are scripts stored in posts, page builder data, widgets and options. A finding needs every sign of its kind in the same script, so copy buttons, CAPTCHA services, web3 sites and payment forms are not reported.

1.1.18

• No PHP warning on hosts whose open_basedir setting leaves out the folder above WordPress. The plugin checks that setting before it looks at a wp-config.php there, a debug log or any other file outside the allowed folders.
• Unused plugins are one finding with their number and names, and so are unused themes, so the Overview and shieldwave.io show the same count. A plugin or theme with a finding of its own keeps that finding too.
• The note on extra files of a plugin built outside WordPress.org says what ShieldWave did: it has no copy of the author’s source for that version, so it did not compare those files.
• With WordPress in a subfolder of the site, a copy of wp-config.php in the folder above (the web root) is requested at the site address like a copy in the WordPress folder: high when it downloads, an info note when the server refuses it. Before, it was low without a request.
• After a plugin update the threat feed is downloaded again, and a stored copy that another plugin version checked is replaced even when the feed has not changed. Before, a copy an older version had stored without the vendor file lists stayed in use. „Copy for your developer” and the sync name the feed version, when it was issued and the plugin version that stored it.
• Security updates, off until you choose a plugin: when a release fixes a known vulnerability of the installed version, WordPress’s own automatic updates install it (WordPress 6.6 or newer, which puts the previous version back if the update fails), the plugin then checks that the home page and the login page answer, and every step goes to the activity log.
• Virtual patches, off until you turn them on under Settings. With the live threat feed on, a small must-use file stops a request that exploits a known vulnerability of an installed plugin, for as long as the installed version is affected. Patch rules come only from the signed feed. Each patch only records matching requests until you let it block them, and a blocked request gets a plain 403. Turning the switch off removes the file.
• Arabic: severity names match shieldwave.io, and instructions address the reader without masculine imperatives.
• Polish: one-letter words stay with the next word, so none ends a line.
• A changed .htaccess, .user.ini or php.ini is described as a server configuration file: the steps for your developer say to undo the lines nobody added and keep the file, instead of treating it as a PHP file and suggesting to delete it.
• An update that adds files to a plugin or theme WordPress.org cannot verify, including one installed by uploading a ZIP, no longer makes every changed file „changed outside an update”. Before, the files the update added were indexed first and made the update look older than the change.
• The readme fits the WordPress.org limits again: the description and External services are shorter, quarantine and login data moved to the FAQ, and the changes before 1.1.10 moved to changelog.txt.

1.1.17

• The score follows the same severity bands as shieldwave.io: an open critical finding keeps it at 39 or below, a high one between 40 and 59.
• Detects file-dropper backdoors: request input written into a PHP file, a written file’s path chosen by the request, and decoder names assembled from pieces whose result is run.

1.1.16

• One score everywhere. The Overview, the weekly email, WP-CLI, the heartbeat and the sync all show the score stored with the last scan, and it is stored again when you ignore or restore an issue, when a live check runs and when an AI second opinion arrives. Before, the Overview and the sync could show two numbers for the same moment.
• A known vulnerability is rated by the access it needs. Without login it keeps the advisory’s rating, and critical needs code execution, SQL injection, an authentication bypass, an arbitrary file upload or a CISA KEV entry. A subscriber, customer or contributor account makes it high at most, author, editor or shop manager medium at most, administrator low. An advisory without a rating is low, with a note. „Update to” names the version that fixes every listed advisory.
• One cause, one finding. An unused plugin WordPress.org closed for a security issue that also has a known advisory is one finding, which says it was closed, plus a note that it is unused. A file reported by more than one check (it differs from its release, it is new since the last scan, the malware check flags it) is counted once, at the most serious finding.
• WordPress PHP translation files (.l10n.php) next to a plugin’s or theme’s translations are no longer „a PHP file the release does not have”. The malware check still reads them.
• A request from the server to its own https:// address that fails is a note that HTTPS could not be checked, not „login not served over HTTPS”. A refused HTTPS port while http:// answers is still high.
• Scans started from WP-CLI or a system cron no longer judge the web server by the command line’s PHP. The plugin remembers the web server’s PHP version and display_errors from your admin pages. Until it has seen them, those two settings are not assessed. WP_DEBUG_DISPLAY set to null follows php.ini, as WordPress does.
• Notes instead of findings: an administrator created with WP-CLI, XML-RPC multicall when another login limiter is active or a firewall answers, PHP that stops getting security fixes within four months, and a leftover scheduled task with only a web address. On a network, a theme active on any site is in use, and a default theme a WordPress update adds is not „added outside the installer”.
• A base64_decode counts only when the decoded text reaches code that runs or includes it, so the plugin no longer flags its own passkey code. Drafts, pending and private posts are read with the malware signatures only. Security keys follow WordPress’s own rule (empty, the sample phrase or shared), not their length. A stale wp-content/debug.log is checked even when WP_DEBUG_LOG names another file.
• Private findings keep their identity when you replace the security keys in wp-config.php. Low findings no longer suggest looking for a break-in, and a few texts were reworded to say what was observed.

Changes before 1.1.16 are in changelog.txt in the plugin folder.