WP Express Checkout CVE-2026-96818

No special conditions - remote unauthenticated exploitation against default installations of the WP Express Checkout (Accept PayPal Payments) WordPress plugin at version 2.4.9 or earlier, per PR:N/UI:N/AC:L. The only requirement is that the vulnerable plugin be installed and active. The limiting factor is version scope (must be ≤2.4.9) and that impact is confined to integrity (C:N/A:N), meaning the attacker can alter but not read data or take the site offline through this flaw; the specific protected function that is exposed is not documented in available data.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, base 7.5) describes an unauthenticated, network-reachable, low-complexity flaw requiring no user interaction, with a pure high-integrity impact and no confidentiality or availability effect - consistent with CWE-862 missing authorization allowing an attacker to invoke a protected action or modify state they should not. All exploitation-likelihood signals are absent: no EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis'. No SSVC decision data was supplied. The 7.5 rating is driven entirely by the unauthenticated/no-UI access profile rather than by observed exploitation, so this is a credible but not confirmed-urgent priority: broken access control in a payment-handling plugin is inherently attractive (potential to tamper with payment/order state), but the integrity-only scope and lack of exploitation evidence keep it below actively-exploited critical issues. The exact protected function affected is not stated in the sparse Patchstack-sourced description, which is the main gap in assessing real-world impact.

A remote, unauthenticated attacker sends a crafted HTTP request directly to an access-control-deficient endpoint or AJAX action in the WP Express Checkout plugin, invoking a privileged operation or altering data (e.g., payment/order-related state) without any login. Because no authentication, user interaction, or special configuration is required, the request can be scripted against any site running the vulnerable plugin. No public proof-of-concept exploit was identified at the time of analysis.