Vigilant – 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner…

Changelog

3.0.13

Closes wp-content/upgrade, where WordPress unpacks updates, to web requests and checks it in Security Check. Watches the secrets.php drop-in, logs changes to WordPress secrets and explains two factor errors after new security keys.

• Improved: a new Update Folders setting in Firewall, Server Protection, on by default, closes wp-content/upgrade and wp-content/upgrade-temp-backup to web requests. WordPress unpacks every update there before moving it into place, and CVE-2026-119977 was exploited by calling a file of a WordPress update while it was being unpacked; the update to the version that fixes it is still unpacked by the code it replaces, so a firewall inside WordPress cannot see that request. Vigilant writes two rules, so the block holds when a .htaccess further down switches rewriting on, ignores case and repeated slashes, and follows a content folder renamed inside the WordPress folder. Existing sites with the Firewall module on get it when they update, without saving anything. Nginx does not read .htaccess, and a server that hands PHP files to PHP-FPM with ProxyPassMatch does not read it for them: there, block those two folders in the server configuration. The new Security Check row says which case a site is in.
• Improved: Security Check has a new row in Sensitive files that asks the server for a PHP file that does not exist inside wp-content/upgrade and for one outside it, and passes only when the first is refused and the second is not. A server that refuses both is not scored, because it cannot be told apart. Sensitive files now scores out of 10.
• Improved: File Integrity watches wp-content/secrets.php, the drop-in WordPress loads on every request where it has the Secrets API, as it watches wp-config.php and .htaccess: it says when the file appears, changes or goes, and asks you to approve it. Its lines are never stored, only a fingerprint keyed with the security keys of wp-config.php and its size, because it can hold the credentials of a secrets store. A site that already has one is asked once, and so is a site whose security keys are replaced, because the fingerprint is keyed with them. Approving takes the file as the scan saw it: if it changed since, scan again. On a network, approving or ignoring it takes a network administrator.
• Improved: the activity log records every change to a secret of the WordPress Secrets API, with its name and never its value. A secret that goes back within a day to a value it had and that was replaced by another is logged as critical, so the audit alerts can send it: putting back a key that was rotated is what somebody who knew the old one would do. Deleting a secret and creating it again with the same value is not.
• Improved: when the codes of an authenticator app can no longer be checked because the security keys of wp-config.php were replaced, the two factor screen says so and points to the backup codes, and the activity log says why. It used to say Authentication error.
• Fix: after ignoring a file in File Integrity, the list of ignored files shows it right away. Until now the count above the list said one more than the table until the page was reloaded. Reported by Juan Díez.
• Fix: after approving a change to wp-config.php or .htaccess in File Integrity, its line changes no longer stay open on screen until the page is reloaded.

3.0.12

Fixes the IP login lockout and the activity log on servers that report table names in lower case, adds a daily limit to wrong two factor codes, saves old browser versions in the User-Agent blacklist again and uses SAMEORIGIN in the Maximum preset.

