=== Ensomedia Security changelog, 1.0.0 to 1.1.15 ===

The changes since 1.1.16 are in readme.txt.

= 1.1.15 =
* What the scanner could not see is a note outside the score: a file too large to read in full, an XML-RPC check the site could not run against itself, a debug log it could not test or the server refuses, and a backup file the server refuses, did not answer about or was not asked about in this scan. A site whose only open items were such notes scored 86 (B). It now scores 100.
* A file counts as downloadable only when the server answers with the file's own first bytes. "PK" at the start of an answer, or any text that is not a web page, no longer proves it. A downloadable zip is listed: settings, keys or a database dump inside make it high, other files low. Installer and Adminer scripts are never requested, since a request runs them, so they are low until you remove them.
* A known vulnerability is rated by the access it needs. Without login it keeps the advisory's rating, and critical is kept only for code execution, SQL injection or an authentication bypass. With a subscriber-level account it is one step lower, with author, editor or administrator rights it is low, and an advisory without a rating is low, with a note.
* One cause, one finding. An update that a known vulnerability covers is listed with the vulnerability, an unused plugin or theme is listed once, and a WordPress minor release is low unless an advisory covers it. A plugin WordPress.org closed for a reason other than security is low. One closed for security is high only with a known advisory.
* Security keys WordPress ignores (the sample phrase, a value two keys share) are low. A short key it uses stays medium. On a network, where people who sign up get no role, registration is no longer judged by a site's default role.
* Scheduled tasks: code words match as whole words, so "retrieval" is not "eval". A task nothing runs that carries code is medium. One with only a web address is a low leftover of a removed plugin. "Treat the site as infected" appears only when the malware check flagged the code that runs a task with a known malware name.
* A new administrator that the activity log shows another administrator created is a note. A script from another site with no sign of malware is low, and "automated injection" needs such a sign. A changed core file is high (critical needs a malware match), a PHP file in uploads the analyzer found nothing in is low, and the files an update left behind are one low finding per plugin.
* A PHP version without security fixes is low, since hosts often backport fixes. Pingbacks are not reported when pings are closed on the whole site. The public user list counts only when a visitor really gets it (a block by the server or a firewall counts as closed), and it is called a list of username slugs.
* One grade ladder, the one shieldwave.io uses: A from 90, B from 80, C from 60, D from 40. The heartbeat sends the stored score of the last scan, the number the sync sends, and the Overview headline reads the score the Overview shows.
* Texts that sounded alarming without evidence were rewritten, and texts the plugin no longer uses were removed from the translations.

= 1.1.14 =
* A plugin its author ships outside WordPress.org, such as Advanced Custom Fields from WP Engine with its own Update URI line and updater files, is compared without that one header line, and its extra files with the author's published source of the same version, which the threat feed now carries. Until now the main file was "changed" and the updater files were "unknown PHP" (high). A file the published source does not have is still reported high. Without a published source the extra files are one note that they could not be verified, and the malware check reads them more strictly.
* Checksum lists from WordPress.org that also list the plugin's files under trunk/ (YITH WooCommerce Product Add-ons 4.34.1 lists 441 files twice) no longer make every clean install report hundreds of missing files. Missing files of one plugin or theme are one finding with the count and a few paths. A missing file runs no code.
* Code snippets of WPCode, Simple Custom CSS and JS and Woody snippets are read with the malware signatures, active or not, and an active PHP snippet is no longer "PHP code stored in content". A PHP tag in a normal post is still reported.
* A known vulnerability in a plugin or theme nothing uses is one step lower, and its fix is to delete it instead of deactivating it.
* Severities follow what someone could do on the site now. The file editor, an easy administrator login name, updates without a known vulnerability, a changed .htaccess without PHP rules, a phpinfo() file the site does not serve, an unknown PHP file in the site root the malware signatures find nothing in, and a backup copy that could not be requested are low. A WordPress minor release and errors shown on the page are medium. A copy of wp-config.php that downloads as text is high.
* XML-RPC: WordPress stops checking passwords in a request after the first wrong one, and login protection counts XML-RPC logins, so with login protection on the multicall finding is a note.
* The Overview says "signs of a break-in" only for a malware match, a web shell, administrator powers outside the role or a malicious code snippet. A file that differs from its release is listed under "Fix now" as a weakness. Finding texts no longer guess at an attack where only a difference was found.
* The sync to shieldwave.io sends every open issue (up to 500, it was cut at 200) with its fingerprint and first-seen time, and says whether the list is complete, so "new since the last scan" counts only new findings.

