CVE-2026-119059 in Content Egg Plugin
Summary
by MITRE • 10/30/2026
The Content Egg plugin for WordPress is vulnerable to unauthorized modification of data due to a missing per-post capability check on the ajaxUpdateProducts() function in versions up to, and including, 12.0.0. The handler verifies a static nonce ('contentegg_metabox') and the generic 'edit_posts' capability, but trusts the attacker-supplied $_POST['post_id'] verbatim and never calls current_user_can('edit_post', $post_id) — the per-object check that its sibling save_post handler saveMeta() correctly performs. This makes it possible for authenticated attackers, with contributor-level access and above, to modify Content Egg product data (_cegg_data_*) and update-timestamp post meta on arbitrary posts, including those owned by administrators.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in the Content Egg plugin for WordPress versions up to 12.0.0 represents a critical failure in object-level authorization controls within an AJAX handler function named ajaxUpdateProducts. This flaw stems from an inconsistent implementation of capability checks, where the application relies on generic role-based permissions rather than specific ownership verification. While the developer correctly implemented a nonce check using the static value 'contentegg_metabox' and verified that the user possesses the broad edit_posts capability, they failed to validate whether the authenticated user has permission to modify the specific post identified in the request payload. This architectural oversight allows any authenticated user with contributor-level access or higher to bypass intended restrictions by manipulating the post_id parameter sent via POST data.
From a technical perspective, the core issue lies in the absence of a call to current_user_can('edit_post', $post_id). In WordPress development, there is a distinct difference between edit_posts and edit_post capabilities. The former checks if a user has permission to perform an action on any post within their role's scope, while the latter performs a granular check against the specific object ID provided. By trusting the attacker-supplied $_POST['post_id'] verbatim without this per-object verification, the application effectively treats all posts as editable by anyone with basic publishing privileges. This contrasts sharply with the plugin’s own saveMeta handler, which correctly implements the necessary per-post capability checks, highlighting an inconsistency in security logic across different parts of the same codebase that leaves one specific endpoint exposed to exploitation.
The operational impact of this vulnerability is significant for any WordPress site running the affected versions of Content Egg. An authenticated attacker can modify product data stored under meta keys such as cegg_data* and update-timestamp post metadata on arbitrary posts, including those owned by administrators or other users with higher privileges. This unauthorized modification capability disrupts data integrity and allows attackers to inject malicious content, alter pricing information in e-commerce contexts, or deface website pages without needing elevated administrative credentials. The ability to modify administrator-owned posts is particularly severe as it undermines the principle of least privilege and can lead to further compromise if those modified products contain links to external malicious resources or sensitive data structures that are subsequently displayed to visitors.
This vulnerability aligns with CWE-269, which describes Improper Privilege Assignment, specifically where an actor is granted privileges they should not have for a specific resource. It also maps directly to the ATT&CK technique T1078, Valid Accounts, as it leverages legitimate but low-level credentials to perform actions outside their intended scope. Furthermore, because the attack vector involves modifying data through web application interfaces, it falls under CWE-653, which covers insufficient isolation of privileged operations from non-privileged ones in web applications. The lack of object-specific authorization checks is a common pattern in legacy or poorly audited WordPress plugins where developers assume that checking for general editing rights is sufficient protection against cross-post manipulation attacks.
Mitigation strategies must prioritize immediate patching to the latest version of the Content Egg plugin, which addresses this missing capability check by implementing proper per-object validation. Until an update is applied, site administrators should restrict user roles with publishing capabilities as much as possible and monitor for unusual activity in post meta tables associated with product data. Additionally, implementing a Web Application Firewall rule that inspects AJAX requests to the specific endpoint handling ajaxUpdateProducts can provide temporary protection by validating that the post_id parameter corresponds to posts actually owned or editable by the requesting user's account ID before allowing the request through. Regular security audits of custom plugins should always include verification that all data modification endpoints enforce both nonce validation and strict object-level capability checks using current_user_can with specific IDs.