• Improved: an account now also stops for up to a day after 20 wrong two-factor codes in 24 hours, besides 10 in 15 minutes, so someone who has the password can no longer keep sending codes just under the limit: 600 in a month at most, where 28,800 got through before. A correct code ends the stop, and a new password starts the day again. The login screen and the email say how long the wait is. Reported by @calzbert.
• Improved: the Maximum Security preset now sets X-Frame-Options to SAMEORIGIN instead of DENY, and frame-ancestors to self. DENY also blocked the frames of the dashboard itself, such as plugin details, the progress of updates and the Customizer preview, and SAMEORIGIN protects from clickjacking just the same. Sites that applied the preset keep what they have: choose SAMEORIGIN in Security Headers to change it.
• Improved: User-Agent blacklist lines with an old browser or system version, such as Chrome/49.0.2623, Firefox/3.6 or Android 4.4, are saved again and no longer flagged: they only block that old version, a common sign of a bot. A version cut short that matches browsers in use, such as Chrome/15, is still left out. Reported by @calzbert.
• Improved: code that writes the settings, such as a network sync, can now learn which blacklist lines were left out through the vigilante_firewall_lines_dropped action. Requested by @calzbert.
• Fix: on servers that report table names in lower case, such as MySQL with lower_case_table_names set to 1, and with a table prefix in capitals, Vigilant took its own tables for missing. Failed logins were not counted, so the login lockout by IP never started, and the activity log and the file hashes stayed empty. Reported by @calzbert.
• Fix: some lines that normal browsers send could still be saved to the User-Agent blacklist and blocked the people using them: a piece cut in the middle of a browser name, such as rome/120.0.0.0, or of the Android device or the Linux processor, the whole User-Agent of a newer Firefox for Android, and lines of browsers Vigilant had no example of: Edge and Opera on Mac, Opera on Android and Opera Mini, Yandex, Huawei, UC, Xiaomi, Amazon Silk, DuckDuckGo, the browsers inside the Facebook, Messenger, Instagram, Google, WeChat, TikTok, LinkedIn, Pinterest, Telegram, Snapchat and LINE apps, including the fields they fill with the language or the network of each person, KaiOS phones, LG and Samsung TVs, PlayStation and Xbox. Windows 7 and 8.1 lines, such as Windows NT 6.1, are no longer saved either, because Chrome 109, Firefox ESR and newer Chromium forks still run there; Windows XP and Vista lines still are. A line that names a bot or a testing tool, such as LinkedInBot, Lighthouse or GTmetrix, is still saved, and so is a combination no browser sends, such as a current Chrome on an old macOS. A very long line no longer slows down the Dashboard and the Firewall tab.
• Fix: on a network, the email about a two-factor stop could be sent again from each subsite for the same run of wrong codes. It is now sent once a day at most for the whole network while the codes keep coming, and again after a new password. Reported by @calzbert.
• Fix: on a network, deleting a user could leave their authenticator secret and backup codes in the table kept from a deleted subsite. Reported by @calzbert.

3.0.11

The User-Agent blacklist no longer saves lines that normal browsers or WordPress also send, which locked people out; saved ones keep working and are flagged. Sections now fold, with summaries and an index. Also fixes the author scan block with NextGEN Gallery and a percent sign in headers.

• Improved: the User-Agent blacklist no longer saves a line that normal browsers, your own browser or WordPress itself also send, because it blocks the people who use them or stops the site from reaching itself. Chrome and Safari send the same User-Agent to everybody on the same version and system, and bots copy it, so a line taken from such a bot blocked every visitor with that browser. The notice says what each line would block and suggests blocking the IP instead. A line that blocks Googlebot or Bingbot is saved with a warning.
• Improved: lines of that kind saved with an earlier version keep applying, and the Dashboard and the Firewall tab now point them out. They are left out the next time the Firewall tab is saved.
• Improved: importing settings leaves out those User-Agent lines too, and IP blacklist entries that are an address of the site, and says which ones.
• Improved: the activity log popup no longer offers to blacklist a User-Agent. It checks the lists as the firewall does, IP ranges and part of a User-Agent included, says which line matches, and a request blocked by the User-Agent blacklist now records the line that blocked it.
• Improved: adding an IP or a User-Agent to a list from the activity log now leaves an entry in the log.
• Improved: the User-Agent whitelist is now called User-Agents not treated as bots, and its description says what it does: it exempts them from Block Bad Bots and nothing else.
• Improved: settings sections, and the groups inside them, fold from their heading, and the heading says what they hold even when folded: how many options are enabled, how many entries a list has, the mode chosen, or what the block shows, such as notifications active, IPs blocked or the date of the last scan. The browser remembers what you folded.
• Improved: an error is marked on the heading of the section that holds it and in the section index, and opens that section on every load. A warning is marked on the folded heading that hides it.
• Improved: tabs with three or more sections get an index on the left with Open all and Close all, which marks the section you are reading. Links to a setting, from the settings search, Security Check or the Dashboard, open a folded section first.
• Improved: in File Integrity, Run Scan Now and Clear Previous Results are now in the results block, which always shows, also before the first scan. Save buttons that only save one section fold with it.
• Improved: the rows of the self-protection box and of the Security Check breakdown remember whether you left them open, except a critical self-protection row, which always opens. Pending registrations show their count in the heading instead of an orange badge.
• Improved: File Integrity keeps the Ignored Files section on screen when the list is empty, and says so. Ignoring files, taking them off the list and emptying it are now recorded in the activity log, with how many files and which ones. The confirmations say how many files they take, selections on other pages of the table included, and the button that empties the whole list says how many it removes.
• Fix: in .htaccess, a User-Agent whitelist entry also exempted requests from the rules against malicious query strings and unused HTTP methods. Any client can send any User-Agent, so it now only exempts from the bad bots rule, as it already did in PHP.
• Fix: a percent sign in a security header value reached .htaccess as a format of the server, which could stop the whole site with an error or put a server variable in a public header. It is now written as a plain percent sign.
• Fix: with NextGEN Gallery active, ?author=N still redirected to the author page and showed the username, with nothing in the log. The block now runs before any plugin can redirect.
• Fix: when ?author=N still showed the username with the protection on, Security Check blamed a cache without checking. It now asks again past any page cache, tells a cache from something on the site that redirects first, and says so when it cannot tell.
• Fix: Security Check missed generator meta tags with their attributes in another order, such as the one Divi prints, and now names the tag it finds.
• Fix: unchecking User changes in the activity log also stopped logging blocked author scans, blocked insecure usernames and the session limit, and their audit alerts.
• Fix: deleting a user left their two-factor data, the authenticator secret and backup codes included, in the tables of Vigilant.

