Login Armor

2.1.11

Bug fix release. Fixes a V2.1.9 regression on multisite + domain mapping setups (where sub-sites are mapped to external domains via WP MU Domain Mapping or native WP 4.5+).

• Fix – HideLogin::build_login_url() is now host-aware: chooses between home_url() and site_url() based on the request’s HTTP_HOST header, instead of always returning site_url() (V2.1.9/V2.1.10 default). Resolves the case where a subsite mapped on an external domain would redirect immediately to /wp-admin/ (404) when typing the slug, because site_url() pointed to the original network path while the request arrived on the mapped domain. Reported on the WP.org support forum by @graphandco. Standard installs (siteurl == home) and multisite headless setups (where the request arrives on the siteurl host) continue to work as in V2.1.9/V2.1.10.
• Fix – Slug detection in intercept_request() now matches against BOTH home_url($slug, ‘relative’) AND site_url($slug, ‘relative’) (instead of just one). Same dual-base matching extended to the wp-login.php and wp-register.php traps. No security change: relative paths only, no new hostnames accepted.
• Internal – Filter login_armor_login_url_base (introduced in V2.1.9) is unchanged and continues to wrap the final URL for advanced overrides (third-host scenarios, custom subdomain mapping plugins).

2.1.10

Cosmetic fix release. The 404 page served when an anonymous visitor hits /wp-admin/ with Hide Login enabled now renders as a proper WordPress 404 instead of a half-bootstrapped theme page with a duplicated header.

• Fix – block_access() now routes through serve_404_template() so the response carries the proper WP_Query::set_404() state. Visible effect: body class error404 is set, Yoast (or any SEO plugin) emits <meta name=”robots” content=”noindex”>, the theme renders its real 404 template instead of a default page layout, and themes with sticky headers (Astra Pro, many FSE themes) no longer show a duplicated header. No security change, no functional change for the actual 404 status header (still 404).
• Internal – 30 lines of duplicated 404 rendering code removed from block_access(); both code paths now share serve_404_template().

2.1.9

Bug fix release. Hide Login now uses site_url() instead of home_url() to build the rewritten login URL, matching what WordPress core does inside wp_login_url().

• Fix – Hide Login URL base switched from home_url() to site_url() (14 callsites migrated to a new public static helper HideLogin::build_login_url()). Inherited from the WPS Hide Login fork, the previous home_url() base was invisible on the ~99 percent of installs where siteurl == home, but broke silently on multisite headless (siteurl on admin.example.com, home on example.com), WordPress installed in a subdirectory (/wp/), and reverse-proxy installs with WP_HOME not equal to WP_SITEURL. Reported on the WP.org support forum by @graphandco.
• Feature – New filter login_armor_login_url_base for exotic setups where neither home_url() nor site_url() matches the hostname that actually serves the login slug (third hostname behind a reverse-proxy, subdomain mapping plugin rewriting the admin URL, etc.). Receives $url, $path, $scheme, $slug.
• Internal – Strictly neutral on the standard install where siteurl == home. Fresh-install, multisite-headless and WP-in-subdir validation suite passed before tag.

2.1.8

Hygiene release issued from a full V2.1.7 audit. Three findings, all LOW severity, batched in a single update.

• Fix – admin/views/tabs/settings.php queries the V2.1.1 webhook queue table without an existence guard. On a fresh install where the Activity Log module was never enabled (table not created) or after wp plugin install –force (which doesn’t re-fire activation), every Settings tab load emitted three DB warnings in debug.log (Table ‘X.wp_login_armor_webhook_queue’ doesn’t exist). Non-fatal but log-polluting. Now wraps the SELECT in a SHOW TABLES LIKE guard and returns zero counts when the table is absent.
• Fix – uninstall.php cleanup list was missing the login_armor_lockout_window option (default 24h, used by LimitLogin::trigger_lockout() for escalation tracking). Plugin deletion previously left this single option behind. Now: zero residue.
• i18n – Five untranslated strings surfaced by wp i18n make-pot regen: the V2.1.1 Activity Log integrity badge BROKEN, the legacy-rows-not-covered amber notice (singular form), the Breach Check password-found message (singular), the Breach Check email-breach message (singular), and the plugin description meta. All translated to French in languages/login-armor-fr_FR.po, no em dash. .mo recompiled. .pot regenerated against the full source tree (1010 strings vs 990 in 2.1.7) to capture 20 strings that had been added to the code (V2.1.1 webhook + integrity UI) but never made it into the translation template.

