What is the CVSS score of CVE-2026-8911?

CVE-2026-8911 has a CVSS 3.1 base score of 6.1 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. EPSS exploitation probability: 0.0%.

WP AutoBuzz CVE-2026-8911

EUVD-2026-32071 MEDIUM

Cross-Site Request Forgery (CSRF) (CWE-352)

2026-05-27 security@wordfence.com

GHSA-62xr-88cq-2vgw

WordPress CSRF

6.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

6.1 MEDIUM

AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

May 27, 2026 - 22:38 vuln.today

CVE Published

May 27, 2026 - 07:16 nvd

MEDIUM 6.1

DescriptionCVE.org

The WP AutoBuzz plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.1.1. This is due to missing or incorrect nonce validation on a function. This makes it possible for unauthenticated attackers to update settings and inject malicious web scripts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. This vulnerability bypasses WordPress's DISALLOW_UNFILTERED_HTML protection because the unsanitized value is written directly via update_option at the plugin level, entirely outside of WordPress post content handling.

AnalysisAI

Cross-Site Request Forgery in WP AutoBuzz (WordPress plugin, all versions ≤1.1.1) enables unauthenticated remote attackers to update plugin settings and inject persistent malicious scripts by tricking an authenticated administrator into clicking a crafted link. The attack carries particular severity because the unsanitized value is written directly via WordPress's update_option at the plugin level, entirely bypassing the DISALLOW_UNFILTERED_HTML hardening constant that would otherwise block unfiltered HTML in post content. No public exploit code and no active exploitation have been identified at time of analysis; EPSS is 0.02% and SSVC classifies exploitation status as none.

Technical ContextAI

The root cause is CWE-352 (Cross-Site Request Forgery) arising from missing or incorrect nonce validation on a settings-handling function within wp-autobuzz.php (lines 77, 81, and 93 per NVD references pointing to plugin tag 1.1.1 in the WordPress SVN repository). WordPress nonces serve as CSRF tokens tied to user session and action; their absence allows any forged POST from a logged-in administrator's browser to be accepted as legitimate. Compounding the issue, the plugin writes attacker-controlled input directly via update_option rather than routing it through WordPress post content pipelines, which means the DISALLOW_UNFILTERED_HTML constant - a WordPress hardening measure intended to strip unfiltered HTML from less-trusted roles - has no effect. The injected script is stored in the WordPress options table and rendered whenever the affected settings are output to the browser, creating a persistent (stored) XSS condition triggered by the initial CSRF.

RemediationAI

No vendor-released patched version is confirmed from available data; the NVD references point exclusively to tag 1.1.1, the highest affected version. Plugin owners should monitor the WordPress plugin repository and the Wordfence advisory at https://www.wordfence.com/threat-intel/vulnerabilities/id/481dc27b-0d64-49cc-8d67-50fa53636398?source=cve for a patch release and upgrade immediately when one becomes available. As a compensating control, deactivate and remove the WP AutoBuzz plugin until a patched version is released - this fully eliminates the attack surface with the trade-off of losing plugin functionality. If removal is not possible, restrict WordPress administrator accounts to trusted users only, enforce strong MFA on admin accounts to reduce phishing success, and configure a Web Application Firewall (WAF) rule to block unauthenticated or cross-origin POST requests to the plugin's settings endpoints (trade-off: WAF rules may require tuning and could block legitimate admin actions if misconfigured). Adding nonce verification to the affected function via wp_verify_nonce() is the correct developer-level fix.