Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2025-6187 is a critical-severity Missing Authorization (CWE-862) vulnerability in Wordpress (inferred from references). Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 48th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
The bSecure plugin for WordPress is affected by CVE-2025-6187, a privilege escalation vulnerability present in versions 1.3.7 through 1.7.9. The flaw exists in the order_info REST endpoint, where the /webhook/v2/order_info/ route is registered with a permission_callback that always returns true, completely bypassing authorization controls.
Unauthenticated attackers who know any user's email address can invoke the endpoint to obtain a valid login cookie and fully impersonate the targeted account. The vulnerability is tracked under CWE-862 and carries a CVSS 3.1 score of 9.8, indicating it is remotely exploitable without authentication or user interaction.
References point to the plugin source on WordPress Trac and a Wordfence advisory, but provide no explicit details on mitigation steps or patched versions. The EPSS score remains flat at 0.0114 with no material rise from its peak, indicating limited observed exploitation interest to date.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-22299
Vulnerability Data
The bSecure plugin for WordPress is vulnerable to Privilege Escalation due to missing authorization within its order_info REST endpoint in versions 1.3.7 through 1.7.9. The plugin registers the /webhook/v2/order_info/ route with a permission_callback that always returns true, effectively bypassing all…
more
authentication. This makes it possible for unauthenticated attackers who know any user’s email to obtain a valid login cookie and fully impersonate that account.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Direct unauthenticated exploitation of public WordPress REST endpoint (T1190) to obtain valid session cookies enabling account impersonation (T1078 + T1550.004).
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces authorization decisions on the /webhook/v2/order_info/ endpoint instead of allowing a permission_callback that always returns true.
Requires that any authenticated session obtained via the endpoint be restricted to the minimum privileges needed, limiting the impact of impersonation.
Mandates timely application of the vendor patch that replaces the always-true permission_callback with proper authorization logic.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Explicitly requires defining, enforcing, and reviewing authorizations and least privilege, directly preventing missing authorization checks.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Requiring authentication and credentials before any access occurs eliminates the absence of authorization checks that would otherwise allow an unauthenticated actor to reach protected resources.
Requiring formal authorization of every access request before rights are granted ensures that checks for required permissions are performed, preventing missing authorization checks from being introduced.
Mandatory authorization checks and central records of granted rights ensure that every access attempt is preceded by an explicit decision rather than relying on missing checks.
Segregating the approval of access rights from their implementation provides an independent check that reduces the impact of missing authorization checks in the resulting system configuration.
By requiring competent outsiders to verify that every function enforces the need-to-know principle, the control lowers the likelihood that missing authorization checks persist undetected.
Defining authorization responsibilities and reviewing risk-treatment progress throughout the project lifecycle catches missing authorization checks before the system is deployed.