Pods (WordPress) EUVD-2026-59778

Exploitation requires that the request traverse the Pods pods_admin AJAX router via the JSON meta-box-loader compatibility path, under which pods_error() logs-and-returns instead of terminating - this is the exact condition that renders the guards ineffective, and it is part of the plugin's normal compatibility handling rather than a rare opt-in setting. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N), no authentication, no user interaction, and only low complexity are needed against a site running Pods ≤ 3.3.9 with the plugin active. The primary limiting factor is simply that the Pods plugin must be installed and active and reachable at admin-ajax.php; a WAF filtering the pods_admin action or plugin deactivation removes the exposure.

This is a genuine top-priority issue rather than an inflated high-CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) is internally consistent with the description: a fully remote, unauthenticated request with no user interaction yields complete compromise, and the authorization bypass is deterministic rather than a race or heap-spray, so exploitation is highly reliable once the request shape is known. Impact - self-promotion to Administrator or arbitrary password overwrite - is total integrity and confidentiality loss and, via account lockout, availability loss too. EPSS and CISA KEV data were not provided in the input, so I cannot cite an exploitation-probability percentile or confirm active exploitation; the analysis rests on the CVSS vector and a detailed public root-cause writeup from Wordfence. Given the low complexity, the large install base of Pods, and how mechanically clear the bug is, even a mid-sized operator running a handful of WordPress sites should treat this as urgent and patch on an emergency schedule rather than waiting for a KEV listing.

An attacker sends a crafted, unauthenticated POST to wp-admin/admin-ajax.php invoking the pods_admin action along a JSON meta-box-loader compatibility path; the failed nonce, login, and capability checks only log errors and return false, so execution continues into the privileged handler. The attacker then invokes an administrator action - resetting the site owner's password or elevating an attacker-controlled account to Administrator - and takes over the site. No public proof-of-concept is identified at time of analysis, but the writeup describes the mechanism in enough detail to reconstruct one.