Vigilant · Version history
Vigilant changelog and version history
- Latest version
- 3.0.12
- Nov 8, 2026 (1 day ago)
- Releases
- 99
- since 2026
- In the last year
- 99
- about one every 3 days
- Tested up to
- WordPress 7.1.4
- PHP 7.4 or later
202699 releases
Vigilant 3.0.12Latest
Vigilant 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, a…
- 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 l…
- 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 ot…
- 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.
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 ver…
- 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 m…
- 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 whi…
- 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…
- 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.
Vigilant 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 PH…
- 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 compar…
- 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 scre…
- 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 c…
- 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.
Vigilant 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…
- 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…
- 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 l…
- 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 long…
- 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 n…
- 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 w…
- 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…
- 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…
- 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 le…
- 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…
Vigilant 3.0.7
- Scheduled tasks run again when a cron job calls wp-cron.php by its address. Saving WP Hardening no longer breaks a wp-config.php with a define over several lines, and PHP in uploads can no longer be reached in three ways that bypassed the rule.
- Improved: the Security Check row about wp-cron.php is informational and no longer scores. A request to that file only runs the scheduled tasks that are already due, so a reachable wp-cron.php is normal. When the server refuses it, the row says that a cron job calling its address gets the same answe…
- Fix: Protect wp-cron.php denied every request to wp-cron.php, including the cron job of a server that calls its address with wget, curl or the cron of a hosting panel, and the scheduled tasks stopped running. The option is retired, and Vigilant takes its rule out of .htaccess when it rewrites its r…
- Fix: Block Bad Bots turned away a cron job that calls wp-cron.php with wget (in .htaccess) or with curl, so on a server set up that way the scheduled tasks did not run. That list now lets requests to wp-cron.php through. Every other firewall rule still applies to them.
- Fix: with the Firewall module switched off, the Vigilant block of .htaccess kept the firewall rules in force: bad bots, bad query strings, HTTP methods, wp-config.php, sensitive files, directory listing and PHP in uploads, wp-includes, plugins and themes. It now carries only the Server Identity rul…
- Fix: importing settings with the Firewall module off removed that .htaccess block even when Server Signature or Remove Fingerprinting Headers asked for it, and deactivating and activating Vigilant left it out in the same case. The refresh after an update now also takes out a block that nothing asks…
- Fix: in a WordPress installed in a subfolder, or on a network by subdirectories, a restrictive Content Security Policy also reached the admin, because the exception for it only matched /wp-admin at the root of the domain. It now matches /wp-admin as a folder anywhere in the address, and no longer c…
- Fix: on PHP 8, with Under Attack on, a visitor could cause a fatal error on the challenge page by sending its redirect field as a list, and the same happened with redirect_to when a login with two-factor authentication started. Both are now read only as text.
- Fix: when the WordPress block of .htaccess had lost its END line, the notice and the log entry said that a Vigilant block was broken. They now name the WordPress block.
- Fix: saving the WP Hardening tab with a define() of wp-config.php written over several lines, such as WP_DEBUG, commented out only its first line and left the file with a syntax error that took the site down. Every line of it is commented now, a define() that shares its line with other code is left…
- Fix: saving WP Hardening commented out the constants of the owner that Vigilant manages, such as DISALLOW_FILE_MODS, DISABLE_WP_CRON, FORCE_SSL_ADMIN or WP_DEBUG_LOG, even when their setting was off, so they stopped applying with nothing in their place. Only the constants that the Vigilant block de…
- Fix: Vigilant wrote wp-config.php up to four times in a row to apply those settings, so a failure halfway left it changed. It now prepares the whole change, writes the file once with a lock and reads it back, and if the write is cut short it puts the previous content back.
- Fix: the rule that blocks PHP in uploads could be bypassed in three ways: a path after the file name (file.php/anything) ran the file, another letter case (file.PHP) served its source code or ran it, depending on the server, and an .htaccess with rewrite rules of its own in a folder of uploads, whi…
- Fix: each time Vigilant wrote its .htaccess rules it deleted the blocks named # BEGIN SECURITY HEADERS, # BEGIN 8G FIREWALL and # BEGIN ADDITIONAL PROTECTIONS, taking them for leftovers of an old version. No version of Vigilant wrote them: they are usually rules pasted from a guide or written by an…
- Fix: switching Under Attack on or off showed in File Integrity as a change to .htaccess, and its block was not checked for a missing marker before Vigilant wrote that file.
Vigilant 3.0.6
- Vigilant now tells you when it cannot write wp-config.php or .htaccess. Until now, saving said that the settings were saved while the constants or the server rules never reached the file.
- Improved: the wp-config.php section of the WP Hardening tab says when that file is not writable, or is kept one folder above WordPress, where Vigilant does not write it, for as long as that lasts. In amber while everything those settings ask for is already in force, and in red, naming the constants…
- Improved: the Server Protection section of the Firewall tab and the Security Headers tab say when .htaccess is not writable on a server that uses that file.
- Improved: while wp-config.php cannot be changed and some of the WP Hardening settings are not in force because of it, the Dashboard recommends looking at it and names the constants that are not applied.
- Improved: the notice about users awaiting approval no longer loads every one of them on each admin screen just to count them.
- Improved: a site that keeps wp-config.php or .htaccess read-only on purpose will see these notices too, in those sections and after saving those tabs. They are true there as well: no change made in those tabs reaches the file until it can be written.
- Fix: when wp-config.php could not be written, saving the WP Hardening tab or moving a module switch answered that the settings were saved, the constants never reached the file and nothing said so. Activating the plugin with the file not writable left it the same way. The save now shows a second not…
- Fix: the same happened with .htaccess. Saving the Firewall or the Security Headers tab, or switching one of those two modules on or off, with a .htaccess that is not writable now says that the server rules were not updated. It also says so, with the reason, when Vigilant leaves the file as it is fo…
- Fix: the description of the Maximum preset said that its Content Security Policy was set to report-only mode. The preset enforces it, and the description now says so.
- Fix: the Test Headers button said nothing when its request failed outright. It now shows an error.
- For older changelog entries, please check the changelog.txt file
Vigilant 3.0.5
Vigilant 3.0.4
Vigilant 3.0.3
Vigilant 3.0.2
Vigilant 3.0.1
Vigilant 3.0.0
Vigilant 2.11.12
Vigilant 2.11.11
Vigilant 2.11.10
Vigilant 2.11.9
Vigilant 2.11.8
Vigilant 2.11.7
Vigilant 2.11.6
Vigilant 2.11.5
Vigilant 2.11.4
Vigilant 2.11.3
Vigilant 2.11.2
Vigilant 2.11.1
Vigilant 2.11.0
Vigilant 2.10.5
Vigilant 2.10.4
Vigilant 2.10.3
Vigilant 2.10.2
Vigilant 2.10.1
Vigilant 2.10.0
Vigilant 2.9.9
Vigilant 2.9.8
Vigilant 2.9.7
Vigilant 2.9.6
Vigilant 2.9.5
Vigilant 2.9.4
Vigilant 2.9.3
Vigilant 2.9.2
Vigilant 2.9.1
Vigilant 2.9.0
Vigilant 2.8.0
Vigilant 2.7.0
Vigilant 2.6.4
Vigilant 2.6.3
Vigilant 2.6.2
Vigilant 2.6.1
Vigilant 2.6.0
Vigilant 2.5.1
Vigilant 2.5.0
Vigilant 2.4.1
Vigilant 2.4.0
Vigilant 2.3.0
Vigilant 2.2.0
Vigilant 2.1.1
Vigilant 2.1.0
Vigilant 2.0.0
Vigilant 1.14.1
Vigilant 1.14.0
Vigilant 1.13.1
Vigilant 1.13.0
Vigilant 1.12.2
Vigilant 1.12.1
Vigilant 1.12.0
Vigilant 1.11.1
Vigilant 1.11.0
Vigilant 1.10.1
Vigilant 1.10.0
Vigilant 1.9.0
Vigilant 1.8.0
Vigilant 1.7.2
Vigilant 1.7.1
Vigilant 1.7.0
Vigilant 1.6.1
Vigilant 1.6.0
Vigilant 1.5.5
Vigilant 1.5.4
Vigilant 1.5.3
Vigilant 1.5.2
Vigilant 1.5.1
Vigilant 1.5.0
Vigilant 1.4.2
Vigilant 1.4.1
Vigilant 1.4.0
Vigilant 1.3.2
Vigilant 1.3.1
Vigilant 1.3.0
Vigilant 1.2.3
Vigilant 1.2.2
Vigilant 1.2.1
Vigilant 1.2.0
Vigilant 1.1.1
Vigilant 1.1.0
Vigilant 1.0.4
Vigilant 1.0.3
Vigilant 1.0.2
Vigilant 1.0.1
Vigilant 1.0.0
Questions about Vigilant’s releases
What is the latest version of Vigilant?
3.0.12, released on Nov 8, 2026 (1 day ago). It’s tested up to WordPress 7.1.4 and needs PHP 7.4 or later.
How often is Vigilant updated?
99 releases in the last year, about one every 3 days. Its first release on WordPress.org dates from February 2026.
Know when your rivals ship
Track your plugin and its rivals: TrackWP sees each new release in the nightly snapshot and alerts you, with what it did to their rank.
Start freeRelease dates come from the day each version’s folder was made in Vigilant’s WordPress.org SVN repository; the notes from its readme’s changelog, as its authors wrote it.