CVE-2026-109982 in MB Custom Post Types & Custom Taxonomies Plugin
Summary
by MITRE • 10/16/2026
The MB Custom Post Types & Custom Taxonomies WordPress plugin before 2.12.2 does not perform a capability check or validate a nonce on its migration actions, allowing any authenticated user, such as a subscriber, to trigger a one-way migration that creates published records and permanently deletes a companion MB Custom Post Types & Custom Taxonomies WordPress plugin before 2.12.2's entire post-type and taxonomy configuration.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in the MB Custom Post Types & Custom Taxonomies WordPress plugin prior to version 2.12.2 represents a critical failure in access control mechanisms, specifically categorized under CWE-862 Missing Authorization and CWE-352 Cross-Site Request Forgery. This flaw stems from the absence of proper capability checks and nonce validation on specific migration endpoints within the plugin's administrative interface. In secure WordPress development practices, actions that modify site configuration or data structures must verify that the requesting user possesses the necessary permissions to perform such operations. Furthermore, nonces are essential for preventing cross-site request forgery attacks by ensuring that requests originate from legitimate sources and have not been tampered with. The lack of these safeguards allows any authenticated user, regardless of their role level including subscribers who typically have minimal privileges, to execute administrative functions intended only for administrators or developers.
The operational impact of this vulnerability is severe due to the destructive nature of the affected migration action. An attacker can exploit this flaw by crafting a malicious request that triggers a one-way migration process within the plugin's logic. This process does not merely alter data but results in the permanent deletion of the entire post-type and taxonomy configuration stored by the companion MB Custom Post Types & Custom Taxonomies plugin. Since these configurations define how custom content types are structured, displayed, and managed on a WordPress site, their loss can lead to significant operational disruption. Existing posts associated with deleted taxonomies may become orphaned or inaccessible through standard administrative interfaces, potentially causing data integrity issues and requiring complex manual recovery procedures if backups exist. The ability for low-privilege users to trigger such destructive actions undermines the principle of least privilege fundamental to secure system design.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates unauthorized configuration changes and potential denial of service through data destruction. An attacker could leverage social engineering or cross-site request forgery vectors to trick an authenticated user into visiting a malicious page that automatically submits the forged migration request. This aligns with technique T1498 Network Denial of Service via resource exhaustion or disruption, although in this specific context it manifests as configuration corruption rather than service unavailability. The exploitation does not require complex binary exploits or remote code execution vectors but relies entirely on flawed server-side validation logic, making it relatively easy to exploit for any user with a valid account on the target WordPress installation.
Mitigation strategies must prioritize immediate patching and enhanced security hardening. Site administrators should upgrade the MB Custom Post Types & Custom Taxonomies plugin to version 2.12.2 or later where these authorization checks have been implemented. In environments where upgrading is not immediately feasible, temporary mitigations include restricting access to the WordPress admin area using IP whitelisting for administrative endpoints and enforcing strict role-based access controls via additional security plugins that can intercept and validate nonces more rigorously than default configurations allow. Additionally, implementing Web Application Firewall rules that detect anomalous POST requests to plugin-specific migration URLs can provide an extra layer of defense against automated exploitation attempts. Regular auditing of user capabilities and ensuring that all administrative actions require appropriate nonce verification are essential steps in preventing similar vulnerabilities in future development cycles.