Security

Advisories and release notes.

Every release that changes security behavior gets an entry here, including our own mistakes. To report a vulnerability, use the contact form and describe it without public detail; we'll reply from a real inbox.

0.2.2 — October 14, 2026 — Password not verified before 2FA code (critical)

Affected: every version before 0.2.2 with email 2FA enabled.
Action: update to 0.2.2 or later now. If you installed from a zip, replace the plugin files; see Updates.

What was wrong

Silverback hooks WordPress's wp_authenticate_user filter to decide whether to issue a 2FA challenge. We had assumed that filter ran after WordPress checked the password. It runs before. Because the plugin redirects to the code-entry screen and exits inside that filter, WordPress's own password check never executed. The effect: on any account 2FA applied to, a valid username with any password reached the code screen, and the emailed code alone completed the login.

In practice the account was still gated by access to the owner's inbox, so this was not an open door. But "password plus email code" had quietly become "email code only," and an attacker could trigger unlimited code emails to an owner by submitting junk passwords. That is exactly how we found it: an inbox filling with codes after every password on the server had been rotated to random values.

What changed

  • The plugin now calls wp_check_password() itself before doing anything. A wrong password returns control to WordPress, which shows its normal error. No code is generated, no email is sent.
  • New challenge-initiation throttle: five challenges per 15 minutes per IP address and per account, then a 30-minute cool-down. Behind Cloudflare the real visitor IP is used.
  • Password logins over XML-RPC, REST, and AJAX are refused for 2FA-protected accounts instead of emailing a code and returning a broken redirect. Use Application Passwords for API access.
  • Resend no longer resets the wrong-guess counter, is capped at three per challenge, and no longer extends the challenge's 10-minute expiry.
  • New SILVERBACK_DISABLE_THROTTLE constant, alongside the existing SILVERBACK_DISABLE_2FA and SILVERBACK_DISABLE_HIDE_LOGIN.

How to confirm you're fixed

Log out. At your login URL, enter a correct username with a deliberately wrong password. You should see WordPress's "incorrect password" error and receive no email. Then log in with the correct password and confirm the code arrives and works. If the wrong password still produces a code, you are not on 0.2.2 — or the plugin files aren't readable by your web server user (see the permissions note in the docs).

Why we're publishing this

A security plugin that hides its own bugs isn't one you should trust with your admin. We found this during an incident on our own infrastructure, fixed it the same day, and are documenting it plainly.

0.2.1 — Cosmetic

Admin menu label corrected to "Silverback Login." No security impact.

0.2.0 — Rename

Project renamed from "Silverback Security" to "Silverback Login." Folder, text domain, and settings URL changed; internal option and meta keys did not, so settings carry over when upgrading by replacing files. No security impact.