CVE-2026-18032

The CVSS 7.5 rating for CVE-2026-18032 masks a more serious architectural failure in WP Data Access. The vulnerability isn't simply 'missing validation' — it's a nonce being pressed into service as an authorization mechanism for a data access primitive it was never designed to guard. WordPress nonces are CSRF tokens. They prove a request originated from a legitimate form submission, not that the requested operation is authorized. WP Data Access conflates these two distinct security boundaries: the nonce guards the AJAX action's existence, but column names are user-supplied parameters that fall outside that guard's scope. The plugin architecture treats 'you submitted this form' as equivalent to 'you are allowed to read any column you name.' That's a fundamentally broken access control model, not a simple input validation lapse. The 'arbitrary column' language in the CVE description understates the real risk. An attacker needs to know or infer table structure, but the WordPress users table schema is well-documented. Unauthenticated password hash extraction is high-value credential compromise that transforms this from 'data curiosity' to 'material for lateral movement.' If this vulnerability existed quietly before disclosure, those hashes may already be in attacker hands — remediation after credential compromise is account lockout theater, not genuine security. Defensive steps: First, confirm whether your WP Data Access version is current. Second, audit any `wp_ajax_nopriv_*` handlers in your plugin ecosystem for `$wpdb` calls without preceding `current_user_can()` checks — this is a known anti-pattern. Consider implementing code analysis tooling that flags this pattern. Third, if you run this plugin, treat any WordPress user password hashes as potentially compromised: enforce password resets immediately rather than waiting for indication of active exploitation. The broader pattern here represents infrastructure debt, not individual negligence. WordPress's AJAX layer explicitly permits unauthenticated access via `wp_ajax_nopriv_*` but provides zero built-in capability-based authorization. Developers wanting public AJAX functionality face a choice: implement custom authorization for every handler, or use the nonce as a proxy for 'logged-in users are authorized.' That second option is architecturally seductive precisely because the framework offers no sanctioned alternative. Review your own plugin stacks for this pattern — it's likely more prevalent than any single CVE suggests.

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