2.1.7

Preventive release on the Email 2FA enrollment flow. Closes a self-lockout pattern reported by a user whose hosting silently dropped outgoing mail.

• Fix – Email 2FA enrollment no longer half-commits when wp_mail() fails. The login_armor_2fa_method = email user meta was previously written before the verification email was attempted, leaving a partially configured state behind on hosts where SMTP is broken (Wanadoo, mutualised hosts without SMTP relay, etc.). The order is now: send first, persist only on success.
• Feature – New pre-activation modal on the user profile page when a user clicks “Set up Email” 2FA. Forces a real wp_mail() round-trip with a Send-test-email button and a safety-net checkbox (“I have a second admin tab open”) before the Enable button unlocks. Both gates must pass, eliminating the most common cause of admin-locked-out support tickets.
• Internal – New AJAX endpoint login_armor_2fa_email_test (nonce-protected) sends a one-shot test message without consuming the OTP cooldown.

2.1.6

Preventive release bundling V2.1.5 + post-tag cleanup findings. No bug observed in production — eliminates a latent V2.1.3-style fatal risk in the TwoFactor module and finishes the uninstall.php cleanup audit.

• Preventive – TwoFactor module now follows the always-require pattern (same as Activity Log V2.1.4 and BreachCheck). Class files are loaded unconditionally so any future hook callback that statically references TwoFactor classes survives fresh installs. Constructor and register() still gated by the enable option — zero-overhead contract preserved.
• Cleanup – uninstall.php now drops the V2.1.1 webhook queue table, deletes 14 leftover options (HSTS, login headers preset, activity auto-verify daily, V2.1.1 chain init flag + show-notice, 5 webhook), generalizes the transient SQL DELETE to login_armor_* (covering chain_verify_last and any future transient), and clears 3 V2.1.1 cron hooks (webhook dispatch + chain repair + chain auto-verify). Plugin deletion now leaves zero residual data.
• UX – Activity Log Integrity panel now surfaces “X rows before the integrity chain are not covered by Verify” when legacy or pre-init rows exist. The verify-chain coverage scope is now explicit rather than implicit.

2.1.4

Critical hotfix.

• Fix – Fatal error Class “LoginArmorActivityLogActivityLog” not found on every fresh install. The class file was loaded only when the Activity Log module was enabled, but the V2.1.1 chain initializer hooked at init priority 5 references the class unconditionally. On a fresh install (Activity Log option not yet set), every request to wp-login.php and the front end crashed with a 500. Existing sites that already had Activity Log enabled were unaffected. Fixed by always loading the class file (constructor still gated — zero-overhead contract preserved) and adding a defensive class_exists guard at the top of maybe_initialize_activity_chain().

2.1.3

Critical hotfix.

• Fix – Hardening “Hide WordPress version” toggle was stripping the ?ver= cache-buster from LoginArmor’s own admin assets (admin.css, admin.js), in addition to WP core and 3rd-party plugin files. Combined with hosting providers that run a server-side static cache (LiteSpeed LSADC on o2switch PowerBoost, Cloudflare full-page cache, hosting CDNs) keyed on the canonical URL, every LoginArmor update past 2.1.0 was invisible to admins for up to a year of cache TTL — the browser kept fetching the old admin.css from the server-side cache because admin.css (no query) and admin.css?ver=2.1.2 are different cache keys. Filter now whitelists /plugins/login-armor/ paths so our own assets always carry their version-derived hash, while WP core and 3rd-party version disclosure are still stripped.
• Fix – Defense-in-depth width=”18″ height=”18″ HTML attributes on the Activity Log Integrity bar’s shield SVG icon. Without these, if admin.css fails to reach the browser for any reason (CDN edge stale cache, content-blocker, proxy stripping CSS), the icon defaults to its intrinsic 300x150px and dominates the page layout. The CSS rule is still authoritative; HTML attrs are belt-and-suspenders.

