| 1 |
=== Vigilant - 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner… === |
| 2 |
Contributors: fernandot, ayudawp |
| 3 |
Tags: security, firewall, 2fa, malware, scanner |
| 4 |
Requires at least: 6.2 |
| 5 |
Tested up to: 7.1 |
| 6 |
Requires PHP: 7.4 |
| 7 |
Stable tag: 2.11.8 |
| 8 |
License: GPL v2 or later |
| 9 |
License URI: https://www.gnu.org/licenses/gpl-2.0.html |
| 10 |
|
| 11 |
Premium WordPress Security - 100% FREE: Firewall, 2FA, Security Headers, Login and Malware Protection, File Monitor, Security Audit & more |
| 12 |
|
| 13 |
== Description == |
| 14 |
|
| 15 |
### Premium Security. Zero Cost. |
| 16 |
|
| 17 |
Vigilant provides enterprise-level WordPress security features completely free. No premium version, no upsells, no hidden features behind paywalls. |
| 18 |
|
| 19 |
Protect your site with a complete security suite: firewall, two-factor authentication, brute force protection, security headers, file integrity monitoring, closed plugin detection, malware detection, user management, security audit logging, under attack mode and much more. |
| 20 |
|
| 21 |
Once activated, Vigilant immediately applies firewall rules against common attacks (SQL injection, XSS, file inclusion), security headers, login attempt monitoring, XML-RPC blocking, WordPress version hiding and sensitive file protection (.htaccess, wp-config.php). |
| 22 |
|
| 23 |
### One-Click Security Presets |
| 24 |
|
| 25 |
Choose a preset and get protected instantly: |
| 26 |
|
| 27 |
**Standard** - Balanced security suitable for most websites. Enables all modules with sensible defaults that won't interfere with normal site operation. |
| 28 |
|
| 29 |
**Maximum Security** - Strictest settings for high-security sites. Tighter rate limits, stronger CSP rules, mandatory admin notifications. May require fine-tuning for some setups. |
| 30 |
|
| 31 |
You can always customize individual settings after applying a preset. |
| 32 |
|
| 33 |
== Under Attack Mode == |
| 34 |
|
| 35 |
Is your site under active attack? Activate Under Attack mode with one click and stop malicious traffic instantly: |
| 36 |
|
| 37 |
* **JavaScript challenge** - Every visitor must pass an automatic browser verification before accessing your site. Real browsers solve it in seconds, bots get blocked completely |
| 38 |
* **Aggressive rate limiting** - Requests limited to 30 per minute with 15-minute blocks for offenders |
| 39 |
* **HTTP method restriction** - Only GET, POST and HEAD allowed; PUT, DELETE, PATCH, OPTIONS and TRACE are blocked |
| 40 |
* **Empty user agent blocking** - Requests without a user agent header are rejected |
| 41 |
* **Full XML-RPC lockdown** during the attack |
| 42 |
* **REST API restriction** - Only authenticated users can access the REST API |
| 43 |
* **Auto-deactivation** - Mode turns off after 4 hours so you never forget it's on |
| 44 |
* **Email notifications** when the mode activates and deactivates |
| 45 |
* **HMAC-signed cookies** - Verified visitors get a signed cookie so they only see the challenge once |
| 46 |
|
| 47 |
Under Attack mode works independently from your preset configuration. Your regular settings are preserved and restored when the mode deactivates. |
| 48 |
|
| 49 |
== Two-Factor Authentication (2FA) == |
| 50 |
|
| 51 |
Add a second verification step to your WordPress login: |
| 52 |
|
| 53 |
* **Authenticator app (TOTP)** - Google Authenticator, Authy, Microsoft Authenticator or any TOTP-compatible app |
| 54 |
* **Email codes** - One-time 6-digit verification codes sent via email |
| 55 |
* QR code setup directly in user profiles |
| 56 |
* 10 backup codes for emergency access if you lose your device |
| 57 |
* Configurable grace period for users to set up their authenticator app |
| 58 |
* Trusted devices - optionally let users skip 2FA on recognized devices for 30 days |
| 59 |
* Role-based enforcement - require 2FA for administrators, editors or any role |
| 60 |
* Exclude specific users from 2FA requirements |
| 61 |
* Admin tool to reset TOTP for users who lost their authenticator |
| 62 |
* Configurable code expiry, attempt limits and email sender name |
| 63 |
* User notification emails when 2FA is enabled or the method changes |
| 64 |
|
| 65 |
== Firewall Protection == |
| 66 |
|
| 67 |
Block malicious requests before they reach WordPress: |
| 68 |
|
| 69 |
* SQL injection blocking |
| 70 |
* XSS (Cross-Site Scripting) attack prevention |
| 71 |
* File inclusion protection (LFI/RFI) |
| 72 |
* Directory traversal blocking |
| 73 |
* Bad query string filtering (catches generic suspicious patterns the specific blockers miss) |
| 74 |
* Bad bot detection and blocking |
| 75 |
* Block requests with empty user agent |
| 76 |
* Rate limiting against DDoS and brute force, with optional progressive lockouts |
| 77 |
* IP whitelist and blacklist management (IPv4 and IPv6, with CIDR ranges and wildcards) |
| 78 |
* User-Agent whitelist and blacklist with partial matching |
| 79 |
* Visitor IP detection control - read the real IP directly from the connection (a spoof-proof default) or from a proxy header when behind Cloudflare, a reverse proxy or a load balancer, with an admin notice if a proxy is detected but not configured |
| 80 |
* HTTP method restriction |
| 81 |
* Server-level file protection via .htaccess: block direct access to wp-config.php, .htaccess, wp-includes/ and sensitive files (.log, .sql, .bak, .ini, debug.log, readme.html, etc.), and optionally wp-cron.php external access |
| 82 |
* Block PHP execution in /uploads (one of the most common post-exploit vectors) |
| 83 |
* Disable directory browsing |
| 84 |
|
| 85 |
== Login Security == |
| 86 |
|
| 87 |
Stop unauthorized access attempts: |
| 88 |
|
| 89 |
* Limit login attempts with configurable thresholds |
| 90 |
* Progressive lockouts - longer blocks for repeat offenders |
| 91 |
* Custom login URL - hide wp-login.php from bots |
| 92 |
* Login URL change notifications to all admin-area users |
| 93 |
* Hide login error messages - don't reveal valid usernames |
| 94 |
* XML-RPC control: leave it on, block only the pingback methods (recommended, it closes the amplification vector while the mobile app and Jetpack keep working), or disable it completely |
| 95 |
* Application passwords control |
| 96 |
* Email notification when an IP is blocked for exceeding login attempts |
| 97 |
* Admin login notifications via email |
| 98 |
* IP whitelist for trusted locations |
| 99 |
|
| 100 |
== User Security == |
| 101 |
|
| 102 |
Comprehensive user account protection: |
| 103 |
|
| 104 |
* Block insecure usernames (admin, test, root, etc.) on new registrations |
| 105 |
* Warn about existing users with insecure usernames so you can rename or remove them |
| 106 |
* Block author scanning - intercept `?author=N` URLs so WordPress doesn't redirect them to `/author/USERNAME/` and leak the login slug |
| 107 |
* Force strong passwords with minimum length |
| 108 |
* Password expiration with configurable intervals |
| 109 |
* Password history - prevent reusing old passwords |
| 110 |
* Force password reset - by specific users, by role, or all users (post-hack recovery) |
| 111 |
* Session limits - control concurrent logins per user |
| 112 |
* Session management - view and revoke active sessions |
| 113 |
* Email verification for new registrations |
| 114 |
* Registration approval workflow - manually approve new users |
| 115 |
* Admin account monitoring - alerts for new admins, email changes, password changes, privilege escalation |
| 116 |
* Display name protection - prevent exposing login username publicly |
| 117 |
|
| 118 |
== Security Headers == |
| 119 |
|
| 120 |
Achieve Grade A security ratings: |
| 121 |
|
| 122 |
* Content Security Policy (CSP) with a WordPress-compatible default policy and Report-Only mode for safe testing before enforcing |
| 123 |
* HSTS (HTTP Strict Transport Security) with includeSubdomains and preload options |
| 124 |
* X-Frame-Options - prevent clickjacking |
| 125 |
* X-Content-Type-Options - prevent MIME sniffing |
| 126 |
* Referrer Policy control |
| 127 |
* Permissions Policy (camera, microphone, geolocation, payment, USB) |
| 128 |
* Cross-Origin policies (COEP, COOP, CORP) |
| 129 |
* HTTPS enforcer with automatic mixed content fix |
| 130 |
* Server fingerprint hiding - the `Server:` header is neutralized and `X-Powered-By` and other fingerprinting headers are stripped from responses |
| 131 |
|
| 132 |
== File Integrity Monitoring == |
| 133 |
|
| 134 |
Detect unauthorized changes to your files and compromised plugins: |
| 135 |
|
| 136 |
* WordPress core verification against official checksums |
| 137 |
* Plugin and theme file monitoring with WordPress.org checksums |
| 138 |
* Critical config files (wp-config.php, .htaccess) monitored against baseline, detecting code injection even in files with no official checksum |
| 139 |
* Closed and removed plugins detection - daily check against the WordPress.org repository, flagging any installed plugin closed for malware, security issues or guideline violations, including both explicit closures and silent "removed" takedowns, with per-slug Ignore for legacy plugins you can't uninstall yet |
| 140 |
* Line-level diff view of changes, with per-file approval workflow |
| 141 |
* Suspicious code scanning for plugins and themes without checksums |
| 142 |
* Extra file detection in plugins and themes (files not in original distribution) |
| 143 |
* Uploads directory scanning for PHP files, double extensions and .htaccess, with smart classification of dangerous rules vs protective ones |
| 144 |
* Root directory scanning for non-core PHP files (common attack vector) |
| 145 |
* String concatenation obfuscation detection |
| 146 |
* Configurable notification levels and an ignore list to dismiss known files |
| 147 |
* Excluded paths and file extensions |
| 148 |
* Scheduled automatic scans (daily, weekly) |
| 149 |
* HTML formatted email alerts with severity sections, including a dedicated section for closed plugins |
| 150 |
|
| 151 |
== Security Audit == |
| 152 |
|
| 153 |
Track everything happening on your site: |
| 154 |
|
| 155 |
* Successful and failed login attempts |
| 156 |
* Two-factor authentication events |
| 157 |
* User account changes (creation, deletion, role changes) |
| 158 |
* Content modifications (posts, pages) |
| 159 |
* Plugin and theme activations/deactivations |
| 160 |
* Security events and blocked threats |
| 161 |
* HTTP request method tracking and filtering (GET, POST, PUT, DELETE) |
| 162 |
* Enhanced log detail popup with grouped sections and quick actions |
| 163 |
* One-click add IP or User-Agent to firewall whitelist/blacklist from log entries |
| 164 |
* Direct IP lookup links to AbuseIPDB |
| 165 |
* Configurable retention period, CSV export, and filtering by event type, severity, request method or date |
| 166 |
|
| 167 |
**Audit Alerts** - get an email when the audit log points to something worth your attention, off by default and configured under Security Audit: |
| 168 |
|
| 169 |
* Immediate alerts the moment a serious event is logged, by minimum severity (a new administrator, a closed plugin or a privilege escalation are all logged as Critical) |
| 170 |
* Threshold alerts when a category spikes - firewall blocks, login failures, user, plugin, file integrity, security, system and content events - over a 30-minute, 1, 6 or 24 hour window, counting only warning and critical events so routine activity never trips them |
| 171 |
* A single anti-repeat cooldown keeps a storm of events down to one notice instead of flooding your inbox |
| 172 |
* Active alerts surface in Settings & Tools, the Dashboard, the Configuration Score and the Security Check |
| 173 |
* "Send test email" button to confirm delivery |
| 174 |
|
| 175 |
== Security Check == |
| 176 |
|
| 177 |
On-demand security audit built into the Dashboard. No external services, no accounts, no API keys - everything runs on your server: |
| 178 |
|
| 179 |
* 40+ checks across 6 categories: SSL/TLS, HTTP Headers, WP Exposure, Access & Auth, Sensitive Files and Internal Checks |
| 180 |
* Single 0-100 score with A-E grade, plus per-category breakdown and explanatory details for every check |
| 181 |
* 15 exclusive internal checks impossible from the outside: PHP end-of-life status, pending updates, inactive plugins, closed or removed plugins, file permissions, default salts detection, `wp_` table prefix, `admin` username, administrators without 2FA enrolled, module status, recent audit errors, last File Integrity scan result and whether audit alerts are configured |
| 182 |
* DNS-only reputation lookup against Spamhaus ZEN, Barracuda BRBL and SpamCop SCBL (informational - listings are flagged but don't deduct from the score) |
| 183 |
* Two-phase scan: fast local checks appear in under a second, remote checks stream in as they complete |
| 184 |
* Weekly automatic scan with opt-in email alert if the score drops by 10+ points or a new critical check starts failing |
| 185 |
* 30-scan history with sparkline trend and delta chip |
| 186 |
* "Go to setting" fix link on every failing check, jumping straight to the exact Vigilant field that resolves it |
| 187 |
* Smart header diagnostics that report "configured but not being served" when a cache/CDN overrides your headers |
| 188 |
|
| 189 |
== WordPress Hardening == |
| 190 |
|
| 191 |
Layered protection at the WordPress level - admin, content, head, feeds and database: |
| 192 |
|
| 193 |
* Lock down the admin: disable the built-in plugin and theme file editor, block installations and updates from the admin area, and force HTTPS for the admin area. Compatible with any hosting layout, respecting values already in place and never overriding them |
| 194 |
* Disable WordPress's internal page-view cron when you already have a real server-side cron job configured |
| 195 |
* Dashboard warning when debug mode is left enabled in production, so error output never leaks to visitors |
| 196 |
* Hide your WordPress version everywhere it can leak: from the HTML head, from RSS and Atom feeds, and optionally from every script and style URL on the front-end (stripping only the WordPress version itself, leaving plugin and theme cache busting intact) |
| 197 |
* Automatic daily removal of readme.html, license.txt and licencia.txt from the WordPress root, which otherwise expose your version |
| 198 |
* HTML head cleanup - remove the RSD link, Windows Live Writer manifest, shortlink header and REST API discovery link |
| 199 |
* Database hardening - check for the default `wp_` table prefix and one-click rename tool with full backup before the change |
| 200 |
* Comment security - honeypot field against spam bots, force moderation on every new comment, close comments on old posts, disable pingbacks and trackbacks |
| 201 |
* Feed management - completely disable RSS and Atom feeds, or only disable them when the site has no published content |
| 202 |
|
| 203 |
== REST API Security == |
| 204 |
|
| 205 |
Control API access to your site: |
| 206 |
|
| 207 |
* Three access modes: public (default WordPress behavior), authenticated only (closes the API to anonymous visitors), or selective (custom allow/block lists) |
| 208 |
* Block user enumeration via `/wp-json/wp/v2/users` |
| 209 |
* Protect any list of sensitive endpoints from anonymous access |
| 210 |
* Per-plugin compatibility toggles so authenticated mode doesn't break the front-end: WooCommerce, Contact Form 7, Gravity Forms, WPForms, Elementor, Jetpack. oEmbed and Site Health endpoints stay accessible by default |
| 211 |
|
| 212 |
== Security Tools == |
| 213 |
|
| 214 |
Utilities included: |
| 215 |
|
| 216 |
* **Database Backup** - Download a full or partial database backup as ZIP with table selection |
| 217 |
* **Database Prefix Change** - Change the default wp_ prefix to a random secure prefix |
| 218 |
* **Export/Import Settings** - Transfer your configuration between sites |
| 219 |
* **Manual Backup** - Create backups of .htaccess and wp-config.php on demand |
| 220 |
* **Reset to Defaults** - Start fresh with one click |
| 221 |
|
| 222 |
== Safe by Design == |
| 223 |
|
| 224 |
Your existing .htaccess, wp-config.php and robots.txt are automatically backed up before any modifications. Backups are stored in the WordPress database, never as files under the web root, and verified with MD5 checksums. |
| 225 |
|
| 226 |
When you deactivate Vigilant, all security rules are automatically removed and your original configuration files are restored. No leftover code, no broken sites. |
| 227 |
|
| 228 |
== Why Vigilant? == |
| 229 |
|
| 230 |
Most WordPress security plugins reserve their best features for paid plans. Vigilant gives you everything upfront - no premium tier, no feature locks, no upsells. Firewall, 2FA with authenticator app, security headers, file integrity scanner, security audit, on-demand Security Check with weekly regression alerts, and more. All free, all maintained, all following WordPress coding standards. |
| 231 |
|
| 232 |
We maintain a detailed feature comparison between Vigilant and other popular security plugins (Wordfence, Solid Security, AIOS, Sucuri, SG Security). See what each offers in its free version and where Vigilant fills the gaps. |
| 233 |
|
| 234 |
→ [View the full comparison](https://vigilante.works/comparison.html) |
| 235 |
|
| 236 |
== Installation == |
| 237 |
|
| 238 |
1. Upload the plugin files to `/wp-content/plugins/vigilante/` or install directly from the WordPress plugin repository |
| 239 |
2. Activate the plugin through the 'Plugins' menu in WordPress |
| 240 |
3. Go to 'Vigilant' in the admin menu |
| 241 |
4. Apply a security preset or customize individual module settings |
| 242 |
|
| 243 |
**Requirements:** |
| 244 |
|
| 245 |
* WordPress 6.2 or higher |
| 246 |
* PHP 7.4 or higher |
| 247 |
* Apache or LiteSpeed server (for .htaccess features) |
| 248 |
* SSL certificate recommended for HSTS |
| 249 |
|
| 250 |
== Frequently Asked Questions == |
| 251 |
|
| 252 |
= Will this plugin slow down my site? = |
| 253 |
|
| 254 |
No. Vigilant is optimized for performance. The firewall uses efficient pattern matching, database queries are cached with transients, and .htaccess rules execute at server level before PHP even loads. |
| 255 |
|
| 256 |
= What happens when I activate the plugin? = |
| 257 |
|
| 258 |
Vigilant immediately backs up your existing .htaccess and wp-config.php to the database, then applies default security settings. All modules are enabled with balanced defaults suitable for most sites. |
| 259 |
|
| 260 |
= What happens when I deactivate the plugin? = |
| 261 |
|
| 262 |
All security modifications are automatically reverted. The .htaccess rules are removed, wp-config.php constants are restored to their original values, and scheduled tasks are cleared. Your site returns to its pre-Vigilant state. |
| 263 |
|
| 264 |
= How does two-factor authentication work? = |
| 265 |
|
| 266 |
Vigilant supports two 2FA methods. With the **authenticator app** (TOTP), you scan a QR code in your profile to link an app like Google Authenticator or Authy, then enter a 6-digit code from the app on every login. With **email codes**, you receive a one-time code via email after entering your password. If enabled by the site administrator, you can mark your device as trusted to skip 2FA for 30 days. |
| 267 |
|
| 268 |
= What if I lose my phone or authenticator app? = |
| 269 |
|
| 270 |
When you set up TOTP, Vigilant generates 10 backup codes. You can use any of them as a one-time replacement for the authenticator code. If you run out of backup codes, an administrator can reset your TOTP from the plugin settings. |
| 271 |
|
| 272 |
= What if I don't receive the 2FA email code? = |
| 273 |
|
| 274 |
Check your spam folder first. You can click "Resend code" on the verification form. Codes expire after 10 minutes by default. If issues persist, an administrator can temporarily disable 2FA from the plugin settings. |
| 275 |
|
| 276 |
= Can I switch between email and authenticator app? = |
| 277 |
|
| 278 |
Yes. Go to Login Security > Two-Factor Authentication and change the verification method. If notifications are enabled, affected users will receive an email explaining the new method and how to set it up. |
| 279 |
|
| 280 |
= Which user roles require 2FA? = |
| 281 |
|
| 282 |
By default, 2FA is enforced for administrators and editors. You can customize which roles require 2FA in the Login Security settings, and exclude specific users individually. |
| 283 |
|
| 284 |
= How do I recover if I'm locked out? = |
| 285 |
|
| 286 |
Access your site via FTP/SFTP and either rename the plugin folder to disable it temporarily, or delete the `vigilante_login_attempts` table rows for your IP address in the database. |
| 287 |
|
| 288 |
= Will the firewall block legitimate users? = |
| 289 |
|
| 290 |
The firewall is configured to allow normal WordPress operations, including the block editor, REST API, and popular page builders. If you experience issues, you can whitelist specific IPs or adjust rate limiting thresholds. |
| 291 |
|
| 292 |
= Can I use this with other security plugins? = |
| 293 |
|
| 294 |
While Vigilant works standalone, running multiple security plugins can cause conflicts. We recommend testing in a staging environment first if you need to combine security solutions. |
| 295 |
|
| 296 |
= Does this work with caching plugins? = |
| 297 |
|
| 298 |
Yes. Vigilant is compatible with popular caching plugins. The firewall runs before cache layers, and .htaccess rules don't interfere with caching mechanisms. |
| 299 |
|
| 300 |
= Does this work with WooCommerce? = |
| 301 |
|
| 302 |
Yes. Vigilant includes compatibility settings for WooCommerce. The REST API security module automatically allows WooCommerce endpoints, and the firewall won't block payment gateway connections. |
| 303 |
|
| 304 |
= How do I test my security headers? = |
| 305 |
|
| 306 |
Use the built-in header testing tool in the Security Headers tab, or visit securityheaders.com with your site URL to get a security grade. |
| 307 |
|
| 308 |
= What is Security Check? = |
| 309 |
|
| 310 |
Security Check is an on-demand audit built into the Dashboard. It runs 40+ checks across 6 categories (SSL/TLS, HTTP headers, WordPress exposure, access and authentication, sensitive files, and internal checks) and returns a 0–100 score with an A–E grade. Unlike external online scanners, it runs entirely on your server and has access to 14 exclusive internal checks: PHP end-of-life status, pending updates, closed/removed plugins, file permissions, default salts detection, administrators without 2FA enrolled, and more. |
| 311 |
|
| 312 |
= Does Security Check send my data to an external service? = |
| 313 |
|
| 314 |
No. All checks run on your server. The only external traffic is three DNS-only lookups against public blacklists (Spamhaus, Barracuda, SpamCop) for the reputation category — these are standard DNS queries with no authentication, no API keys, and no payload beyond your site's IP address. If you disable the reputation category, Security Check makes zero external network calls. |
| 315 |
|
| 316 |
= How often should I run Security Check? = |
| 317 |
|
| 318 |
Run it manually after any significant change (plugin update, server migration, new user role configuration). For ongoing monitoring, enable the weekly automatic scan from the widget. You'll only receive an email if the score drops by 10 points or more, or if a new critical check starts failing — so no spam from routine scans. |
| 319 |
|
| 320 |
= What is password expiration? = |
| 321 |
|
| 322 |
You can require users to change their passwords after a set number of days (30, 60, 90, etc.). Users receive warnings before expiration and are forced to change their password on next login when it expires. Password history prevents reusing recent passwords. |
| 323 |
|
| 324 |
= What is registration approval? = |
| 325 |
|
| 326 |
When enabled, new user registrations require manual approval by an administrator before the account becomes active. Pending users cannot log in until approved. You can configure auto-rejection after a set number of days. |
| 327 |
|
| 328 |
= What does email verification do? = |
| 329 |
|
| 330 |
New users must verify their email address by clicking a link before their account becomes active. This prevents fake registrations and ensures valid contact information. |
| 331 |
|
| 332 |
= How do session limits work? = |
| 333 |
|
| 334 |
You can limit how many concurrent sessions each user can have. When the limit is reached, either the new login is blocked or the oldest session is terminated, depending on your configuration. |
| 335 |
|
| 336 |
= Can I export the security audit log? = |
| 337 |
|
| 338 |
Yes. The security audit log can be exported to CSV format for external analysis or compliance reporting. You can also filter logs by event type, user, or date range before exporting. |
| 339 |
|
| 340 |
= What files does the integrity scanner check? = |
| 341 |
|
| 342 |
The scanner compares WordPress core files, plugin files, and theme files against official checksums from WordPress.org. Plugins and themes without available checksums are also scanned using strict obfuscation pattern detection. The uploads directory is scanned for PHP files, double extensions, and .htaccess files. Extra PHP files not present in original distributions are detected and, if they contain suspicious code, automatically flagged as suspicious. |
| 343 |
|
| 344 |
= I updated from a version that stored wp-config.php in the database. Is there anything else to do? = |
| 345 |
|
| 346 |
Previous versions kept a copy of wp-config.php in an option so the integrity scan could show which lines had changed, and that copy carried the database password and the eight authentication keys and salts. Updating removes the copy, but no update can undo an exposure that already happened. So if your database, or any backup of it, may have been read by somebody else while that copy was stored, replace the eight keys and salts in your wp-config.php with fresh ones from the WordPress.org secret-key service, and change the database password if your host lets you. Replacing the salts signs everybody out, yourself included, which is the whole point of doing it. |
| 347 |
|
| 348 |
= How often does the file integrity scan run? = |
| 349 |
|
| 350 |
You can configure automatic scans to run daily or weekly. You can also run manual scans at any time. Email notifications support three levels: all issues, suspicious files only, or disabled. |
| 351 |
|
| 352 |
= What is the difference between Standard and Maximum presets? = |
| 353 |
|
| 354 |
Standard applies balanced settings suitable for most sites. Maximum applies stricter rules: lower rate limits, tighter CSP policies, required admin notifications, session limits, and more aggressive hardening. Maximum may require adjustments for sites with complex functionality. |
| 355 |
|
| 356 |
= Where are backups stored? = |
| 357 |
|
| 358 |
Configuration backups (.htaccess, wp-config.php, robots.txt) are stored in the WordPress database, not as files under the web root, so they can never be served over HTTP. A database backup you download is generated as a temporary ZIP with an unguessable name and removed right after the download. |
| 359 |
|
| 360 |
= What is Under Attack mode? = |
| 361 |
|
| 362 |
Under Attack mode is an emergency feature you can activate when your site is experiencing an active attack. It adds a JavaScript challenge that real browsers solve automatically in a few seconds, while bots and automated scripts are blocked completely. It also applies aggressive rate limiting, blocks restricted HTTP methods, and restricts API access. |
| 363 |
|
| 364 |
= Will Under Attack mode affect my logged-in users? = |
| 365 |
|
| 366 |
No. Logged-in users, admin pages, cron jobs, AJAX requests, and the login page are all excluded from the JavaScript challenge. Only unauthenticated frontend visitors see the verification page. |
| 367 |
|
| 368 |
= What if I forget to turn off Under Attack mode? = |
| 369 |
|
| 370 |
It automatically deactivates after 4 hours. You will also receive an email notification when it activates and deactivates. |
| 371 |
|
| 372 |
= Does Under Attack mode change my regular security settings? = |
| 373 |
|
| 374 |
No. It operates independently from your preset configuration (Standard or Maximum). Your regular settings are untouched and continue working normally after Under Attack mode deactivates. |
| 375 |
|
| 376 |
= How does the database backup work? = |
| 377 |
|
| 378 |
Go to Vigilant > Tools > Database Backup. Select which tables to include (or leave all selected), then click Download. The backup is generated as a temporary ZIP with an unguessable name, streamed to your browser and deleted from the server immediately after the download. |
| 379 |
|
| 380 |
= What does changing the database prefix do? = |
| 381 |
|
| 382 |
WordPress uses wp_ as default table prefix. Changing it to a random prefix adds a layer of protection against SQL injection attacks that target default table names. Go to Vigilant > WP Hardening > Database Hardening. Always create a backup before changing the prefix. |
| 383 |
|
| 384 |
= How do I exclude management services like ManageWP from the firewall? = |
| 385 |
|
| 386 |
Go to Vigilant > Firewall > User-Agent Lists and add the service name (e.g., ManageWP, MainWP, UptimeRobot) to the User-Agent Whitelist. Partial matching is used, so entering "ManageWP" will match any User-Agent string containing that keyword. |
| 387 |
|
| 388 |
If you also use a custom login URL, add the management dashboard's IP address to the firewall IP Whitelist as well. Some operations (for example pushing a plugin update from MainWP) reach wp-admin without a WordPress session and with a generic WordPress user agent rather than the service name, so the User-Agent rule alone would not match them. A whitelisted IP is allowed past the hidden login/wp-admin protection (it still has to authenticate). |
| 389 |
|
| 390 |
= Can I send security notifications to someone other than the site admin? = |
| 391 |
|
| 392 |
Yes. Go to Vigilant > Settings & Tools > Notification settings. You can add additional email recipients (one per line) and optionally uncheck the WordPress admin email. This is useful for maintenance professionals managing multiple sites who need to receive all security alerts. |
| 393 |
|
| 394 |
= Can I customize notification recipients programmatically? = |
| 395 |
|
| 396 |
Yes. Use the `vigilante_notification_recipients` filter. It receives and returns an array of email addresses used for all administrative notifications: |
| 397 |
|
| 398 |
`add_filter( 'vigilante_notification_recipients', function( $recipients ) { |
| 399 |
$recipients[] = 'security-team@example.com'; |
| 400 |
return $recipients; |
| 401 |
} );` |
| 402 |
|
| 403 |
== Screenshots == |
| 404 |
|
| 405 |
1. Security Dashboard - Security score, module controls, and preset selection |
| 406 |
2. Two-Factor Authentication - Second verification step during login |
| 407 |
3. Login Security - Brute force protection, 2FA, lockouts, and custom login URL |
| 408 |
4. User Security - Complete user protection tools and settings |
| 409 |
5. Password Expiration - Force periodic password changes with history |
| 410 |
6. Registration Approval and Session Limits - Control new users and concurrent logins |
| 411 |
7. File Integrity - Scanner settings and verification results |
| 412 |
8. Security Audit - Filterable event viewer with export option |
| 413 |
9. Database Backup - Download full or partial database backups with table selection |
| 414 |
10. Security Check - On-demand audit widget with score, per-category breakdown, and fix links |
| 415 |
|
| 416 |
== Changelog == |
| 417 |
|
| 418 |
= 2.11.8 = |
| 419 |
Security fixes: the Under Attack challenge and its rate limit, the visitor IP behind X-Forwarded-For, secrets left in the integrity scan copy of wp-config.php, and several permission checks on networks. |
| 420 |
|
| 421 |
* Fix: in Under Attack mode, a visitor can no longer break the challenge of other visitors who share the same IP address. The challenge used a single nonce per address, reused by every page loaded from it, and any answer carrying that nonce deleted it before the proof of work was checked, so a client behind the same NAT, or any visitor when the site sits behind a proxy with no trusted IP header configured, could keep the others in a challenge loop by sending wrong answers. Each challenge page now carries its own signed token, tied to the address and to the time it was issued, which is checked without being stored or deleted, and serving the challenge no longer writes a transient for each address. Reported by the wordpress.org automated security review of 2.11.7. |
| 422 |
* Fix: the copy of wp-config.php that the file integrity scan keeps to show which lines changed now hides every text value in the code, not only the database credentials, the keys and salts and the constants whose name reads like a credential, and everything in comments except plain words. FTP_PASS, SMTP passwords, keys written inside serialize( array() ), any const, putenv() and the fallback after getenv() were stored as they were, within reach of anyone able to read the database or a backup of it, and the check that drops the copy when a secret survives only looked for the twelve WordPress constants; it now looks for every constant the file names and every environment variable it reads. The site address, folders, memory limits, table prefix and include paths stay readable in the diff, and when a value in force cannot be hidden safely the scan says so instead of showing the lines. The copy of the root .htaccess now hides SetEnv values, headers whose name reads like a credential such as Authorization or X-Api-Key, php_value settings that look like a credential and keys compared in RewriteCond. Copies already stored are cleaned the first time an admin page loads or a scan runs on each site after updating, and so are the lines kept in the last scan results; on a network they are also cleaned on every site when a network administrator opens the dashboard of the main site, sites nobody opens included. The lines of wp-config.php are shown again after the next scan. Present since 2.11.2, the version that started redacting this copy. |
| 423 |
* Fix: on a network, the changed lines of wp-config.php and the root .htaccess are only shown to network administrators, on the main site. The scan of every site with file integrity on worked them out, stored them in that site's options and showed them to its administrator, and on the main site they were also shown to administrators without network rights, while approving the change has needed a network administrator since 2.11.3. Everybody else still sees that the file changed and its size before and after, with a note saying where the lines are. |
| 424 |
* Fix: with visitor IP detection set to X-Forwarded-For, Vigilant now reads the visitor address from the end of the header, where the proxy writes it, and not from its first entry, which the visitor writes. By sending the header, anyone could be taken for an address of their choice: out of the IP blacklist, into the whitelist, which skips the firewall, the Under Attack challenge and the hidden login URL, and with a new address on every request for rate limiting and login lockouts. Addresses of your own network at the end of the header (private, loopback, link-local and the shared 100.64.0.0/10 range) are taken as proxies and skipped, an IPv4 address written as IPv6 is read as IPv4, and a list in CF-Connecting-IP or X-Real-IP is read the same way. Behind a CDN with a reverse proxy in front of PHP that adds to the header, or behind a load balancer that adds its own public address, every visitor is now seen with the address of that CDN or balancer, so choose the header of the CDN if it has one; the Firewall tab warns when your own request shows that shape. The whitelist exceptions written in .htaccess now match the last address of the header. Present since 2.7.0, which added the setting. |
| 425 |
* Fix: in Under Attack mode, a visitor who passed the challenge is no longer exempt from rate limiting. The exemption lasted as long as the mode, and the proof of work takes a script a few milliseconds, so a bot could solve it once and then send requests without any limit. Verified visitors now get 300 requests per minute, or the limit set in the firewall if it is higher, while everybody else keeps 30, and they are counted apart from the unverified visitors at their address, so a client that gets that address blocked does not block them. |
| 426 |
* Fix: the HTTP method filter of the firewall no longer lets a request through because /wp-json/ appears anywhere in its address, the query string included. Only addresses under the REST API path of the site skip it. |
| 427 |
* Fix: on a network, an administrator without network rights can no longer add wp-config.php or the root .htaccess to the ignore list, and that list no longer hides a change to either file. The administrator of the main site could close the warning about a change that only a network administrator can approve by sending the file name to the ignore action. Clearing the scan results now keeps that warning too, for anyone who cannot approve it, and on the main site turning off the critical-file scan, whether its own switch or the whole File Integrity module, is no longer available to an administrator without network rights, since that silences the same warning. |
| 428 |
* Fix: on a network, switching Under Attack mode on only purges caches when a network administrator does it. The purge empties the object cache, asks the cache plugins to clear their caches and deletes the SiteGround Optimizer cache folder, most of which reach every site of the network, and the administrator of any subsite could run it every time they switched the mode on. The challenge, the rate limit and the REST API restriction work as before; pages already in a page cache are served from it until it expires or is purged. |
| 429 |
* Fix: in an installation with more than one network, only the main site of the main network writes wp-config.php and the root .htaccess, which every network shares, or changes the database prefix. The main site of any other network, and its network administrator, were treated as their owner. |
| 430 |
* Fix: the lock that keeps two requests from writing .htaccess at the same time is now atomic. It relied on add_option(), which two requests arriving together could both win, so two writers could still overwrite each other. The network cleanup of stored wp-config.php copies added in 2.11.6 now uses the same kind of lock, so right after an update it runs one request at a time instead of every request repeating the same batch of sites. |
| 431 |
* Fix: a .htaccess file that PHP can write but not read is no longer replaced by the Vigilant rules alone. It was treated as empty, so writing the rules removed every other rule in it; now it is left as it is, and the refresh after an update records once that it could not be rewritten instead of retrying every hour. |
| 432 |
* Fix: on a network, a setting that had never been saved keeps its default value when an administrator without network rights saves other settings. A module switch in that situation could be stored as off. |
| 433 |
* Fix: on a network, approving or rejecting a pending registration now needs permission over that user, which WordPress only gives to network administrators. The pending flag belongs to the account, which every site shares, so the administrator of any subsite could approve a registration waiting on another site, the main site included, and open that account's login everywhere, or reject it. The other account tools have required this since 2.10.3; on a network the approval buttons now appear disabled for everybody else. On a single site that permission is the ability to edit users, which administrators have, and a role without it now sees those buttons disabled too. |
| 434 |
* Fix: on a network, visiting another site's dashboard no longer clears a forced password change set by a site with password expiration. The flag is shared by every site, and each site cleared it whenever its own policy did not apply to that user. |
| 435 |
* Fix: the one minute wait between two-factor email codes now holds whatever the time zone of the database server. Codes were stored with the database server's local time and compared with UTC, so the wait never applied on servers behind UTC and blocked a legitimate resend for hours on servers ahead of it. |
| 436 |
* Fix: a wrong email verification link no longer reveals whether an account is waiting for verification. The expiry was checked before the token, so an account with nothing pending answered expired while a waiting one answered invalid. |
| 437 |
* Fix: removed old copies of four admin actions that never ran, because the plugin always used a newer version of each, so a future fix cannot land in the copy that does not run. |
| 438 |
* Fix: removed three more methods that nothing called (a login-statistics query, a table-name helper and a duplicate author-enumeration guard whose job another class already does), and with the first one a database suppression that had no written justification. Housekeeping found by a read-through of the direct database queries and the output escaping, which turned up no injection and no cross-site scripting. |
| 439 |
|
| 440 |
= 2.11.7 = |
| 441 |
Security fix for networks: switching Under Attack mode off no longer undoes changes a network administrator made, while the mode was on, to the settings behind the wp-config.php and .htaccess all sites share. |
| 442 |
|
| 443 |
* Fix: on a network, switching Under Attack mode off no longer undoes the changes a network administrator made, while the mode was on, to the settings the shared wp-config.php and .htaccess are built from. Switching the mode off puts back the configuration saved when it was switched on, and any administrator of the main site can do it, so an administrator of the main site without network rights could roll those changes back to their earlier values, which the next rewrite of the shared files would publish for the whole network. Those settings are now compared with what the mode applied: the ones nobody changed go back to their earlier values, as before, and the ones that changed keep their new value, whoever switches the mode off and also when it expires by itself. If the mode was already on when you update, they are only put back when a network administrator switches it off. Single sites keep the previous behavior. Reported by the wordpress.org automated security review of 2.11.6. |
| 444 |
|
| 445 |
= 2.11.6 = |
| 446 |
Security fixes: Vigilant deletes the copies of wp-config.php, with its database password and keys, that earlier versions kept in the database. On networks, only a network administrator can change or remove the hardening in the wp-config.php and .htaccess all sites share. |
| 447 |
|
| 448 |
* Fix: on a network, deactivating Vigilant on a subsite no longer removes the hardening constants from wp-config.php. That file is shared by every site, and since 2.9.8 only a network administrator on the main site can write or remove the constants block from the settings screen, but the deactivation routine carried its own copy of the removal without that check. With Plugins enabled for site administrators in Network Settings, the administrator of any subsite can deactivate a per-site copy of Vigilant, and doing so removed the block for the whole network: file editing and the installation and updating of plugins, themes and core were unlocked again if they had been locked, forced SSL for the admin was dropped, and the original value of any constant the block had replaced came back. Deactivation now goes through the same removal as the settings screen, with the same check, so the block comes out when a network administrator deactivates Vigilant on the main site, or across the network from whichever site the request comes from, or when WP-CLI does it with no user on the main site or for the whole network; a network-wide deactivation requested on a subsite now removes the .htaccess rules too, which it used to leave behind. Nothing is removed while Vigilant is still active on the main site on its own, which is the case when it was activated there before it was activated for the network, and a copy that stays active on any site keeps its scheduled tasks and sends no deactivation email. Any other deactivation leaves the block in place, including a network administrator deactivating Vigilant on a subsite and a main site administrator without network rights deactivating it there; to remove the block after that, a network administrator can activate and deactivate Vigilant on the main site, or delete the lines between the Vigilant markers in wp-config.php and uncomment the ones marked [VIGILANTE_ORIGINAL]. The deactivation routine had removed the block without that check since 1.0.0, and it became a way around the network rule when 2.9.8 introduced the rule. |
| 449 |
* Fix: on a network, only a network administrator can now change the settings that Vigilant writes to the wp-config.php and .htaccess every site shares. Since 2.9.8 the settings screens have shown the file protections, the security headers and the wp-config.php constants as read-only to other users, but saving a tab, importing a settings file, applying a preset, restoring the defaults and adding an address to the whitelist from the activity log only checked that the user administered the site. On the main site those settings are the ones the shared files are built from, so an administrator of the main site without network rights could still change them: the file was not rewritten at that moment, but the new value stayed stored, and the refresh after the next update, or the next save by a network administrator, wrote it to the files of the whole network. Besides the settings already shown as read-only, that covered blocking bad bots and bad query strings, the visitor IP detection, the IP and User-Agent whitelists and the switches of the Firewall, Security Headers and WP Hardening modules, which on the main site now also appear disabled to anyone who is not a network administrator. Saving, importing, applying a preset, restoring the defaults and the whitelist button now leave them as they were, and activating Under Attack mode as such a user no longer changes them either; switching Under Attack mode off still puts back the settings it saved when it was switched on, these included. On subsites, the firewall settings and module switches that only protect that site stay editable by its administrator, while the HTTPS settings of the Headers tab, which only act on that site but have been read-only there since 2.9.8, can no longer be changed by importing a settings file either. If an administrator without network rights may have changed these settings on the main site before this update, review them as a network administrator: the refresh that runs after the update writes the stored values to the .htaccess. |
| 450 |
* Fix: Vigilant no longer keeps full copies of wp-config.php in the database, and deletes the ones earlier versions left there. Activating the plugin copied wp-config.php, .htaccess and robots.txt into the options table, keeping up to five sets, and writing the hardening constants kept one more copy of wp-config.php. That file holds the database password and the authentication keys and salts, so every copy put them within reach of anyone able to read the database or a backup of it, and nothing ever read those copies back. After the update they are deleted on the first request that reaches WordPress, which a page served from a page cache does not, and on a network the cleanup goes through every site, 50 at a time, including sites where Vigilant is no longer active, as long as it still runs on one. The file integrity scan still keeps the redacted copy it compares against, without those secrets. The Create Backup tool, which downloads the files as a ZIP, works as before. Present since 2.7.0, which moved these copies from files into the database. |
| 451 |
* Fix: deactivating Vigilant no longer changes the permissions of wp-config.php, and writing its rules no longer changes those of the root .htaccess, on single sites as well as on networks. Both used the default WordPress file mode, which is never stricter than 0644, so a wp-config.php kept at 0600 or 0640 was left readable at 0644 or wider on deactivation, and a .htaccess kept at 0640 was left at 0644 or wider every time the rules were written. If you have deactivated Vigilant while it managed constants in wp-config.php, check the permissions of that file. The wp-config.php part was present since 1.0.0. |
| 452 |
* Fix: Vigilant no longer cuts a file when one of its blocks has a BEGIN line without its END. Rewriting a Vigilant block in .htaccess, which happens after every update and whenever Vigilant writes its rules, dropped everything below the broken block on any site, the WordPress rules included, and removing the block on deactivation did the same on any site whose rules carry no WordPress markers, as happens when they are pasted by hand. Deactivating also cut wp-config.php from the broken block down, including the line that loads WordPress. Saving or switching off WP Hardening with a broken constants block did not cut wp-config.php, but saving added a second block after the broken one, and switching it off uncommented the original constants while the broken block stayed. The file is now left as it is, and so is the broken block, which keeps working until it is removed by hand. After an update the activity log records it once for that update; saving the Firewall, Headers or WP Hardening tab does not report it, and the rules are only written again once the broken block is gone. Present since 1.0.0. |
| 453 |
* Fix: on a network, activating Vigilant on a subsite, or its daily maintenance there, no longer deletes readme.html, license.txt and licencia.txt from the root folder every site shares. Only the main site removes them now, following its own settings. |
| 454 |
* Fix: removed unused code that could overwrite wp-config.php, .htaccess and robots.txt from those database copies without the network check, and an unused uninstall routine, so no future change can call them by mistake. |
| 455 |
|
| 456 |
= 2.11.5 = |
| 457 |
The file integrity scan now inspects the content inside the blocks Vigilant writes in wp-config.php and the root .htaccess, which earlier versions skipped. Blocks already on disk are recognised once after updating, so a file nobody changed is not reported. |
| 458 |
|
| 459 |
* Fix: the file integrity scan now checks the content inside the blocks Vigilant writes in wp-config.php and the root .htaccess. Those blocks, and the lines Vigilant comments out when it manages a constant, were left out of the hash so that Vigilant rewriting its own block would not read as somebody else's change; the side effect was that a change made inside them did not move the hash and did not show up in a scan. From now on a block is left out only when it is exactly a block Vigilant wrote, which is recorded at the moment Vigilant writes it, and a commented-out original line only while uncommenting it would still give a plain constant define. Anything else is hashed like the rest of the file and reported for review. The blocks already on disk are recognised once, on the first scan after updating, so a file nobody changed is not reported; a block that cannot be recognised as Vigilant's own is reported instead, and the activity log names the file. Present since 1.14.0, the version that first kept these blocks out of the hash. |
| 460 |
|
| 461 |
For older changelog entries, please check the [changelog.txt](https://plugins.svn.wordpress.org/vigilante/trunk/changelog.txt) file |
| 462 |
|
| 463 |
== Upgrade Notice == |
| 464 |
|
| 465 |
= 2.11.8 = |
| 466 |
Security fixes: the Under Attack challenge and its rate limit, the visitor IP behind X-Forwarded-For, secrets left in the integrity scan copy of wp-config.php, and several permission checks on networks. |
| 467 |
|
| 468 |
== Support == |
| 469 |
|
| 470 |
Need private support or custom development? |
| 471 |
|
| 472 |
Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just [contact me](mailto:vigilante@ayudawp.com) and tell me what you need. |
| 473 |
|
| 474 |
Need help or have suggestions? |
| 475 |
|
| 476 |
* [Official website](https://servicios.ayudawp.com/) |
| 477 |
* [WordPress support forum](https://wordpress.org/support/plugin/vigilante/) |
| 478 |
* [YouTube channel](https://www.youtube.com/AyudaWordPressES) |
| 479 |
* [Documentation and tutorials](https://ayudawp.com/) |
| 480 |
|
| 481 |
Love the plugin? Please leave us a 5-star review and help spread the word! |
| 482 |
|
| 483 |
== About AyudaWP == |
| 484 |
|
| 485 |
We are specialists in WordPress security, SEO, AI and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements. |
| 486 |
|
