CVE-2026-7753

This vulnerability exposes a fundamental architectural weakness in how WordPress AJAX handlers conflate CSRF protection with authorization. The plugin's export handler at `admin-ajax.php?action=ccb_export_calculators` returns plaintext payment credentials (Stripe secret keys, PayPal client secrets, Razorpay keys) to any authenticated user with Subscriber-level access or higher — the lowest privilege tier in WordPress. The handler verifies a nonce but performs no capability check, so any logged-in user can trigger the export and retrieve credentials stored in the calculator configuration database rows. The deeper problem isn't a missing `current_user_can()` call — it's that WordPress's AJAX architecture creates structural incentives to skip authorization checks. The `wp_ajax_*` hook fires for any logged-in user; the framework provides nonce verification but never enforces capability verification. Developers reach for the nonce first because it exists, it's familiar, and it 'proves' the user initiated the request intentionally. That feels like security, even though nonce verification and authorization are distinct concerns. The path of least resistance wins every time under pressure. What compounds this vulnerability is the credential storage approach. Payment gateway secrets are stored as plaintext in the WordPress options table, serialized alongside calculator configurations. This wasn't a deliberate security decision — it emerged from WordPress's plugin architecture, where the options API is the path of least resistance for persisting settings. The export handler, likely added years ago for backup and migration purposes, was never revisited as the plugin accumulated payment integrations. Forgotten functionality became a retrieval mechanism for data that should never have been persisted in this form. The CVSS 6.5 MEDIUM rating fundamentally miscalibrates this vulnerability. Payment API keys cannot be rotated without potential business interruption — Razorpay keys used for webhook signature verification are bound to account configuration. Unlike patchable code flaws, credential exposure is irreversible once keys leave the database. The real business risk approaches 9+ for any site that cannot perform non-disruptive secret rotation. The CVE severity score systematically undervalues this class of vulnerability, which means organizational resources flow elsewhere while the exposure compounds. Immediate remediation requires three layers. First, patch the plugin immediately — the fix must add `current_user_can('manage_options')` or equivalent capability verification before any export operation. Second, rotate every payment credential that was stored in calculator configurations, treating this as a confirmed compromise regardless of whether you see exploitation evidence. Third, audit for similar forgotten AJAX handlers across other plugins in your stack — the pattern of 'export functionality added early, never audited as the plugin grew' is the actual blast radius multiplier. The vulnerability isn't just this one handler; it's the architectural failure mode that will produce the next one in a different plugin, and the next, until the ecosystem introduces friction at the framework level to make capability checks the default.

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