Ibtana Product Addons CVE-2026-1984

Requires an authenticated WordPress account with Subscriber-level privileges or higher on a site running Ibtana - Ecommerce Product Addons version 0.4.7.7 or earlier; the attacker invokes the 'iepa_use_gt_editor' AJAX action, which lacks a capability check, to modify or delete the 'iepa_builder' post meta on arbitrary posts. Limiting factors: an attacker must first hold a valid low-privilege account (open registration makes this trivial, otherwise it requires an existing user), impact is confined to integrity of post meta (no confidentiality or availability loss), and the site must run the vulnerable plugin version. Despite the vendor's PR:N vector, the description makes Subscriber authentication a hard prerequisite.

This is a high-CVSS-but-modest-real-risk issue. The vendor vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3) claims unauthenticated (PR:N), but the description explicitly states exploitation requires 'authenticated attackers, with Subscriber-level access and above' - a direct contradiction. PR should almost certainly be PR:L, which lowers the true base score to ~4.3. Impact is integrity-only (C:N/I:L/A:N): the attacker can update or delete arbitrary post meta under the 'iepa_builder' key, which is data tampering, not data theft or full compromise. There is no EPSS score, no CISA KEV listing, and no public POC provided, so exploitation status is 'no public exploit identified at time of analysis.' The requirement for a valid authenticated account (even a low-privilege Subscriber) plus the low, integrity-only impact means this is a low-to-moderate operational priority rather than an urgent, mass-exploitable flaw. The most notable conflict to verify with the vendor is the PR:N-vs-Subscriber-required discrepancy.

An attacker registers or obtains a Subscriber-level account on a WordPress site running Ibtana - Ecommerce Product Addons (≤0.4.7.7), then sends a crafted AJAX request to the 'iepa_use_gt_editor' action, which lacks a capability check. Because the handler trusts the caller, they can update or delete the 'iepa_builder' post meta on arbitrary posts, corrupting product/page builder data. No public exploit code is identified at time of analysis.