3.0.10

Two factor now stops an account after 10 wrong codes in 15 minutes and emails its holder, Ignore applies to the file as it is when ignored, and the visitor IP is read right behind proxies that add the port, such as Azure.

• Improved: Ignore in File Integrity now applies to a file as it is when it is ignored: if it changes, goes away or comes back, its finding shows again and the file leaves the ignored list. Excluded Paths is still the way to stop watching a file or a folder for good. Files ignored with an earlier version of Vigilant show once more, to be ignored again.
• Improved: only one File Integrity scan runs at a time. Run Scan Now says when another scan is already running and since when, the scheduled scan leaves it to the one that is running, and a scan the server stops is always the one reported.
• Improved: Security Check asks for the home page once per scan also when it does not answer or answers with a verification screen, instead of once per check that reads it.
• Fix: two-factor verification had no limit per account. The tries of each verification session started again with every correct password, and the lockout of Login Security counts per address and does not run on a site of a network where that module is off. Each account now has 10 wrong codes in 15 minutes, by app or by email, counted across sessions and addresses; then verification stops until that time passes, and the account holder and the site recipients get an email, because every one of those codes came with the right password.
• Fix: behind a proxy that writes the port in X-Forwarded-For or X-Real-IP, as Azure App Service does, every visitor was read as the proxy, for the firewall, the rate limit, the login lockout and the IP lists, and the notice that detects a proxy did not show. The port is now set aside, and the IP whitelist rules of .htaccess accept it too.
• Fix: on a site whose WordPress lives on a host of its own, the redirect to set up the authenticator app once the grace period ended went to the dashboard, which redirected again, in a loop. The Activity Log and File Integrity menu shortcuts landed on the dashboard there too.
• Fix: Remove X-Powered-By and Server headers now also removes an X-Powered-By header added by the server configuration, such as PleskLin on Plesk. Security Check no longer calls a value without a version number version information, and when the header still arrives with the rules of Vigilant applied, it says that the server adds it outside .htaccess.
• Fix: on a network, deleting a site now also removes Vigilant’s tables for that site, its activity log included. The two factor table stays while it holds an enrolment, because accounts belong to the network.
• Fix: the IP blocklist of Comment Security, which only code can fill, compared the connection address as text. It now reads the visitor IP and matches the list as the firewall does.

