CVE-2026-9701: WordPress Vulnerability Chaining in Eventer
By WP Vanguard Team
On July 7, 2026, two CVEs landed against the same plugin, Eventer, on the same day. One scored 7.5. The other scored 9.8. Neither number tells you what actually happened on a vulnerable site, because the two flaws are a case study in WordPress vulnerability chaining: read separately they look like a data leak and a theoretical bug, chained they gave an unauthenticated attacker a path to set any administrator's password.
Two "medium" problems, individually manageable, combined into something a site owner can't triage from the score alone.
Eventer is an event and booking management plugin, the kind of tool that handles public registration forms and, by extension, password reset requests from people who aren't logged in. Both bugs came out of the same disclosure window and hit the same underlying weakness: a custom credential mechanism the plugin built for itself instead of reusing what WordPress already provides.
How the flaw works
Every WordPress password reset normally works the same way. A user requests a reset, core generates a random key, hashes it, and stores the hash in the user_activation_key column on wp_users. The email that goes out contains the raw key. Core checks the raw key against the stored hash when the user clicks the link. Reading the database at that point gets you a hash you can't use directly, not the key itself.
Eventer doesn't do it that way. The plugin stores a plaintext copy of the password reset key in the eventer_verification_code user meta field whenever a user requests a reset, alongside whatever core is doing in user_activation_key. The plugin built its own reset flow next to core's and skipped the hashing step entirely. Its custom reset action reads that plaintext value straight out of wp_usermeta and uses it to set a new password for the account it belongs to.
That means the value sitting in eventer_verification_code is a live credential, not a hash. Anyone who can read that one field for any user account can take over that account, no login required. That's CVE-2026-9701, rated critical at CVSS 9.8. The severity makes sense once you see what the field actually is: a working password reset token, sitting in a database table, protected by nothing but the assumption that nobody outside the site can read wp_usermeta.
That assumption is where the second bug matters. On its own, the plaintext key still needs a way to be read. CVE-2026-9700 is a time-based SQL injection in the 'code' parameter, caused by insufficient escaping on the user-supplied input and a lack of sufficient preparation on the existing SQL query. Rated 7.5, high severity. Time-based blind SQL injection doesn't return data directly in a response. It works by getting the database to pause execution conditionally, so the attacker infers each byte of a value from how long the response takes to come back. Slow, but reliable, and it needs no valid session or API key to run.
Chain the two and the sequence is direct. The SQL injection extracts the plaintext value of eventer_verification_code for an administrator's user ID. The plugin's own reset endpoint then accepts that value and lets the attacker set a new password for that account. No credentials at any step, and no core WordPress mechanism involved anywhere in the path. Both flaws are unauthenticated, so nothing about the attack requires prior access to the site, an existing account, or a phishing step to get a foothold first.
Who is affected
The version detail matters more than usual here, because the two bugs were patched separately:
- CVE-2026-9700 (the SQL injection) affects Eventer up to and including 4.4.3, fixed in 4.4.4.
- CVE-2026-9701 (the plaintext reset key) affects Eventer up to and including 4.4.4, fixed in 4.4.5.
A site that updated to 4.4.4 closed the SQLi read primitive but was still storing plaintext reset keys in usermeta. That's not a broken patch, it's two separate advisories with two separate fix versions landing a step apart, and a site owner who stopped at "I updated Eventer" after the first CVE notice would reasonably assume they were covered. They weren't, not fully, until 4.4.5. Sites need to be on 4.4.5 or later to close both halves of the chain.
No authentication or special configuration is required for either flaw. Any site running the affected versions with the plugin active is exposed, whether or not the site owner ever used the password reset feature themselves. The plugin generates and stores that meta value for any user, including subscribers and event registrants, whenever a reset is requested, which means the attack doesn't need the target account to be an administrator from the start. Reading enough rows through the SQLi lets an attacker find whichever account has admin capabilities and target that one specifically.
Why CVSS misses vulnerability chaining
CVSS scores one vulnerability at a time. That's not a flaw in the standard, it's the design: the score describes what a single flaw does in isolation, assuming everything else about the target is unknown or irrelevant. A 7.5 SQL injection that "only" extracts data reads as a data-exposure problem. A 9.8 privilege escalation that "requires" a way to read a stored value reads as theoretical, since most reset-key storage bugs have no obvious read path from the outside.
Score each one alone and you get two findings that a patch queue might reasonably prioritize behind something else. Attackers don't read them alone. They read a plugin's full disclosure history looking for exactly this kind of pair: a read primitive plus a place to point it. The SQLi doesn't need to be catastrophic by itself. It needs to reach one field. The reset flaw doesn't need an obvious attack surface by itself. It needs someone else's read primitive to feed it.
This is the same shape of mistake behind other recent WordPress incidents. The Kirki account takeover, CVE-2026-8206, and the User Registration & Membership auth bypass, CVE-2026-1492, both involved a plugin building its own credential or session logic next to core's instead of using it. Eventer's plaintext usermeta key is the same design error: a parallel credential store that shadows what core already does safely, and that only needs one more bug elsewhere to become exploitable.
Defenders who score vulnerabilities in isolation systematically undervalue storage flaws like CVE-2026-9701. There's no CVSS field for "combines badly with a bug in the same plugin's changelog three lines up." A scanner or a patch-priority queue built only on individual severity numbers will treat these as two separate, moderately urgent tickets. An attacker treats them as one exploit.
Exploit-prediction efforts like EPSS help by estimating real-world exploitation likelihood rather than theoretical severity, but they still score per CVE, not per pairing. Nothing in the standard vulnerability-management pipeline asks "what does this look like next to every other open finding in the same codebase." That question has to be asked by a person, or by a process built specifically to ask it, because the tooling that generates the score was never designed to answer it.
The practical fix isn't a better formula. It's treating "storage of a sensitive value in an unusual location" as a finding worth investigating on its own, independent of whether a read path is obvious yet. A reset key, a session token, or an API secret sitting in plaintext in a meta field, an option, or a log file is a liability the moment it's written, whether or not this month's disclosure includes the bug that reads it.
What to do now
If you're running Eventer, check your installed version against eventer.php or the plugin listing in wp-admin/plugins.php. Anything at 4.4.4 or below is exposed to the reset-key disclosure; anything at 4.4.3 or below is exposed to both flaws. Update to 4.4.5 or later. Don't stop at 4.4.4.
Before you update, check for signs the chain was already used. Look at wp_usermeta for any eventer_verification_code entries with recent updated_at timestamps that don't correspond to a password reset request you initiated. Check wp_users for administrator accounts with password changes you can't account for, and for any new administrator accounts created around the time of a password reset you didn't request. Review your web server logs for repeated requests to the reset endpoint with a code parameter carrying SQL syntax, quotes, UNION, SLEEP(), or similar time-based injection markers.
If you find an unexplained password reset on an administrator account, treat the site as compromised. Rotate all admin passwords, revoke and reissue any application passwords, and check for new admin users or scheduled tasks you didn't create. Our general guide on how WordPress sites get hacked covers what attackers typically do once they hold admin access, and signs your WordPress site has been hacked walks through the indicators to check beyond this specific plugin.
A version scanner that checks Eventer against known CVEs would have flagged both issues the moment they were disclosed; that's the kind of check WP Vanguard runs against a site's installed plugin versions.
Neither flaw is unusual on its own. Plaintext secrets in usermeta and unescaped parameters in SQL queries both show up regularly in plugin disclosures. What makes this pair worth writing up is the timing: both were disclosed the same day, against the same plugin, and closed in two consecutive point releases rather than one. That's a narrow but real window where a site owner could reasonably believe they'd already fixed the problem after the first update.
References
Related reading
Check Your WordPress Site Security
Free scan, no login required. Find vulnerabilities before attackers do.
Scan Your Site FreeGet weekly WordPress security tips
Vulnerability alerts, plugin updates, and security guides. No spam. Unsubscribe any time.