Description

The Eventin – Event Calendar, Tickets, Registration, Booking & WooCommerce plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.1.23. This is due to the `PermissionManager::manage_permissions()` function being registered as a callback on WordPress core's `map_meta_cap` filter and unconditionally returning the always-true `'exist'` primitive for every capability check whenever the evaluated user ID is 1, without scoping this behavior to plugin-specific capabilities. This makes it possible for authenticated attackers whose account is user ID 1, even subscribers, to pass every WordPress capability check, including `manage_options`, `edit_plugins`, `edit_themes`, `promote_users`, and `update_core`, thereby elevating their privileges to administrator-equivalent power and achieving full site takeover, including remote code execution via the plugin and theme editors. Exploitation is only impactful when user ID 1 has been deliberately demoted to a lower-privilege role as a common administrator-account hardening practice; on default installations where user ID 1 retains the administrator role, no incremental privilege gain occurs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-15T07:16:29.743Z",
  "pubdate": "2026-09-15T07:16:29.743Z",
  "executiveSummary": "The Eventin plugin for WordPress is susceptible to a critical privilege escalation vulnerability affecting all versions up to and including 4.1.23.\nThe vulnerability stems from improper implementation of the map_meta_cap filter, which incorrectly validates user capabilities by granting administrative access to any user account associated with ID 1.\nThe flaw allows an authenticated attacker possessing the user ID 1—even if assigned a low-privilege role like Subscriber—to bypass all capability checks within the WordPress core.\nThis effectively grants the attacker full administrative control, enabling site takeover, unauthorized content modification, and remote code execution.\nThe risk is primarily realized in hardened environments where the original administrator account (ID 1) has been demoted to a restricted role to reduce the attack surface.\nExploitation requires the attacker to be authenticated as user ID 1. Default installations where ID 1 remains an administrator are not impacted by incremental privilege gain.",
  "technicalDetails": "The vulnerability resides within the PermissionManager::manage_permissions() function, which is registered as a callback for the WordPress core map_meta_cap filter.\nThe map_meta_cap filter is designed to map meta capabilities to primitive capabilities, allowing developers to restrict or grant access to specific actions based on conditional logic.\nIn the Eventin plugin, the PermissionManager::manage_permissions() implementation contains a logic error: it unconditionally returns the 'exist' primitive capability for any capability check performed against user ID 1.\nBecause the function fails to scope this validation to plugin-specific permissions, it overrides the standard WordPress capability verification process for the entire application.\nWhen a user with ID 1 initiates any action requiring specific capabilities—such as manage_options, edit_plugins, or update_core—the WordPress core triggers map_meta_cap. The Eventin plugin intercepts this request and forces a return value of true.\nConsequently, the user ID 1 bypasses the user_can() checks that would otherwise prevent a non-administrator from performing sensitive operations.\nAn authenticated attacker possessing user ID 1 can navigate to administrative panels, modify site configurations, install malicious plugins, or edit active theme files to inject arbitrary PHP code, leading to complete remote code execution.\nThe exploitation flow is as follows: 1) The attacker authenticates as the account with user ID 1. 2) The attacker attempts an administrative action (e.g., accessing /wp-admin/plugins.php). 3) WordPress core invokes map_meta_cap to verify if the user has the 'activate_plugins' capability. 4) The vulnerable PermissionManager::manage_permissions() callback is executed, identifies the user ID as 1, and returns true. 5) WordPress grants the request, elevating the attacker's effective privileges to those of a super-administrator regardless of their assigned role in the wp_users table.\nThis flaw effectively nullifies the WordPress role-based access control system for the affected account, making it a severe security regression for sites that have attempted to harden their administrator account."
}