Adds failed-login rate limiting, on after the update: three wrong passwords lock an address out for 15 minutes, five lockouts hold it a day. Configurable under Settings, never applies to the local network or allow-listed addresses. Also stops reporting liesmich.html as a missing core file.<\/p>","1.8.0":"
Adds passkeys as a second factor alongside authenticator apps, and optional passwordless sign-in. Nothing to do after updating: existing two-factor setups are untouched and passkeys are opt-in per account. On an HTTPS site, users will find "Add a passkey" on their Two-factor screen.<\/p>","1.7.0":"
Sentinel Security Center is now Vokull Security Center. Settings, log and baselines are preserved. One manual step: the main plugin file was renamed, so WordPress leaves the plugin switched off after updating \u2014 activate it again on the Plugins screen.<\/p>","1.6.6":"
Documentation and housekeeping only, with no functional change and nothing to do after updating. The readme now spells out the two external services the plugin can contact, what each request sends, and when.<\/p>","1.6.5":"
Adds an alert for plugins that have an update waiting. Nothing is e-mailed until you set that event to e-mail under Settings; until then it is written to the log like any other event.<\/p>","1.6.0":"
The plugin no longer updates itself from GitHub; updates come through WordPress.org from this version on. Install this one through the update offer as it stands, or by uploading the ZIP. WPSEC_GITHUB_TOKEN, if you set it, can be removed from wp-config.php.<\/p>","1.5.2":"
Fixes "Check again" reporting no update for hours after one was published. The fix only takes effect once this version is installed: to see it now, use the plugin's update offer as it stands, or clear the wpsec_gh_release transient.<\/p>","1.5.1":"
A build-tooling fix with no functional change from 1.5.0. Nothing to do after updating.<\/p>","1.5.0":"
Packaging and metadata only: no functional change, and nothing to do after updating.<\/p>","1.4.0":"
A rename and nothing else: WP Security Center is now Sentinel Security Center. Settings, log and baselines are preserved. One manual step: the main plugin file was renamed, so WordPress leaves the plugin switched off after the update. Nothing is monitored until you activate it again.<\/p>","1.3.0":"
Adds an IP deny list on the Login & Location tab; nothing changes until you put an address in it. Also fixes the plugins screen offering an update that is already installed, and lets the log search box find rows by event type, IP address and time rather than only by description.<\/p>","1.2.0":"
Start at the Hardening screen: it grades this installation against the official WordPress hardening guide and says what to change. Adds optional two-factor authentication \u2014 nothing changes for anyone until a user enrols, or until you require it in Settings. Also fixes three false alarms.<\/p>","1.1.1":"
Required if your copy of this plugin is hosted in a private GitHub repository: without it, automatic updates are detected but cannot be downloaded. Install this version once by hand, and every later update will work on its own.<\/p>","1.1.0":"
The first release that actually does anything. Review Settings after upgrading: alerts are off until recipients are set, and login blocking stays in monitor mode until you arm it.<\/p>","1.0.0":"
Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-256x256.png":{"filename":"icon-256x256.png","revision":3667003,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256},"icon.svg":{"filename":"icon.svg","revision":3667003,"resolution":false,"location":"assets","locale":false}},"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.7.0","1.8.0","1.9.0"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[],"plugin_tags":[8531,8534,222353,600,9217],"plugin_category":[54],"plugin_contributors":[277624],"plugin_business_model":[],"class_list":["post-356632","plugin","type-plugin","status-publish","hentry","plugin_tags-activity-log","plugin_tags-audit-log","plugin_tags-passkeys","plugin_tags-security","plugin_tags-two-factor","plugin_category-security-and-spam-protection","plugin_contributors-glogger","plugin_committers-glogger"],"banners":[],"icons":{"svg":"https:\/\/ps.w.org\/vokull-security-center\/assets\/icon.svg?rev=3667003","icon":"https:\/\/ps.w.org\/vokull-security-center\/assets\/icon.svg?rev=3667003","icon_2x":false,"generated":false},"screenshots":[],"raw_content":"\n
Vokull Security Center (\"v\u00f6kull\" is Icelandic for \"vigilant\/watchful\") watches the things an attacker actually has to touch in order to keep a foothold in a WordPress site, records them in a searchable log, and e-mails you immediately when something matters.<\/p>\n\n
It is built around two goals that pull against each other: miss as little as possible, and produce as few false alarms as possible. Every event type can be set individually to immediate e-mail, log only, or off. Login blocking always starts in monitor mode so you can see what a rule would have done before you arm it.<\/p>\n\n
What is monitored<\/strong><\/p>\n\n A separate Hardening screen reports the current posture \u2014 file editor, permissions, salts, updates, HTTPS, two-factor coverage and more \u2014 against the official WordPress hardening guide, linking to it at each point.<\/p>\n\n The plugin never modifies, quarantines or deletes a scanned file.<\/strong> It reports, and leaves recovery to you.<\/p>\n\n Hardening report<\/strong><\/p>\n\n A read-only screen grading this installation against the official WordPress hardening guide, with a link to the relevant section of that guide on every check. Twenty-two checks covering the dashboard file editor and DISALLOW_FILE_MODS, file permissions, wp-config.php location and permissions, authentication salts, error output, core and extension updates, unused plugins and themes, administrator count, open registration, HTTPS, two-factor coverage, XML-RPC, alerting, file monitoring and backups.<\/p>\n\n Checks are graded Good, Fix this, Worth fixing \u2014 or \"Your call\", for the ones that genuinely depend on how the site is run rather than having a right answer. Nothing on the page changes anything.<\/p>\n\n Two-factor authentication: passkeys or an authenticator app<\/strong><\/p>\n\n Two independent second factors, and an account may hold either or both. Whichever is used, the session is issued only after the factor is proven \u2014 never before. Enrolment is per account and voluntary by default; a site setting can require a second factor for administrators, with a grace period whose clock starts when you switch the requirement on. Either factor satisfies it.<\/p>\n\n Passkeys.<\/em> A WebAuthn credential held by the phone, laptop, hardware key or password manager that created it. There is nothing to type, nothing to read out over the phone to someone claiming to be support, and the browser will only ever offer the passkey to your exact domain \u2014 so a convincing copy of your login page gets nothing. Only a public key is stored on the site; the private half never leaves the device. Users can register several and see when each was last used. If an authenticator that keeps a signature counter ever repeats a value \u2014 what a cloned key looks like \u2014 that is logged and mailed to you.<\/p>\n\n Passwordless sign-in.<\/em> On an HTTPS site you can additionally allow a passkey to sign in on its own, with no password at all. It is off by default, because it is a second way into the site and that is a decision worth taking deliberately. The authenticator must verify the user (fingerprint, face or PIN), and country rules, the IP deny list and the kill switch all still apply.<\/p>\n\n Authenticator apps.<\/em> The familiar six digits from any TOTP app. Shared secrets are encrypted with AES-256-GCM under a key derived from the site salts, so a database dump without wp-config.php is useless. Each code is accepted once, so a code read over your shoulder cannot be replayed. The QR code is drawn on your own server \u2014 the secret is never sent to an external QR service.<\/p>\n\n Recovery, in order: ten single-use recovery codes, issued the first time any factor is switched on and shown once; the other factor, if the account has both; optionally a one-time code mailed to the account address; and failing everything, a reset by another administrator.<\/p>\n\n No part of this contacts anything outside your own site. Passkeys are a conversation between the browser and this server; the WebAuthn library is bundled with the plugin.<\/p>\n\n Geo-aware login control<\/strong><\/p>\n\n Country is resolved from your CDN or reverse proxy's country header when the request demonstrably came through it, otherwise from a local MaxMind GeoLite2 database. No external API is called during login. X-Forwarded-For is only trusted when the connecting address is in your configured trusted-proxy list, so the client IP cannot be spoofed.<\/p>\n\n Because locking yourself out is the real risk, there are four independent ways back in: monitor mode is the default, an IP\/CIDR allow list is exempt from blocking, a wp-config.php constant disables blocking outright, and every blocked login e-mails you a single-use, time-limited link that unblocks your current IP.<\/p>\n\n Administrator-only<\/strong><\/p>\n\n The plugin adds no front-end output, no REST routes and no shortcodes. Its menu, notices, assets and actions all require the manage_options capability, and a blocked login is indistinguishable from an ordinary wrong password. The one exception is two-factor enrolment: that belongs to the account holder, so every signed-in user finds a Two-factor entry in their own profile menu and can set up a passkey or an authenticator app there. Nothing else about the plugin becomes visible to them.<\/p>\n\n About the name<\/strong><\/p>\n\n \"V\u00f6kull\" is Icelandic for \"vigilant\", \"watchful\". Which is fairly close to the entire job description: watch, and say something the moment it matters.<\/p>\n\n This plugin contacts two external services. Both are optional, neither is contacted from the front end or during a login, and no information about your site, your users or your visitors is sent to either.<\/p>\n\n MaxMind GeoLite2<\/strong><\/p>\n\n Used to resolve the country a login came from. The lookup itself happens locally against a downloaded database file, which is why no API is called while anyone signs in \u2014 but the database has to be fetched in the first place, and refreshed as it is reissued.<\/p>\n\n What is sent: a download request to When: only after you enter a MaxMind licence key under Security Center \u2192 Settings \u2192 Login & Location. Until you do, the service is never contacted. After that, when you press \"Download the GeoIP database now\", and weekly via a scheduled task.<\/p>\n\n Service provided by MaxMind, Inc. \u2014 GeoLite2 End User Licence Agreement<\/a>, privacy policy<\/a>.<\/p>\n\n Cloudflare IP ranges<\/strong><\/p>\n\n Used to offer Cloudflare's own address ranges as a ready-made option for the trusted-proxy list, so you do not have to find and paste them yourself.<\/p>\n\n What is sent: nothing beyond the HTTP request. The plugin performs a plain read of the public text files at When: only when an administrator presses \"Fetch Cloudflare's address ranges\" under Security Center \u2192 Settings \u2192 Login & Location. Nothing is requested by opening that screen, or by any other part of the plugin, and there is no scheduled task for it; the stored list is re-read only when you press the button again. Fetching alone changes nothing \u2014 the ranges are offered as a suggestion, every line is validated as CIDR notation, and nothing reaches your trusted-proxy list until you separately click to merge them.<\/p>\n\n Service provided by Cloudflare, Inc. \u2014 website terms of use<\/a>, privacy policy<\/a>.<\/p>\n\n\n An HTTPS site and a reasonably current browser. Nothing else: no service to sign up for, no key to configure, no traffic leaving your server. If the site is not on HTTPS the feature does not offer itself, because browsers refuse to create a passkey over a plain connection.<\/p>\n\n A passkey is bound to your domain. On a subdomain multisite, one registered on a.example.com will not work on b.example.com.<\/p><\/dd>\n A passkey, if the device allows it \u2014 it is the only second factor that cannot be typed into a fake login page. But there is no need to choose: an account can hold both, and either one gets you in. Whichever comes first also issues the recovery codes.<\/p><\/dd>\n Use one of the ten recovery codes issued when you switched two-factor on. If those are gone too and the site has the e-mail fallback enabled, the sign-in screen can mail a one-time code to the address on your account. If everything is lost, any other administrator can reset your second factor from your profile screen \u2014 you then set it up again.<\/p>\n\n The e-mail fallback is off by default on purpose. It means whoever can read that mailbox can finish the sign-in, which on many sites is the same person who controls the hosting account. Turn it on when losing a phone would otherwise mean losing the site; leave it off otherwise. Every code sent and every code used is written to the log.<\/p><\/dd>\n No. They are non-interactive \u2014 there is nobody there to type a code \u2014 and an application password is already a separate credential you can revoke on its own. If an account has to be locked down completely, revoke its application passwords as well.<\/p><\/dd>\n Yes, since 1.9.0, under Settings \u2192 Login & Location. An address gets three wrong passwords before it is locked out for fifteen minutes; after five lockouts it is held for twenty-four hours; an address that goes quiet for twenty-four hours is forgotten entirely. Every one of those numbers is yours to change.<\/p>\n\n The lockout is checked before the password is verified, so a locked address does not even get a password hash computed for it. It applies to the login form, to XML-RPC and to application passwords alike \u2014 those are where most password guessing actually happens.<\/p>\n\n This does not replace a firewall, a CDN rule or fail2ban, all of which act before the request reaches PHP and cost you nothing to run. It is what you have when none of those are available to you, and it is aimed at the volume rather than at a determined attacker.<\/p>\n\n Failed attempts are still logged individually as No. An attacker using a VPN endpoint inside an allowed country resolves to that country and passes. There is no VPN or Tor detection. Treat this control as something that removes opportunistic foreign traffic, not as a boundary.<\/p><\/dd>\n An individual IP that cannot be resolved is treated as not allowed and is blocked. But if the lookup subsystem as a whole is unavailable, blocking automatically falls back to monitor mode and raises a critical alert, so a deleted database file can never lock you out.<\/p><\/dd>\n Almost always because the plugin was installed from a GitHub source archive rather than the release ZIP, so the bundled MaxMind reader library in Country blocking is off until you arm it, and the settings screen refuses to arm it without a working database. If it does happen: the The failed-login rate limit is on out of the box, so it is worth knowing what it will not do. It never applies to the local network, to an address on your always-allowed list, or to one holding a live bypass grant; the same Not by default. Application passwords and XML-RPC authenticate through the same WordPress hook as an interactive login, so blocking them would silently break integrations hosted abroad. There is a setting to include them.<\/p><\/dd>\n No. Activation on a network stops with a message rather than misbehaving quietly.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
Username + password\n \u2502\n \u25bc\nWordPress accepts the password\n \u2502\n \u25bc\nDoes the account have a second factor?\n \u2502\n \u251c\u2500\u2500 Passkey \u2500\u2500\u2500\u2500\u25ba Face ID \/ Touch ID \/ Hello \u2500\u2500\u2510\n \u2502 \u2502\n \u251c\u2500\u2500 TOTP \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba six digits from the app \u2500\u2500\u2500\u2500\u2500\u2524\n \u2502 \u2502\n \u2514\u2500\u2500 Recovery \u2500\u2500\u2500\u25ba one of ten single-use codes \u2500\u2524\n \u2502\n \u25bc\n Login\n<\/code><\/pre>\n\nExternal services<\/h3>\n\n
https:\/\/download.maxmind.com\/app\/geoip_download<\/code> carrying the MaxMind licence key you configured and the edition name (GeoLite2-Country<\/code>). MaxMind requires both to authorise the download. Nothing else is transmitted.<\/p>\n\nhttps:\/\/www.cloudflare.com\/ips-v4<\/code> and https:\/\/www.cloudflare.com\/ips-v6<\/code>.<\/p>\n\n\n
vokull-security-center.zip<\/code> release asset and not the \"Download ZIP\" source archive: the source archive carries no vendor\/<\/code> directory and unpacks under a branch-suffixed directory name, which breaks country lookups and updates.<\/li>\nvokull-security-center<\/code>. It is the plugin slug, and updates are matched against it.<\/li>\n\n
Do passkeys need anything special?<\/h3><\/dt>\n
Should users have a passkey or an authenticator app?<\/h3><\/dt>\n
What happens if I lose my authenticator app?<\/h3><\/dt>\n
Does two-factor cover the REST API and application passwords?<\/h3><\/dt>\n
Does it block brute-force login attempts?<\/h3><\/dt>\n
login.failed<\/code>, at Info and log-only. Set that event to \"E-mail\" only if you know the site is quiet \u2014 on a public site bots guess passwords around the clock, and an inbox that learns to ignore this plugin is worse than no alert at all. The lockouts themselves are separate events: login.lockout<\/code> is logged, and login.lockout_extended<\/code> is e-mailed, because an address that is still going after five lockouts is somebody trying rather than a bot passing through. An attempt made while an address is locked out is recorded as login.blocked_lockout<\/code> instead of login.failed<\/code>, so nothing is written twice.<\/p><\/dd>\nWill country blocking stop a determined attacker?<\/h3><\/dt>\n
What happens if the GeoIP database is missing or broken?<\/h3><\/dt>\n
The Status screen says the GeoIP self test failed, but the database is installed. Why?<\/h3><\/dt>\n
vendor\/<\/code> is missing. Downloading the database needs no library and succeeds; reading it does. Two-factor enrolment showing no QR code is the same cause. Reinstall from the release ZIP.<\/p><\/dd>\nCan I get locked out?<\/h3><\/dt>\n
WPSEC_DISABLE_BLOCKING<\/code> constant in wp-config.php disables blocking immediately, and the alert e-mail for every blocked login contains a single-use bypass link.<\/p>\n\nWPSEC_DISABLE_BLOCKING<\/code> constant stands it down; and the Status screen lists every address being held with a button to release them all. At worst an ordinary lockout is a fifteen-minute wait.<\/p><\/dd>\nAre logins over the REST API or XML-RPC blocked too?<\/h3><\/dt>\n
Does it support Multisite?<\/h3><\/dt>\n
1.9.0<\/h4>\n\n
\n
login.lockout<\/code> (logged), login.lockout_extended<\/code> (e-mailed, because an address still going after five lockouts is somebody trying rather than a bot passing through), and login.blocked_lockout<\/code> for each attempt made during a lockout. The last one takes the place of the login.failed<\/code> line that attempt would otherwise have produced rather than being written next to it, so the log does not grow. All three are configurable on the Alerts tab like every other event.<\/li>\nWPSEC_DISABLE_BLOCKING<\/code> stands it down along with the country rule. It cannot be the thing that shuts you out of your own site.<\/li>\n<\/ul>\n\n1.8.0<\/h4>\n\n
\n
1.7.0<\/h4>\n\n
\n
1.6.6<\/h4>\n\n
\n
1.6.5<\/h4>\n\n
\n
1.6.0<\/h4>\n\n
\n
1.5.2<\/h4>\n\n
\n
1.5.1<\/h4>\n\n
\n
1.5.0<\/h4>\n\n
\n
1.4.0<\/h4>\n\n
\n
1.3.0<\/h4>\n\n
\n
1.2.0<\/h4>\n\n
\n
1.1.1<\/h4>\n\n
\n
1.1.0<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n