3.0.9

Security Check now says when the PHP of the server lacks the fixes of PHP2Shell, the critical flaws of October 2026, and the firewall blacklist no longer accepts an address of the site itself, which stopped WP-Cron.

• Improved: Security Check has a new row in Internal Checks, PHP security fixes, that compares the release of PHP, and not only its branch, with the critical security releases of PHP that Vigilant knows about. The first one is PHP2Shell (CVE-2026-109618 and CVE-2026-109619, October 2026), fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. An older release of those branches fails, and so does a branch that no longer gets fixes. A release marked by a Linux distribution, which can carry fixes without changing its number, also on a branch PHP no longer fixes, and a test release are a warning, because the number cannot tell. Until now a site on PHP 8.5.3 passed, so a site with an older PHP gets a lower score until PHP is updated, and the weekly scan, where its email is switched on, reports the row as a new failing check.
• Improved: the hidden login answers wp-login.php, wp-admin and the login shortcuts with one same page, the 404 page of the theme, as an address that does not exist gets it, so they cannot be told apart from a missing page. Until now wp-login.php showed the theme and wp-admin a plain page, and comparing them showed that something was there. Vigilant keeps a copy of that page, taken by asking the site for a missing address and renewed every day, after a theme switch and after updates; while there is none, every path gets the same plain page.
• Fix: with a custom login URL, /login.php answered with a redirect to the hidden login address, because WordPress sends that address to the login page and Vigilant only blocked /login and /wp-login.php. It now gets the same not found page as the rest.
• Fix: an address of the site itself could be put in the firewall blacklist: a loopback address, the address of the server or the one its domain points to. The requests WordPress sends to itself come from one of them, so WP-Cron stopped and the REST API test of Site Health failed with nothing on screen to say why. Saving the Firewall tab now leaves such an entry out, also one saved before, and says so in a second notice; the button of the Security Audit refuses it; and the Dashboard recommends removing one that is already saved.
• Fix: on a hosting that disables gethostbynamel() or gethostbyname(), the blacklist checks of Security Check stopped it with a fatal error, and its weekly run with it. They now say that the hosting disabled that function of PHP and are skipped.
• Fix: the password expiry setting could be saved at 0 days through an import or a request that skipped the limits of the field, and then every password with a date had expired. It can no longer be saved below 7 days, the minimum on screen, and a 0 saved before is read as 7.
• Fix: where PHP counts its time limit in clock time, as on Windows, a File Integrity scan fitted to a short limit could start a request for checksums that waited longer than the time left, and the server stopped the scan before it saved its result. That wait now shrinks to the time left. Where PHP counts processor time, the time used by other tasks of the same scheduled run now counts too, so the closed plugins check does not start with less time ahead than it needs.
• Fix: with the wp-includes folder linked from another place on the server, the alert about self-protection switched off by a filter could name a file of WordPress itself again.
• Fix: with Content-Security-Policy in report-only mode, the Test Headers button said so twice.

3.0.8

Security Check tells a firewall verification screen, a stale cache and headers set only on files apart from a missing header. A File Integrity scan stopped by the server is now reported, and the scan fits the time limit of PHP.

