CVE-2026-110010 in MB Custom Post Types & Custom Taxonomies Plugin
Summary
by MITRE • 10/22/2026
The MB Custom Post Types & Custom Taxonomies WordPress plugin before 2.12.3 does not perform any capability or authentication check before allowing an unauthenticated request to re-run a legacy data migration, letting anyone revert a custom post type or taxonomy definition on sites upgraded from a pre-2.0 release back to its pre-upgrade state. This discards configuration changes an administrator made after upgrading and, where those changes had restricted a definition's visibility, silently re-exposes the definition and its content to anonymous visitors.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in MB Custom Post Types & Custom Taxonomies versions prior to 2.12.3 represents a critical authentication bypass that allows unauthenticated actors to manipulate site configuration data. The core technical flaw lies within the plugin's handling of legacy data migration processes, specifically the function responsible for re-running these migrations on demand. In secure software design, any operation that modifies persistent state or alters system configurations must be protected by robust access control mechanisms. However, in this implementation, the endpoint triggering the legacy migration lacks both capability checks and authentication verification. This oversight means that any user with knowledge of the specific request parameters can invoke the function without providing valid credentials or possessing administrative privileges. The vulnerability exploits a design assumption where internal maintenance tasks were exposed via public-facing endpoints without adequate security gating, creating an open door for unauthorized state changes.
From an operational perspective, the impact of this flaw is severe and multifaceted. By allowing an unauthenticated request to re-run a legacy data migration, attackers can effectively revert custom post type or taxonomy definitions back to their pre-upgrade states from versions prior to 2.0. This action discards all configuration changes that administrators have intentionally made since the upgrade process was completed. The immediate consequence is the loss of administrative control over content structure and organization. More critically, if an administrator had previously modified these definitions to restrict visibility or limit access for specific user roles, this reversion silently removes those restrictions. As a result, custom post types and taxonomies that were intended to be private or restricted become publicly accessible again. This leads to the unintended exposure of sensitive content structures and potentially confidential data associated with those posts to anonymous visitors who have no legitimate reason to view them.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control, as it involves a failure to enforce proper authorization checks before executing privileged operations. Furthermore, in the context of the MITRE ATT&CK framework for web applications, this behavior is indicative of an Unrestricted Upload or Data Manipulation attack vector where an attacker manipulates application state through insecure direct object references or lack of authentication on critical endpoints. The specific technique resembles privilege escalation via configuration manipulation, allowing a low-privilege actor to achieve high-level administrative effects by exploiting the misconfigured migration tool.
To mitigate this vulnerability and prevent further exploitation, immediate action is required from site administrators and plugin developers. The primary remediation step is to upgrade the MB Custom Post Types & Custom Taxonomies plugin to version 2.12.3 or later, where these authentication checks have been implemented. For sites that cannot immediately update due to compatibility constraints, temporary mitigations should include restricting access to WordPress admin-ajax.php if it serves as the entry point for such requests, although this may impact other legitimate functionalities and requires careful configuration. Additionally, implementing a Web Application Firewall with rules targeting known exploitation patterns of legacy migration endpoints can provide an additional layer of defense. Regular security audits focusing on input validation and authorization checks in custom plugins are essential to prevent similar flaws from being introduced or persisting in WordPress ecosystems.