CVE-2026-11616
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedThe Events Calendar for GeoDirectory plugin for WordPress is vulnerable to Privilege Escalation in versions up to and including 2.3.28. This is due to the ajax_ayi_action() handler only applying strip_tags(esc_sql()) — with no allow-list — to the attacker-controlled $_POST['type'] and $_POST['postid'] values before forwarding them to update_ayi_data(), which calls update_user_meta($current_user->ID, $rsvp_args['type'], $posts). By passing type=wp_capabilities and postid=administrator, an attacker writes ['subscriber'=>true,'administrator'=>'administrator'] into their own wp_capabilities user meta; WP_User::get_role_caps() then treats the 'administrator' array key as an active role on the next request. This makes it possible for authenticated attackers, with Subscriber-level access and above, to elevate their privileges to Administrator.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe Events Calendar for GeoDirectory plugin for WordPress has a privilege escalation vulnerability in ajax_ayi_action() where $_POST['type'] and $_POST['postid'] are passed through strip_tags(esc_sql()) without allow-list filtering, then used directly in update_user_meta(). Authenticated users with Subscriber-level access can set type=wp_capabilities and postid=administrator to inject administrator role into their own user meta, elevating privileges to Administrator.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check installed plugin versionIn WordPress admin, go to Plugins > Installed Plugins > Events Calendar for GeoDirectory and note the version number. Alternatively, check the plugin's main PHP file header or version.php for the 'Version' constant.Affected if The installed version is 2.3.28 or lower (any version up to and including 2.3.28 is affected)
-
Verify ajax_ayi_action function existsSearch the plugin files for the function 'ajax_ayi_action' - typically in the main plugin file or an includes/ajax.php file. Confirm the function handles $_POST['type'] and $_POST['postid'] parameters.Affected if The function exists and processes $_POST['type'] and $_POST['postid'] without proper allow-list validation on those parameters
-
Check if admin-ajax endpoint is accessibleVerify the WordPress site has admin-ajax.php accessible (standard in WP). Test with a simple curl or browser request to /wp-admin/admin-ajax.php?action=ayi_action to confirm the action is registered.Affected if The 'ayi_action' hook is registered and accessible without authentication restrictions or with only subscriber-level authentication required
-
Identify at-risk user rolesCheck if any user accounts exist with the Subscriber role. In WordPress admin under Users, review the role assignments. Subscribers have the lowest privilege level but are sufficient to exploit this flaw.Affected if There are Subscriber-level user accounts active on the site who can access the ajax endpoint
-
Inspect user meta for suspicious entriesQuery the wp_usermeta table (via phpMyAdmin or WP CLI: wp user meta list --user_id=<id>) looking for meta_key 'wp_capabilities' on user IDs that should not have administrator privileges. Check if any non-admin users have wp_capabilities containing 'administrator'.Affected if Any user with Subscriber role has wp_capabilities meta containing 'administrator', indicating successful exploitation
You are affected if the plugin version is 2.3.28 or lower, the ajax_ayi_action function processes type/postid without allow-listing, and Subscriber-level users exist or have unauthorized admin capabilities in user meta.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade to a patched version that implements proper allow-list validation for the type and postid parameters, restricting them to safe values and preventing manipulation of WordPress core user meta keys.
The Events Calendar for GeoDirectory version 2.3.29 or latest available
- Log in to the WordPress admin dashboard
- Navigate to Plugins > Installed Plugins
- Locate 'The Events Calendar for GeoDirectory' plugin
- Check the current version installed (should be 2.3.28 or below)
- Update the plugin to the latest available version (2.3.29 or higher) which contains the security fix
- Verify the update was successful by checking the plugin version
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation2.0 h
- Testing3.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,832.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-11616 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-11616 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data