CVE-2026-86608 in WP Recipe Maker Plugin
Summary
by MITRE • 09/23/2026
The WP Recipe Maker WordPress plugin before 10.8.2 does not have any authorisation check in one of its REST routes, nor does it bound what that route stores, allowing unauthenticated users to write unlimited data into any user's metadata and to permanently prevent that account, including an administrator's, from loading.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in WP Recipe Maker versions prior to 10.8.2 represents a critical failure in access control mechanisms within the plugin’s REST API implementation. Specifically, one of the exposed REST endpoints lacks any form of authentication or authorization verification. This architectural flaw allows unauthenticated actors on the network to interact with the endpoint directly via HTTP requests without needing valid credentials for any WordPress user account. In modern web application security frameworks such as OWASP Top 10 and CWE standards, this is classified under CWE-287 Improper Authentication and CWE-862 Missing Authorization. The absence of these checks effectively bypasses the core security model of the Content Management System, treating sensitive administrative functions as public-facing resources accessible to any internet user with basic networking knowledge.
The technical nature of this flaw extends beyond simple unauthorized access; it involves a severe lack of input validation and data binding constraints on what is stored in the WordPress database metadata fields associated with specific users. The endpoint allows attackers to write arbitrary, unlimited amounts of data into any user's metadata profile. This capability transforms the vulnerability from a mere information disclosure or privilege escalation risk into a persistent denial-of-service vector against individual accounts. By injecting excessively large payloads or malformed data structures into these metadata fields, an attacker can corrupt the internal state management of the WordPress platform for targeted users. The impact is not limited to reading sensitive information but includes the active manipulation and corruption of user profile data that the system relies upon during session initialization and page rendering processes.
The operational impact of this vulnerability is severe, particularly regarding account availability and integrity. When an attacker writes corrupted or excessively large metadata entries to a specific user's record, it can cause the WordPress application to fail when attempting to load that user’s context. This results in a permanent denial-of-service condition for the affected accounts, including those with administrator privileges. Unlike temporary session timeouts or standard rate-limiting blocks, this issue persists until the database is manually cleaned by an administrator. For high-privilege users such as site administrators, this effectively locks them out of their own management console, preventing any remediation actions from being taken through the web interface. This aligns with ATT&CK technique T1496 Resource Hijacking or more specifically T1530 Data from Information Repositories if used for exfiltration, but in this context, it serves as a destructive persistence mechanism that disrupts business continuity and operational availability of the WordPress installation.
Mitigation strategies must address both the immediate remediation and long-term hardening of the application environment. The primary defense is to upgrade WP Recipe Maker to version 10.8.2 or later, where these authorization checks and input validation constraints have been implemented by the developers. For organizations unable to patch immediately due to compatibility concerns with other plugins, a temporary workaround involves restricting access to the WordPress REST API endpoints through web application firewall rules that block unauthenticated POST requests to known vulnerable paths if they can be identified via static analysis of older plugin versions. Additionally, implementing strict rate limiting on all REST endpoints and enforcing principle of least privilege by disabling unnecessary REST API functionality for non-essential users can reduce the attack surface. Regular database integrity checks should also be performed after any suspected incident to ensure that no malicious metadata entries remain in user profiles, thereby restoring normal operational function to compromised accounts.