Custom Field Template CVE-2026-9855

Requires an authenticated WordPress account with Contributor-level capability or higher on a site running Custom Field Template <= 2.7.8; the attacker must first obtain a valid nonce, which any Contributor can legitimately retrieve from the post edit screen. Exploitation targets the 'post_ID' parameter and works despite the current_user_can('edit_post', $id) check because WordPress casts the value to an integer for the permission decision while the unsanitized full string reaches the SQL query. Limiting factors: it is not unauthenticated (PR:L), so it is most dangerous on sites allowing open/untrusted Contributor registration or multi-author setups; impact is confidentiality-only (database read/exfiltration), with no direct write or availability effect described.

This is a genuine but moderate-priority issue. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) describes a network-reachable, low-complexity SQL injection requiring only Contributor-level authentication, with high confidentiality impact and no integrity or availability impact - consistent with a data-extraction SQLi. The most important signal is the described capability-check bypass: current_user_can('edit_post', $id) is defeated because WordPress casts $id to an integer for the permission decision while the full unsanitized string is preserved and passed to the SQL sink, and the required nonce is legitimately obtainable by any Contributor from the post edit screen - so the PR:L barrier is real but low. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no evidence of active or automated exploitation; risk is elevated on sites that grant untrusted users Contributor accounts (open registration, multi-author blogs) and low on single-author/locked-down installs. Bottom line: real and worth patching, but not an emergency - it is an authenticated info-disclosure SQLi, not an unauthenticated RCE.

An attacker holding (or self-registering into) a Contributor account opens the post edit screen to obtain a valid nonce, then submits a request with a malicious 'post_ID' value crafted so its integer prefix passes the edit_post capability check while its full string body is concatenated into the plugin's SQL query. Using UNION or stacked/appended sub-queries they exfiltrate data such as user password hashes and secret keys from the database. No public exploit code was identified in the provided data, but the technique is standard and low-complexity.