The Eventer plugin for WordPress has a serious password reset vulnerability tracked as CVE-2026-9701. Every version up to and including 4.4.2 is affected. Any site running this plugin — on PHP 7.4 or below — is exposed to unauthenticated account takeover, including administrator accounts.

Here's the core failure: when a user requests a password reset, Eventer writes the reset key in plaintext to the eventer_verification_code field in wp_usermeta. That's the wrong place and the wrong format. WordPress core hashes reset keys before storing them in wp_usermeta for exactly this reason — if your database is ever read by an attacker, hashed keys limit the damage. Eventer skips that protection entirely. On its own that's bad. Paired with CVE-2026-9700, a SQL injection flaw in the same plugin, an unauthenticated attacker can pull that plaintext key directly from the database and use the plugin's own custom reset action to set a new password on any account. No credentials required.

This is a classic defense-in-depth breakdown. Two individually serious bugs combine into something much worse. The SQL injection is the entry point; the plaintext key storage is what makes account takeover trivial rather than just possible. If the key had been hashed, extracting it via SQL injection would've bought the attacker very little without additional cracking effort. The insecure storage turns a difficult attack into a straightforward one.

From an IAM standpoint, the lesson here isn't specific to WordPress. Any system that implements its own credential or token storage — reset keys, magic links, temporary passcodes — needs to treat those values like secrets. Hash them. Expire them aggressively. Don't store them in broadly queryable tables with weak access controls. I've seen this pattern in custom-built CIAM flows too, not just plugins. The moment you write a plaintext token to a user record in a shared table, you've created a lateral movement path that bypasses your entire authentication stack.

If you're running the Eventer plugin, audit your WordPress version and PHP environment immediately. If you're on 4.4.2 or below and can't patch right now, disable the plugin — the risk of admin account takeover isn't one you can accept while you wait. If you manage WordPress environments at scale, add checks for both CVEs to your vulnerability scanning. And if you have custom password reset or magic-link flows anywhere in your stack, pull the code this week and verify those tokens are hashed at rest. That's the Monday-morning action that actually matters here.