Content Egg EUVD-2026-113716

Requires an authenticated account with contributor-level capabilities or above on a WordPress site running Content Egg ≤12.0.0, because the handler gates on the generic edit_posts capability and the static 'contentegg_metabox' nonce. The exploit works against default configuration - no special plugin feature or non-default setting is needed - but is LIMITED by the authentication prerequisite: an attacker must first register or obtain a contributor+ account, so sites that do not permit low-privilege user registration (and have not had a low-privilege account compromised) are not remotely exploitable by anonymous attackers. Impact is limited to modifying Content Egg product data and update-timestamp post meta (I:L); there is no confirmed confidentiality or availability impact.

This is a genuine but low-to-moderate priority issue, not a high-severity emergency. The CVSS 3.1 base score is 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N - network-reachable, low attack complexity, but requiring authenticated privileges (PR:L, i.e. contributor-level or above), no user interaction, unchanged scope, and only a low integrity impact (C:N/I:L/A:N). The vendor advisory source is Wordfence and the vuln.today priority is 'this_month' - a routine patch cadence, not act_now or emergency. No EPSS score, no CISA KEV listing, and no PoC/exploit reference are present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals are internally consistent: a low-privilege authorization gap (CWE-862 missing per-object capability check) that only affects data integrity, matching the 'this_month' decision label. The main caveat is the prerequisite of an existing authenticated contributor account, which substantially limits the realistic attacker population to sites that allow untrusted user registration at contributor level or where a lower-privilege account has already been compromised.

An attacker who already holds a contributor-level (or higher) account on a WordPress site running Content Egg ≤12.0.0 sends a crafted admin-ajax POST to the ajaxUpdateProducts handler, supplying the post_id of a post they do not own - for example an administrator's published page. Because the handler validates only the static 'contentegg_metabox' nonce and the generic edit_posts capability but never calls current_user_can('edit_post', $post_id), the attacker can overwrite the Content Egg product meta (_cegg_data_*) and update-timestamp meta on that arbitrary post. No public exploit identified at time of analysis; the attack is low-complexity and needs no user interaction.