2.1.2

Critical hotfix + UX polish.

• Fix – Settings tab fatal error on fresh installs that have not yet enabled the Activity Log module. The class LoginArmorActivityLogWebhookDispatcher was referenced in the Settings tab without an explicit require_once, and the file is only loaded when Activity Log is on. Visiting the Settings tab on a default install crashed with Class “LoginArmorActivityLogWebhookDispatcher” not found. Fixed by loading the file unconditionally before its first use.
• Fix – Save-confirmation toast (Settings saved.) was anchored top-right and overlapped the LoginArmor admin tabs nav, making the message unreadable behind the dark Réglages tab. Moved to bottom-right (Gutenberg snackbar convention), bumped z-index above sticky elements, and re-tuned the entrance animation to slide up from the bottom edge.

2.1.1

• Feature – Activity Log integrity: every row is HMAC-SHA256 signed and chained to the previous one. Detects any direct-SQL tampering, deletion or insertion. First-in-market for WP audit-log plugins.
• Feature – Signed webhook forwarding: optional async POST of every activity event to your SIEM, Slack, Datadog, Discord or any HTTPS receiver. X-LoginArmor-Signature HMAC header, adaptive retry policy, max 5 attempts.
• Feature – WP-CLI command wp login-armor activity verify-chain for scheduled audits and orphan repair (–from, –to, –repair-orphans, –format, –verbose).
• Feature – Admin UI: new compact “Activity Log Integrity” status bar in Activity tab + full Webhook configuration panel in Settings (URL, secret regenerate, send test event, queue stats).
• Feature – Login Page Security Headers (CSP + X-Frame + Referrer-Policy) now ON by default on fresh installs; REST public-namespace allowlist filterable via login_armor_rest_public_namespaces; auto-detection of 6 conflicting Hide Login plugins (Rename wp-login.php, WPS Hide Login, Defender, Solid Security, Wordfence, AIOS).
• Fix – Hardening: mask_login_errors no longer leaks remaining-attempt hint through LimitLogin filter (S-9), Honeypot switched to <input type=”hidden”> to survive theme stripping (S-22), User-Agent truncation cap reduced 500 -> 256 chars (S-19).

2.1.0

• Security (HIGH) – 2FA pending-verification token no longer travels in the URL. After the password step, the partially-authenticated session is held in a HttpOnly + SameSite=Strict cookie scoped to the login slug, signed with HMAC-SHA256 over wp_salt(‘auth’). Closes a leak surface that exposed the token via browser history, server access logs and the Referer header.
• Security (defense-in-depth) – The transient that backs the pending session is now keyed on sha256(token) instead of the clear token. The clear token never appears in wp_options.option_name either – DB-read attacks no longer yield a replayable token.
• Compat – URL token is still accepted as a fallback for one minor (V2.1.0). V2.2.0 will remove the fallback. Browsers that reject SameSite=Strict cookies fall through gracefully.
• Internal – One-shot upgrade hook purges any leftover V2.0.x 2FA pending transients from wp_options on first load. Idempotent.

2.0.5

Security audit pass. Five fixes identified by an internal Phase 1 + Phase 2 audit against 2.0.4, each double-checked on production before patching. No functional regression.