• Improved: when a security header arrives more than once, Security Check says so in its row, because it is being sent from more than one place and only one should be left. The policy that Vigilant itself sends from PHP with upgrade-insecure-requests alone does not count as a repetition.
• Improved: Security Check also asks for the home page as it is generated now, and says when the copy that visitors get comes from a cache and does not carry the same security headers, so that the cache can be emptied.
• Improved: when a File Integrity scan is stopped before it can save its result, because PHP runs out of time or memory or the server cuts the request, the tab and Security Check say so, with the cause when PHP gives it, and the Security Audit records it. Until now such a scan left no trace.
• Improved: in the Security Audit, Escape closes the details popup, and the actions for the IP and for the User Agent are now in two separate blocks, each with its value and buttons that say what they act on, so that a User Agent is not blacklisted by mistake instead of the IP.
• Fix: Security Check took the verification screen of a firewall or an anti-bot service for the site. A challenge answered with 403 passed as a protected user list, a refused wp-cron.php or a protected file, and one answered with 202 as the home page. Those checks now say that they could not measure and whose screen it was, for the screens that can be told apart: the challenges of SiteGround, Cloudflare and AWS WAF, the block pages of Cloudflare, Sucuri, Imperva, DataDome and Wordfence, and the challenge of the Under Attack mode of Vigilant itself. A file or a page served with 2xx is never taken for a screen. The Test Headers button says the same.
• Fix: on a server that applies the header rules of .htaccess to files and not to the pages PHP generates, as some hosting with PHP as CGI does, Security Check said that mod_headers was not enabled. It now checks an image of WordPress and says what happens. A copy kept by a cache is told apart in the same way, and the policy that Vigilant sends from PHP no longer counts as a header of its .htaccess block that arrives.
• Fix: X-Content-Type-Options and Cross-Origin-Opener-Policy with a value other than the expected one were reported as missing. The row now says which value arrives and which one is expected.
• Fix: a blacklist that does not answer this server was reported as not listing the site. When the answer is empty, each list is now asked about the test entry it keeps listed on purpose, and an answer that is not a blacklist code, which some DNS providers give to every name, is no longer read as a listing.
• Fix: the Limit HTTP Methods option and the description of Under Attack promised to block TRACE. Apache answers TRACE before it reads .htaccess, so only the hosting can switch it off, and the option now says so.
• Fix: with self-protection switched off by a filter that returns __return_false, as in the example of SECURITY.md, the email and File Integrity named wp-includes/functions.php as the file that switched it off. A function or a method of WordPress itself, such as __return_false or is_admin, is no longer named, also when it is passed as a closure, and the steps say how to find the filter. A callback written as Class::method or an object that can be called is now traced to its file, and when something hooks the filter that cannot be traced to a file, the screens say so.
• Fix: in the Security Audit, a scheduled task created for the first time was explained as one that had disappeared, a critical entry listed every task restored in that pass instead of the ones that keep disappearing, and the entries about self-protection switched off or about its hooks removed had no explanation.
• Fix: a Content-Security-Policy with upgrade-insecure-requests alone, the one Vigilant sends from PHP, scored in Security Check as a full policy, and with CSP off in Vigilant it read as delivered by something other than Vigilant. It restricts nothing, so it no longer counts as a policy, and a site whose only CSP is that one loses those points.
• Fix: a Content-Security-Policy-Report-Only scored in Security Check as a policy in force. In that mode the browser reports what the policy would block and blocks nothing, so the row is now a warning with half the points, and when the policy is the one of Vigilant it says how to put it in force. The strictest preset sets CSP to report-only, so a site that applied it gets half the points of that row until the mode is turned off.
• Fix: the attempt to open the hidden wp-admin logged before translations load showed in English in a translated log. It is now translated when it is shown, older entries included.
• Fix: with WPML active, the hidden wp-admin answered a visitor with no session with a server error instead of a not found page, and left a fatal error in the PHP log on every visit. The page is now written without the template of WordPress, with the same text and the same 404, and always as an HTML page, where a request that asked for JSON or XML got the error in that format.
• Fix: the File Integrity scan saved its result only after asking WordPress.org about every installed plugin, so a server that stopped the request at that point lost a scan that had finished. It is now saved as soon as the files are checked, and when little time is left the closed plugins check is left to its daily run.
• Fix: the Run Scan Now button deleted the previous result before scanning, so a scan stopped halfway left the tab empty, and it ran with the memory limit of php.ini instead of the one WordPress gives the dashboard.
• Fix: the scan did not take the time limit of PHP into account, so on hosting that gives a request 30 seconds a scan could be stopped halfway. It now asks for more time and, when the hosting does not allow it, stops in time to save its result, measuring the time as PHP counts it on that server, and says so in the list of what it did not check.

For older changelog entries, please check the changelog.txt file