CVE-2026-14843

This vulnerability stems from a fundamental category error: the developer treated WordPress nonce verification as authorization, when it only proves a request originated from a legitimate site form—not that the requester has permission to modify the targeted resource. The plugin's AJAX handler for modifying person records validated a nonce but performed no ownership check or capability verification. With a valid nonce (which is trivially obtainable from any public form on the site), an attacker can enumerate record IDs and overwrite data for any person in the system. The nonce stops automated CSRF bots but provides zero defense against a directed attacker who reads the API. The critical technical detail to verify: check whether the AJAX handler was registered with the 'nopriv' hook (wp_ajax_nopriv_*) which would make it reachable by unauthenticated users. If so, any visitor could modify any person record. If only wp_ajax_* was used, authenticated users with subscriber-level access could still exploit the IDOR to modify records outside their scope—both represent serious authorization failures. What to check in your WordPress plugins: any AJAX handler processing data modifications must include explicit current_user_can() checks or ownership validation (verifying the current user owns or can edit the targeted record). A nonce verifies request origin; it does not verify permission to perform the action. If your code has 'if (check_ajax_referer(...))' without subsequent authorization logic, you have this vulnerability. The CVSS score understates the severity. This is a maximal blast radius: unauthenticated attackers with no account can enumerate and modify the entire person database. The attack requires only reading the JavaScript to find the endpoint and parameter names, then scripting ID enumeration.

Reviewed through automated stages and approved by a human before publication.