= 1.1.13 =
* No more false alarms right after an update. The file changes check finishes again (from 1.1.10 to 1.1.12 it stopped with an error, so its findings never closed), a file that matches its release keeps its official mark through the walk that follows an update, and a plugin or theme whose every code file matches WordPress.org is never "changed without an update", even when the update left no record, as automatic updates of this plugin do.
* The malware check no longer calls a plugin's own admin code malicious when request input reaches eval or include behind a nonce and capability check that ends the request, and an include path chosen from a fixed table by a request key is not request input. Dummy checks and checks on one side of an "or" are still caught.
* A file of a WordPress.org plugin is judged more strictly only when it stands out: it differs from the release, is not part of it, or the rest of the plugin matched while it carries no mark. Until now, when the marks were gone after an update or WordPress.org had no checksums for the version, every file of the plugin was read that way and one weak sign was enough to report it (WP Mail SMTP's e-mail summary template).
* Six rules were narrowed after a sweep of 147,858 files from the 200 most popular WordPress.org plugins: a login form that checks the password it was sent, the WordPress importer and the copies themes bundle, assert used as a type check, a stylesheet printed inside a style tag, a variable named $include, and a shipped build script that writes PHP from its own text are no longer reported. The backdoors they resembled still are, each with a sample in the release tests.
* Drafts of code snippets (Simple Custom CSS and JS, WPCode) are not injected content; published snippets are still checked.
* A large script that is not PHP in a node_modules, vendor or bower_components folder of a plugin or theme gets no "too large to analyze" note of its own; both ends are still analyzed.
* The Overview headline says the site needs some tidying, in amber, when the score is under 60 or five or more things are open with nothing urgent. It no longer says "Your site looks good" over a failing score.
* The live threat feed card says "nothing new beyond the built-in rules" instead of "0 rules, 0 known-bad files".
* A theme that loads its front-end CSS in wp-admin no longer draws a line across the ShieldWave header.
* A security review of the whole plugin (admin screens, REST and the scan worker, the connection to shieldwave.io, login and two-factor, passkeys, sessions, quarantine, every check and the rules engine). What it found is fixed here. For a site updated from 1.1.x with a trusted proxy, the visitor address header is no longer picked up from a header a visitor could have added; only X-Forwarded-For is adopted on its own. A live login lockout is no longer lifted by a sign-in finished later on the two-factor screen. Turning the scan schedule or the alerts off, raising the alert threshold, adding an alert recipient, excluding files and starting the file history over now ask for your password, as turning a protection off does. Serialized objects inside the posts, widgets and builder data the content check reads are never created. A post of many megabytes no longer holds the scan. A server rule that runs images as PHP through mod_rewrite, a redirect to another site inside a caching plugin's block, a page or redirect saved as a "placeholder" in uploads, and a firewall bootstrap that only names the firewall's folder in a comment are reported. File names are shown and quarantined exactly as stored, including a leading space or a marker inside the name. Paths longer than 1,024 characters are stored whole. Findings whose severity depends on the state of the site (an exposed backup, an available update, a known-bad scheduled task) come back after an ignore when that state gets worse. The history log refuses to seal over a change made outside the plugin, notices the deletion of its oldest entries and uses a lock name of its own per install; the personal data eraser also removes the address. Freshly issued recovery codes are stored encrypted. The excerpt sent to the AI second opinion also loses bearer tokens, positional random tokens and password values. Answers from shieldwave.io and WordPress.org have size limits, feed rules are tested for cost before use, and the detection of encoded files keeps to the time budget.
* The readme says more precisely what the sync, the AI second opinion and the checks send and to whom, names the theme information service, and says which translation is used for the shipped languages.
* Before release, the plugin went through a scan of a test site with the 200 most popular WordPress.org plugins and the plugins of five real sites, an update of a WordPress.org plugin, a premium plugin, a theme and WordPress core by FTP and through WordPress, and every check had to finish.

= 1.1.12 =
* Quarantine with restore for findings of the malware, PHP in uploads, core, file changes, plugin and theme checks. The file is stored encoded so it cannot run, and Restore puts back the same bytes.
* Block PHP execution in the uploads folder and send security headers, each with its own switch, off by default. On nginx and IIS, Settings shows the rule to add.
* Two-factor login can be required for chosen roles, with 0 to 30 days to set it up. Passkeys (WebAuthn) work as the second step. Sessions can be listed and ended everywhere, and an administrator's session length can be set.
* The suggested privacy text now describes what two-factor login and passkeys store for an account.
* Deleting the plugin also removes the quarantine folder, the passkey data and the uploads .htaccess block.
* Setting up an authenticator app asks for your password, and the owner gets an email for every new app. An account whose time to set up two-factor is over gets a code by email before the set-up screen.
* Changes that lower protection (higher login limits, a trusted proxy, the file editor back on, a longer session) ask for your password, wherever they are made.
* On a multisite network the plugin is network activated, so two-factor and login protection cover every site.
* Quarantine refuses files the site loads on every request, checks the site still works after a move, and puts the file back if it does not.

= 1.1.10 =
* Login protection: a limit per user name, a limit on password reset requests, trusted proxies as a list of addresses or CIDR ranges with a choice of header, and an email when an administrator's user name is locked.
* The activity log has its own table, its ordinary entries form a hash chain whose newest entry is recorded apart, so edited, deleted and cut-off entries are found, the retention is set in days and the log can be exported as CSV.
* Privacy: a suggested text for Settings > Privacy, and the WordPress personal data export and erasure tools cover the failed login records.
* The AI second opinion redacts more before anything is sent (IP addresses, paths, all DB_ constants, database connection arguments, secrets from 6 characters), never reads configuration, credential, backup, dump, log and ini files, and starts the excerpt of PHP in an image at the PHP tag.
* The banner that offers live protection now says that the AI second opinion sends redacted excerpts to shieldwave.io and its AI provider.
* The API key is stored encrypted when the server allows it.
* Deleting the plugin asks shieldwave.io to remove a connected site, and removes the tables, scheduled task and user settings this version adds.
* A record link in a vulnerability finding is shown only for known vulnerability databases.
* The readme describes what is sent and how often as the code does it: the threat feed and the lookups run every hour from WP-Cron, live protection has three features.
* Malware detection follows request input more precisely and no longer flags legitimate code. On a test site with 35 popular plugins, 5 themes and WordPress core (52,800 files) it flags nothing, and no file takes more than a fraction of a second. Large PHP files are analysed within a time and memory budget.
* File checks: a file that differs from its release only in line endings matches it, a change made by a recorded update is explained, and a real change stays reported until it is reviewed. Links to other sites and odd file names are one finding per place.
* Known vulnerabilities: when a fixed version exists but WordPress does not offer the update (a plugin closed on WordPress.org, a premium plugin, or an update source that has no newer version), the finding says so and gives the steps for that case.
* HTTPS: when the site address starts with http but every http address redirects to https, this is information, not a problem.
* Login and two-factor: turning two-factor off for the whole site needs the password or a code, a changed or reset password forgets the remembered browsers, wp shieldwave unlock <user> lifts a two-factor lock, and ?author= requests in any form no longer reveal a login name.
* Alerts, notices and log entries use calmer, more precise wording.
* Findings that name user accounts reach a connected shieldwave.io account without the names.
* Every text was reviewed again for natural wording in all 16 languages, and 23 unclear English texts were rewritten.

= 1.1.9 =
* Unused plugins can be deleted from their finding: tick the ones to remove (all are ticked) and confirm. It works like Delete on the Plugins screen, so each plugin's own uninstall runs. Only plugins in use nowhere are listed, never ShieldWave itself, and only for users who may delete plugins on a server where WordPress can write the files.
* On a multisite network, a plugin switched on for one site only is no longer reported as unused.
* Files that an older WordPress release left behind after an update are no longer reported as unknown PHP. Each one matches the checksums of the release it comes from; the check's summary counts them and nothing needs to be done. A PHP file that no release explains is still reported.
* Fewer false alarms on premium plugins: the storage index files All-in-One WP Migration writes itself, the html2canvas library in Elementor Pro, a base64 image saved with wp_upload_bits(), and $GLOBALS read with a fixed key as in BerlinDB (WP Rocket and others) and ACF Pro.
* An empty debug.log is not reported. A debug log the server refuses to hand out is a low note instead of a high finding; only a log that can really be downloaded stays high.
* A site that works over HTTPS but has http:// in Settings > General gets a low note instead of "Login and dashboard are not served over HTTPS".
* With TranslatePress active, findings no longer show its #!trpst# markers, and texts follow the language of the admin instead of the site.
* A new rule finds the cmd.exec remote-control backdoor family as critical, also outside the uploads folder. Every file is analysed again under the new rules.
* In the network admin the texts say "network" where a single site says "site".
* More room in the layout: a wider side margin, a calmer header with smaller tabs, a smaller headline and more space between sections. WordPress notices above the plugin are readable in dark mode.

= 1.1.8 =
* A scan no longer stops with an error on hosting whose PHP is built without the tokenizer extension (rare; it is on by default almost everywhere). Without it the malware rules match the raw text, as before 1.1.7.

= 1.1.7 =
* A finding about files now says where they are: "in the plugin X 2.3.0 (inactive)", "in the theme Y", "in WordPress's own files" or "in the uploads folder", and the advice fits that place. An inactive plugin is to be deleted, a plugin from WordPress.org reinstalled, a premium one replaced with a fresh copy from its author, a WordPress file reinstalled from Dashboard > Updates. The same goes into the email alert and into "Copy for your developer".
* Every finding has "Read more": a fuller explanation for a developer, where the file comes from, the steps with WP-CLI commands and how to check the fix worked, with a button that copies all of it. The plain message above stays as it was.
* An old copy of ShieldWave Security (2.x or 3.x) left in the plugins folder is no longer reported as malware. Its scanner lists the names of known webshells as text to look for, which read like a webshell. Code-pattern rules now count only where the pattern is code, not inside a string or a translated sentence; real backdoors are still found.
* After a scan, the Overview asks once whether to turn on live protection, with a link to what is sent. "Not now" hides it for 30 days. Nothing is turned on without the click.
* Translations shipped with the plugin now win over an older language pack from translate.wordpress.org, which only fills what the plugin lacks. On Polish sites some sentences showed in English and corrected wording never appeared.
* An empty threat feed says that it has nothing beyond the built-in rules yet, instead of showing three zeros.
* Many screen fixes: the layout is centred on wide screens, titles wrap instead of being cut off, form fields and the selected option read clearly in dark mode, notices above the plugin follow its theme, commands and settings fit a phone, the settings section list stays in view and marks the right section, changed settings that are not saved yet are marked and leaving asks first, no glow under buttons, and one-letter words no longer end a Polish line.
* The link to this site on shieldwave.io opens "My sites".

= 1.1.6 =
* On a multisite network the ShieldWave screens are styled again. In the network admin WordPress names the screen differently from a single site, so the plugin did not recognise its own screens there: the stylesheet did not apply (plain lists, tiny text), History and Settings opened as the Overview, and the footer line was missing.
* WordPress itself is no longer reported as vulnerable for two old records that match every version and that WordPress has never fixed (a blind server-side request through pingbacks and activation keys stored in plain text). An up-to-date site was told "WordPress has 2 known vulnerabilities" and to wait for a fix that is not coming. A real vulnerability in WordPress is still reported with the release that fixes it.
* A WordPress release that WordPress.org marks as insecure is reported with the secure release of its branch, even before the vulnerability databases have a record for the fix.
* A vulnerability in WordPress itself with no fixed release no longer offers the Plugins screen.

= 1.1.5 =
* The site and shieldwave.io agree on a language. When the site connects, the plugin tells shieldwave.io the site's language; an account that has not chosen one yet takes it over, so the emails, reports and dashboard of shieldwave.io come in the language the site already uses. The account's language is shown next to the account under Settings and follows a change made in the dashboard within the hour.

= 1.1.4 =
* Known-vulnerability checks and the threat feed now run every hour instead of every three, so a vulnerability disclosed for one of your plugins or themes is reported, and emailed if alerts are on, within the hour. The lookups are cached on shieldwave.io, so the extra runs cost your site almost nothing. An existing schedule is moved to the new rhythm on update.

= 1.1.3 =
* A plain image in the uploads folder is no longer reported as an unknown PHP file. With "Images" switched on in Extra checks, every picture was listed as a high finding (a shop with 200 product photos saw all 200), and the email alert went out for them. An image is now reported only when ShieldWave actually finds PHP code inside it, which it still does.

= 1.1.2 =
* The screens keep the size of the WordPress admin on large monitors. Since 1.0.3 the whole plugin was enlarged on windows wider than 1920 pixels (a third bigger at 2560); now a wider window gives the lists more room instead of bigger letters. Only a 4K window at 100% scaling gets one small step up.
* The header, the status band, the lists and the footer share one left and right edge, and the light under the current tab sits exactly on the header's bottom line.
* A tidier header: a slightly lower headline, the theme switch and Scan now in the same rounded shape.
* More bot traffic in the simulation on the planet, most of it aimed at your site, also when the system asks for less motion.

= 1.1.1 =
* The automatic scan stays on the hour you chose. It kept its old clock time after the clocks changed or after you picked another time zone under Settings > General, so "At 03:00" could sit beside "Next scan at 02:00". Every run now plans the next one from your site's own time. On the one day the clocks skip the chosen hour, the scan runs right after it; when an hour happens twice, it runs once, the first time.
* The update replaces the schedule of 1.1.0 at once, and nothing is scheduled twice.
* The weekly summary follows your site's clock in the same way.
* The hours in the list under "At" use your site's time format, the same as "Next scan", and "today" and "tomorrow" are right on the days the clocks change.
* "See plans" opens the pricing page with the Pro plan selected.
* After a scan, the Overview shows one plain line about the free outside check at shieldwave.io, with your domain filled in. There is nothing to dismiss, and nothing is sent unless you click it.
* Every link from the plugin to shieldwave.io carries the tags utm_source=wordpress, utm_medium=plugin and utm_campaign=(the screen the link is on), which tell shieldwave.io only which link a visit came from.

= 1.1.0 =
* Connect with shieldwave.io in one click, from Settings or the Overview: sign in or create a free account there, press "Connect this site" and you are back. Pasting an API key still works, under "Use an API key instead".
* A free shieldwave.io account shows one site in the dashboard, with its score and open problems.
* While connected, shieldwave.io confirms that the domain is yours from an invisible tag on the home page, so its full outside scan can run on the site.
* Disconnecting removes the site and its results from shieldwave.io, and a copy of the site at another address (a staging copy) shows as a site of its own.
* The dashboard shows the AI second opinion on a file, and problems you ignored as ignored.
* Known vulnerabilities: plugins whose folder name has capital letters are matched again, and one plugin the lookup cannot read no longer stops the check for all the others.
* The old ShieldWave Security from shieldwave.io and this plugin can be installed side by side without losing anything: deactivating or deleting one leaves the settings, results, schedule and two-factor set-ups of the other alone, and a notice says how to remove the old copy.
* Problems about administrator accounts are sent to the dashboard without the account names, and the texts about what is sent say exactly that.
* "Turn all of it on" beside Live protection on the Overview works without JavaScript too.

= 1.0.3 =
* A clearer Overview: every group of problems has its own heading above its list, a row shows the name of the problem, and everything else opens with a click.
* The tabs in the header are easier to see, and the Settings tab shows how many protections are still off.
* The look of shieldwave.io: its colours, and its planet beside the status of your site. The planet marks where your site is and shows a simulation of typical bot traffic; a button beside it stops the motion.
* The screens grow with the window on large monitors, and buttons are easier to hit on phones.
* "New" marks a problem only when some problems are new and others are not.
* When a problem has no WordPress screen to open, "Copy for your developer" is the main button.
* No request for a review while something urgent is open.
* "Turn on" beside Known vulnerabilities opens the right part of Settings, and the time of an AI second opinion no longer says "ago" twice.
* In the dark theme the hour of the automatic scan stays readable while its list is open, and switches that are off have a visible edge.

= 1.0.2 =
* Emails display correctly in Outlook on Windows: the button keeps its padding, the fonts stay the same in every part of the message, and a long file path wraps instead of widening the message.
* The ShieldWave mark in emails is in the brand colour, so it shows in Outlook's dark mode too.

= 1.0.1 =
* Translated into Arabic, Chinese (Simplified), Dutch, French, German, Indonesian, Italian, Japanese, Korean, Polish, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish and Vietnamese.
* Right-to-left layout for Arabic and other right-to-left admin languages.
* The ShieldWave mark in the plugin's header and admin menu, the same as on shieldwave.io.
* Alert emails carry the ShieldWave mark (embedded in the email, nothing is loaded from outside), a clearer layout and a right-to-left layout for Arabic.
* After a few scans, the Overview asks once whether you would review the plugin on WordPress.org. "Later" and "Do not ask again" are remembered per administrator.

= 1.0.0 =
* First release in the WordPress.org directory.
* Builds downloaded earlier from shieldwave.io were numbered up to 3.6.6. To switch, deactivate and delete that copy, then install this one; the first scan starts the file history again.
