Vokull Security Center

Changelog

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.