• Fix (HIGH) – REST author-enumeration scope. The Hardening “Disable author enumeration” toggle now also gates /wp-json/oembed/1.0/embed, the _embed=1 fanout on /wp/v2/posts, and wp-sitemap-users-N.xml. The lockout-side REST gate also denies oEmbed for locked IPs.
• Fix (HIGH) – Optional HSTS header for the Login Headers module. Off by default; opt-in 180-day or 1-year-with-subdomains modes. Only emitted on HTTPS requests.
• Fix (MED) – IPv6 subnet derivation. subnet_of() and DetectionClassifier::compute_subnet() now produce a re-parseable canonical /64 from compressed IPv6 (2001:db8::1 → 2001:db8:0:0::/64). Subnet block rules entered against IPv6 attackers now match.
• Fix (MED) – Self-DoS via 0.0.0.0 placeholder. record_failed_attempt() and check_lockout() skip the literal placeholder returned by get_client_ip() when the configured proxy header is misconfigured. Prevents site-wide lockout on the shared placeholder.
• Fix (MED) – “Block PHP in uploads” toggle off no longer wipes user-authored .htaccess rules. Only the LoginArmor block (recognized by # BEGIN/END LoginArmor markers, with a legacy fallback) is stripped.

2.0.4

Real fix for the lockout 429 page never appearing on hosts with a public page cache fronting the Hide Login slug.

• Fix – LockoutPage::render_on_trigger now performs a 302 redirect to /[hide-slug]/?_la_locked=<timestamp>. The unique query string defeats every public page cache (LiteSpeed Cache, WP Rocket, Cloudflare full-page, hosting reverse-proxy). Verified live with Playwright Firefox 150 + httpx HTTP/2.
• Fix – Branded lockout page logo now appears (path was referencing a file that did not ship).

2.0.3

Same-day hotfix on top of 2.0.2 for HTTP/2 stream termination.

• Fix – LoginArmor::flush_response_and_exit() now mirrors WordPress core’s _default_wp_die_handler exactly (no fastcgi_finish_request). Under LiteSpeed/LSAPI, calling fastcgi_finish_request() after a 4xx with a custom body left HTTP/2 streams without END_STREAM, hanging Firefox/Chromium. HTTP/2 lockout response now arrives complete in 1.3 s.

2.0.2

Critical fix for the lockout 429 page.

• Fix – The branded 429 lockout page now actually reaches the browser when the lockout is triggered. Root cause: PHP’s default output buffer (output_buffering=4096 on most managed hosts) was capturing the body. LoginArmor::flush_response_and_exit() now discards every parent buffer before writing the response. Same helper is used by Hide Login’s 404 renderer and Hardening’s XML-RPC + access-denied responses, so all three paths inherit the fix.

2.0.1

Post-launch patch.

• Fix – Branded 429 lockout landing page is now rendered on the lockout-triggering attempt (#N), not the next one. New action login_armor_lockout_triggered fires after the lockout marker is committed; LockoutPage subscribes and renders inline.
• Feature – Two new “Reset” buttons in Settings: “Reset all events & incidents” wipes the events feed, brute-force counters, and incidents in one click; “Reset all activity entries” wipes the admin-action audit trail. Both are confirmation-gated.
• Assets – WordPress.org banner and icon replaced with the navy-blue / yellow-padlock variant matching the in-admin icon.

2.0.0

First WordPress.org public release of the V2 line. Bundles eight independent security modules in a single sub-megabyte plugin: Hide Login (custom URL slug + branded lockout page), Brute Force Protection (cascading lockouts, subnet blocking, X-Forwarded-For), Hardening (13 one-click toggles), Two-Factor Authentication (TOTP + Email OTP + backup codes + trusted devices + recovery flow), Detection and Incidents (6 attack patterns), Activity Log (compliance-ready audit trail), Login Page Security Headers (CSP / X-Frame-Options / Permissions-Policy presets), and Breach Check (HIBP k-anonymity + opt-in XposedOrNot).

Pre-release security audit:

• Security – Breach Check email lookup is opt-in by default (only the password lookup is enabled when the module is activated).
• Security – Reserved-username blacklist folds Unicode-to-ASCII before comparison, so homoglyphs collapse onto the same blacklist entry.
• Security – REST API gating for unauthenticated users now matches public namespaces by route prefix on the parsed REST path; substring-match query-string bypass closed.
• Security – “Hide WordPress version” also strips ?ver=X.Y.Z from script and stylesheet URLs at script_loader_src priority 9999.
• Security – .htaccess writes (Block PHP in uploads, Disable directory listing) are atomic via temp file + rename, with admin notice on flush failure.