Vokull Security Center

Vokull Security Center ("vökull" 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. 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. What is monitored

• Plugins: installed, activated, deactivated, updated, deleted, plugins with an update waiting, and plugins that appear without a matching install (an SFTP drop).
• Themes: installed, activated, updated, deleted.
• Users and administrators: created, deleted, role changed, promoted to administrator, demoted, e-mail changed, password changed or reset — including changes an administrator makes to their own account.
• User records altered directly in the database, outside WordPress, detected by a periodic reconciliation scan.
• Configuration: critical options such as siteurl, home, admin_email, users_can_register and default_role; wp-config.php and .htaccess changes; WordPress core files verified against the official checksums; cron jobs; newly appearing must-use plugins; XML-RPC and file-editor state; application passwords.
• Filesystem: new or changed files in wp-content/mu-plugins/, and any PHP file under wp-content/uploads/ — where one never belongs. New PHP files are additionally checked against common backdoor signatures.
• Logins: failed attempts, successful logins, a login from a country outside your allow list, and logins refused by the IP deny list — with optional blocking.
• Two-factor authentication: who switched it on or off, passkeys registered and removed, wrong codes submitted after a correct password, and every use of a recovery code or the e-mail fallback.

A separate Hardening screen reports the current posture — file editor, permissions, salts, updates, HTTPS, two-factor coverage and more — against the official WordPress hardening guide, linking to it at each point. The plugin never modifies, quarantines or deletes a scanned file. It reports, and leaves recovery to you. Hardening report 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. Checks are graded Good, Fix this, Worth fixing — 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. Two-factor authentication: passkeys or an authenticator app 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 — 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. Username + password │ ▼ WordPress accepts the password │ ▼ Does the account have a second factor? │ ├── Passkey ────► Face ID / Touch ID / Hello ──┐ │ │ ├── TOTP ───────► six digits from the app ─────┤ │ │ └── Recovery ───► one of ten single-use codes ─┤ │ ▼ Login Passkeys. 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 — 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 — what a cloned key looks like — that is logged and mailed to you. Passwordless sign-in. 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. Authenticator apps. 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 — the secret is never sent to an external QR service. 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. 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. Geo-aware login control 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. 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. Administrator-only 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. About the name "Vökull" is Icelandic for "vigilant", "watchful". Which is fairly close to the entire job description: watch, and say something the moment it matters.

1.8.0

• Added: passkeys. A second factor that is not a code — a WebAuthn credential held by the phone, laptop, hardware key or password manager that created it. There is nothing to type and nothing to read out over the phone, and the browser will only ever offer the passkey to your exact domain, 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.
• Added: passkeys and authenticator apps sit side by side. An account can hold either or both, either one satisfies the "administrators must use two-factor" requirement, and the setup screen lists registered passkeys with when each was added and last used, with renaming and removal. Up to ten per account.
• Added: passwordless sign-in, off by default. Where you switch it on, the login screen gains a "Sign in with a passkey" button, and browsers that support it offer the passkey from the username field's own autofill list. The authenticator must verify the user — fingerprint, face or PIN — so the device and the person holding it are both proven. Country rules, the IP deny list and the kill switch all still apply, and every such sign-in is logged as one.
• Added: registering your first passkey now also issues your recovery codes, if you do not have a set. A passkey lives on one device, and losing that device with nothing written down would otherwise mean losing the account.
• Added: new log events for passkeys registered, removed, used and used for a passwordless sign-in, for refused verifications, and for a signature-counter anomaly. That last one is what a cloned authenticator looks like — an authenticator that keeps a counter should never repeat a value — and it is reported at critical severity by e-mail. The sign-in itself is not refused, because a mis-implemented authenticator would otherwise lock a legitimate user out for good.
• Added: two settings under Settings → Two-factor — whether users may register passkeys (on by default; the feature simply never offers itself on a site without HTTPS), and whether a passkey may sign in without the password (off by default).
• Changed: the authenticator app can now be removed on its own, leaving your passkeys and recovery codes in place. "Turn off two-factor authentication" still removes everything, as does an administrator reset — an account you believe is unprotected must not still hold a credential that can sign in.
• Changed: recovery codes are no longer reissued when a second factor is added to an account that already has a set. Reissuing would silently invalidate the codes you filed away.
• Note: passkeys need HTTPS, because browsers refuse to create one over a plain connection, and they are bound to your domain — on a subdomain multisite, one registered on a.example.com will not work on b.example.com. Nothing about this contacts anything outside your own site: the WebAuthn library is bundled with the plugin and reaches no network.

1.7.0

• Changed: the plugin is now called Vokull Security Center, with the permalink and text domain vokull-security-center. The WordPress.org review flagged "Sentinel" as a name already carried by well-known security products in this same field. Vökull is Icelandic for "vigilant", "watchful" — the name the project has been developed under all along.
• Changed: what the plugin calls itself on screen is now simply "Security Center" everywhere — the activation and deactivation log entries, the alert e-mail footer, the multisite refusal and the platform guards. The full name is what appears on the Plugins screen and in the directory.
• Changed: Cloudflare's published address ranges are now fetched only when you press a button on the Login & Location tab. Opening that tab used to read them as a side effect of rendering the page — nothing about the site was ever sent, but a settings screen should not contact a third party on your behalf. There is no scheduled refresh either. Ranges already stored keep working, and merging them into the trusted-proxy list remains a separate click.
• Fixed: the error message shown when a login is refused by a country rule, or when API authentication is refused for an account with two-factor, was not translatable — it was passed through WordPress' translation function without this plugin's text domain, so it stayed English in every language. The wording is unchanged; it is simply translated now like everything else.
• Removed: the bundled German translation and the translation template. Translations for a plugin hosted on WordPress.org come from translate.wordpress.org, which delivers them per locale through the ordinary update system; a bundled copy only duplicates that and goes stale against it. The strings themselves are unchanged.
• Unchanged: your settings, the log and the file and user baselines are all preserved. The option names, database tables and the GeoIP directory under uploads keep their existing prefix and are untouched.
• Note: as with the previous rename, this one leaves the plugin deactivated, because WordPress reactivates a plugin by the file path it recorded and the main plugin file has been renamed. Activate Vokull Security Center on the Plugins screen and monitoring resumes as before. Until you do, nothing is being monitored.

1.6.6

• Added: an "External services" section to this readme, documenting exactly what the MaxMind and Cloudflare requests send, and when. Neither is contacted until you configure it, and neither ever sees anything about your site or your visitors.
• Changed: the GeoIP downloader now deletes its temporary files through WordPress rather than calling unlink() directly.
• Changed: the plugin no longer calls load_plugin_textdomain(). WordPress has loaded translations on demand since 4.6 and does it for us.
• Fixed: the German translation was missing the two strings added in 1.6.5, and the translation template still offered three strings from features that have been removed. Both are up to date again.
• Housekeeping: no functional change otherwise. The code-standards exemptions moved from the project ruleset onto the statements they apply to, so the reasoning is visible where it matters and automated checks can see it.

1.6.5

• Added: a daily check for plugins with an update waiting, logged as its own event with the installed and available versions. It starts at log only — switch it to e-mail under Settings if you want to be told. An unpatched plugin is the most common way a site is taken over.
• Removed: the log event for changes to the automatic-update options. The Hardening screen still reports whether automatic updates are switched on, and disabling them through wp-config.php is still logged.

1.6.0

• Removed: the built-in updater that installed updates from GitHub Releases, along with the Update URI header. Plugins hosted on WordPress.org may not install or serve updates from an external source; updates now reach your site the ordinary way, through WordPress.
• Note: the WPSEC_GITHUB_TOKEN constant no longer does anything and can be deleted from wp-config.php.

1.5.2

• Fixed: "Check again" on the Updates screen could report no update for up to six hours after one had been released. The plugin caches its release lookup to stay under the GitHub rate limit, and was reading that cache back even when you had explicitly asked WordPress to check again. A forced check now re-queries GitHub.
• Added: the plugin's own icon, wherever WordPress previously drew the generic puzzle piece — the Updates screen and the plugin details modal. The admin menu keeps its shield.

1.5.1

• Fixed: a stale composer.lock left over from the 1.4.0 rename made the automated test run fail. Build tooling only; the plugin itself is unchanged from 1.5.0.

1.5.0

• Fixed: readme.txt declared "Tested up to: 7.0.4". That field takes a WordPress major version only, and a patch number in it is an error at review time, so it now reads 7.0.
• Fixed: the release ZIP shipped a vendor/ directory built by Composer without the composer.json that describes it, which the plugin review tooling flags. composer.json is now packaged alongside it.

1.4.0

• Changed: the plugin is now called Sentinel Security Center. WordPress.org does not allow a plugin name or permalink to begin with "wp", so the name, the slug and the text domain changed from wp-security-center to sentinel-security-center, and the main plugin file was renamed to match.
• Changed: the GitHub repository moved to sglogger/sentinel-security-center and the updater now queries it. The old URLs redirect.
• Unchanged: your settings, the log and the file and user baselines are all preserved. The option names, database tables and the GeoIP directory under uploads keep their existing prefix and are untouched.
• Note: this upgrade leaves the plugin deactivated, because WordPress reactivates a plugin by the file path it recorded and the main plugin file has been renamed. Activate Sentinel Security Center on the Plugins screen and monitoring resumes as before. Until you do, nothing is being monitored.

1.3.0

• Security: two-factor authentication could be bypassed by authenticating through xmlrpc.php with the account password, because XML-RPC never fires the hook the challenge hangs on. Primary-password API authentication is now refused for accounts with a second factor; application passwords are unaffected.
• Security: the GitHub updater token could be sent to a foreign host if any WordPress HTTP request contained the asset URL as a substring, e.g. in a query string. The URL is now matched structurally by scheme, host and path.
• Security: CSV export now neutralises spreadsheet formula injection — cells starting with =, +, - or @ are prefixed with a quote, since the log deliberately records attacker-typed strings.
• Security: two-factor attempts are now capped per user across all addresses, so rotating IPs does not multiply the guess budget.
• Added: an IP deny list for IPv4 and IPv6, single addresses or CIDR blocks, on the Login & Location tab. Denied addresses can never sign in: the list overrides the allow list, an allowed country and the private-network exemption, and applies even when country checking is off. No bypass link is issued for a denied address, and the settings screen refuses to store an entry matching the address you are saving from.
• Added: the login.blocked_denylist event, defaulting to log only. Because the check runs after the password is verified, an entry means someone at that address had working credentials.
• Changed: the log search box now searches the event type, the IP address and the timestamp as well as the description, the object and the user — everything a row puts on screen.
• Changed: tested up to WordPress 7.0.4.
• Fixed: the plugins screen kept offering an update to a version that was already installed, when the files had been updated by any means other than the updater itself. The cached check is now corrected on read, and is discarded outright when the version on disk changes.
• Fixed: the plugin details modal showed the changelog of the installed version rather than of the version being offered, and reported the last released version even on a copy that was newer.

1.2.0

• Added: a Hardening screen. Twenty-two read-only checks graded against the official WordPress hardening guide, each linking to the section it comes from. Verdicts include "Your call" for the decisions that depend on how the site is run — DISALLOW_FILE_MODS being the clearest, since it blocks plugin installation and every security update alike.
• Added: two-factor authentication (TOTP). A one-time code from any authenticator app, asked for after the password is accepted; the session is only issued once that code is right. Enrolment is per account and voluntary by default, with a site setting to require it for administrators after a grace period.
• Added: recovery for a lost authenticator — ten single-use recovery codes shown once at enrolment, an optional one-time code by e-mail (off by default, because it reduces the second factor to whoever reads the mailbox), and a reset by another administrator as the last resort.
• Added: failed login attempts are recorded as login.failed, at Info and log only. Nothing is enforced on a failure; rate limiting still belongs in your firewall or CDN.
• Fixed: the file scanner reported the plugin's own GeoIP guard files under uploads as a critical find. The GeoIP refresh was overwriting the recorded path of its own directory, which is what the scanner used to recognise them.
• Fixed: a .htaccess in the uploads directory was reported as "an executable file … should never contain PHP", which is wrong on both counts. It is now its own finding, with the event the registry already defined for it.
• Fixed: on a localised WordPress, wp-includes/version.php was reported as modified on every scan. The checksum manifest is now chosen by the package the core was built from rather than by the site's current language.
• Fixed: the "View details" link vanished from the plugins list whenever GitHub could not be reached. The plugin now always registers itself in the update transient, and the details modal no longer offers a WordPress.org page that does not exist.

1.1.1

• Fixed: updating from a private GitHub repository failed after the update had already been offered. The release asset was fetched from its browser URL, which cannot carry a token; it is now fetched from the API asset URL with the token and the correct Accept header. Public repositories were unaffected.

1.1.0

• First functional release. Everything below is new.
• Event log with a filterable admin viewer, search, sorting, per-page control and CSV export of exactly the filtered view.
• Monitoring of plugins and themes: install, activate, deactivate, update, delete, auto-update, and plugins that appear on disk without an install.
• Monitoring of users and administrators: creation, deletion, role change, promotion and demotion, e-mail and password changes, application passwords, and changes an administrator makes to their own account.
• Detection of user records altered directly in the database, by hourly reconciliation against a stored baseline. This is the only way to see a changed login name, which WordPress itself provides no path for.
• Configuration monitoring: critical options, wp-config.php and .htaccess hashes, WordPress core files against the official checksums, cron jobs, new must-use plugins, XML-RPC and file-editor state.
• File integrity for wp-content/mu-plugins and any PHP file under uploads, with weighted backdoor-signature heuristics. Files are only ever read, never modified, quarantined or deleted.
• Geo-aware login control: country from a trusted CDN header or a local MaxMind GeoLite2 database, monitor mode by default, optional blocking, and four independent ways back in if you lock yourself out.
• Immediate e-mail alerts, configurable per event type as e-mail, log only, or off, with an hourly circuit breaker so a mass finding cannot flood a mail server.
• Diagnostics screen showing how the site sees your address, and a what-if test for any other address.
• Complete German translation.

1.0.0

• Initial scaffolding release.