Icegram Engage CVE-2026-16087

Exploitation requires an active, authenticated WordPress session holding the edit_post capability on Icegram campaign posts - the CVE description explicitly states this equates to Editor role or above. The attack is two-phase and both phases must succeed: first, the attacker POSTs the crafted messages[][id] payload to save_campaign_preview() (protected by a WordPress nonce, preventing CSRF-driven delivery); second, the attacker triggers a campaign preview request that invokes get_message_data() to execute the stored payload as SQL. SQL execution is scoped to the WordPress database user's privileges, which on shared hosts often equals full database access. Exploitation is limited by: (1) the Editor-level credential requirement - attackers must already hold a high-trust WordPress account or compromise one; (2) the two-step, workflow-aware nature of the attack, which precludes single-request mass scanning. Note: the CVE description opens with 'contributor-level access and above' but its technical section states 'edit_post capability, requiring Editor-level access or above' - this privilege discrepancy is unresolved and the true minimum role should be confirmed with Wordfence before finalizing access-control mitigations.

The vendor-assigned CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) classifies this as a medium-severity, remotely exploitable, low-privilege, read-only SQL injection. However, the CVE description's own technical detail states the save_campaign_preview() AJAX action is gated by the edit_post capability 'requiring Editor-level access or above' - a privilege threshold that is higher than the PR:L (contributor level) the vendor assigned in the CVSS vector. This internal discrepancy is unresolved and materially affects real-world risk: if Editor role is truly required, the effective exploiter population on a given WordPress site is small, significantly reducing opportunistic risk. No EPSS data was provided, so statistical exploitation probability cannot be quantified. No KEV listing and no public proof-of-concept exist, placing this firmly in a 'patch promptly' category rather than emergency response. The two-phase exploitation requirement - save then preview - reduces risk from mass automated scanning, as it demands contextual knowledge of the campaign workflow. The impact is confidentiality-only: full read access to the WordPress database, which can include user password hashes, PII, subscriber email lists, and API secrets stored as wp_options rows - a meaningful data-breach vector for marketing-intensive WordPress deployments.

An attacker who has obtained or created an Editor-level WordPress account sends a crafted POST to wp-admin/admin-ajax.php invoking the save_campaign_preview action with messages[][id] set to a payload such as 0) UNION SELECT option_value,2,3 FROM wp_options WHERE option_name='auth_key'--, satisfying the nonce and capability checks with their session credentials. WordPress stores the payload in post meta without sanitization. The attacker then requests the campaign preview, causing get_message_data() in class-icegram.php to embed the stored payload into a SQL IN() clause; the injected UNION SELECT returns the target option value in the preview response, exposing secret keys or other sensitive database contents. No public proof-of-concept exists at time of analysis, but the injection points are identified by line number in the public Trac source browser, making independent reproduction straightforward.