CVE-2026-83593: WPBot: unauth stored XSS in chatbot conversation field

HIGH
Published September 9, 2026
CISO Take

An unauthenticated stored cross-site scripting flaw in WPBot, a widely-installed WordPress AI chatbot plugin, lets any anonymous visitor inject persistent JavaScript via the public 'conversation' parameter because the plugin's nonce check is meaningless — that nonce is localized into every public page via wp_localize_script, so it provides zero access control against unauthenticated attackers. This should worry security teams because the plugin has an existing track record (11 other CVEs in the same package) suggesting a pattern of insufficient input handling, and the payload persists until an administrator or support agent views the stored chat session in wp-admin, at which point it executes with their privileges. There is no CISA KEV listing, no EPSS score, and no known public exploit or Nuclei template yet, so opportunistic mass-exploitation risk is currently low but the attack complexity is trivial (AC:L, PR:N, UI:N) and the vulnerability requires no special skill. Sites running WPBot up to and including 8.7.3 should update to the patched release as soon as it is available, and in the interim strip or heavily sanitize chatbot transcripts before rendering them in the admin UI, restrict admin session review to a hardened browser profile, and monitor chat-session content for script tags or event-handler attributes as a detection signal. Because this is a classic web-layer stored XSS rather than a novel LLM-specific attack technique, it should be tracked as a plugin patch item, not escalated as a breaking AI-threat alert.

Sources: NVD ATLAS

What is the risk?

CVSS 7.2 (high) with network attack vector, low complexity, no privileges and no user interaction required for the attacker makes this trivially exploitable by any unauthenticated actor who can reach the site's public chatbot widget. The scope is changed (S:C), meaning the injected script executes in the security context of whoever views the stored conversation in wp-admin — typically a site administrator or support staff with elevated privileges — turning a low-impact confidentiality/integrity flaw (C:L/I:L) into a realistic path to admin session hijacking. Absence from CISA KEV, no EPSS percentile, and no public exploit/Nuclei template currently lower the near-term mass-exploitation likelihood, but the trivial exploitation bar and the plugin's history of 11 other CVEs suggest opportunistic scanning is plausible once details circulate.

How does the attack unfold?

Initial Access
Unauthenticated attacker submits a malicious script payload via the public WPBot chatbot widget's 'conversation' parameter.
AML.T0049
Storage
The payload is persisted server-side without sanitization due to insufficient input validation and output escaping (CWE-79).
Trigger
A site administrator or support agent opens the wp-admin chat-sessions view to review the stored conversation, causing the browser to render and execute the injected script.
Impact
The script executes in the admin's authenticated session, enabling cookie/session theft, unauthorized admin account creation, or further site compromise.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
WPBot pip No patch

Do you use WPBot? You're affected.

How severe is it?

CVSS 3.1
7.2 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 23% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Changed
C Low
I Low
A None

What should I do?

1 step
  1. Update WPBot to the first version beyond 8.7.3 once a patch is released (no patched version is listed yet in the available data — monitor the Wordfence advisory and plugin changelog). Until patched, consider disabling or gating the public chatbot widget, or placing a WAF rule in front of the conversation-submission endpoint to strip HTML/script tags from inbound conversation payloads. Do not rely on the plugin's existing nonce check as an access-control mechanism — it is localized into every public page and does not gate unauthenticated requests. For detection, audit stored chat-session content in the WordPress database for <script>, onerror=, onload=, or javascript: patterns, and review wp-admin activity logs for anomalous admin actions immediately following chat-session views. As a defense-in-depth measure, restrict wp-admin chat-session review to accounts with a strict Content-Security-Policy applied to the admin dashboard.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable Yes
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Code Execution Data Leakage Plugin Agent AML.T0049

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MEASURE 2.7 - AI system security and resilience testing
OWASP LLM Top 10
LLM02:2025 - Insecure Output Handling

Frequently Asked Questions

What is CVE-2026-83593?

An unauthenticated stored cross-site scripting flaw in WPBot, a widely-installed WordPress AI chatbot plugin, lets any anonymous visitor inject persistent JavaScript via the public 'conversation' parameter because the plugin's nonce check is meaningless — that nonce is localized into every public page via wp_localize_script, so it provides zero access control against unauthenticated attackers. This should worry security teams because the plugin has an existing track record (11 other CVEs in the same package) suggesting a pattern of insufficient input handling, and the payload persists until an administrator or support agent views the stored chat session in wp-admin, at which point it executes with their privileges. There is no CISA KEV listing, no EPSS score, and no known public exploit or Nuclei template yet, so opportunistic mass-exploitation risk is currently low but the attack complexity is trivial (AC:L, PR:N, UI:N) and the vulnerability requires no special skill. Sites running WPBot up to and including 8.7.3 should update to the patched release as soon as it is available, and in the interim strip or heavily sanitize chatbot transcripts before rendering them in the admin UI, restrict admin session review to a hardened browser profile, and monitor chat-session content for script tags or event-handler attributes as a detection signal. Because this is a classic web-layer stored XSS rather than a novel LLM-specific attack technique, it should be tracked as a plugin patch item, not escalated as a breaking AI-threat alert.

Is CVE-2026-83593 actively exploited?

No confirmed active exploitation of CVE-2026-83593 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-83593?

Update WPBot to the first version beyond 8.7.3 once a patch is released (no patched version is listed yet in the available data — monitor the Wordfence advisory and plugin changelog). Until patched, consider disabling or gating the public chatbot widget, or placing a WAF rule in front of the conversation-submission endpoint to strip HTML/script tags from inbound conversation payloads. Do not rely on the plugin's existing nonce check as an access-control mechanism — it is localized into every public page and does not gate unauthenticated requests. For detection, audit stored chat-session content in the WordPress database for `<script>`, `onerror=`, `onload=`, or `javascript:` patterns, and review wp-admin activity logs for anomalous admin actions immediately following chat-session views. As a defense-in-depth measure, restrict wp-admin chat-session review to accounts with a strict Content-Security-Policy applied to the admin dashboard.

What systems are affected by CVE-2026-83593?

This vulnerability affects the following AI/ML architecture patterns: Conversational AI / chatbot interfaces, Public-facing AI plugin integrations (WordPress).

What is the CVSS score for CVE-2026-83593?

CVE-2026-83593 has a CVSS v3.1 base score of 7.2 (HIGH). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

Conversational AI / chatbot interfacesPublic-facing AI plugin integrations (WordPress)

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

The WPBot – AI ChatBot for Live Support, Lead Generation, AI Services plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'conversation' parameter in all versions up to, and including, 8.7.3 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The action is gated only by a nonce that is localized into every public-facing page via wp_localize_script, rendering the nonce check ineffective as an access control barrier for unauthenticated users.

Exploitation Scenario

An unauthenticated attacker visits a target site's public-facing WPBot chatbot widget and submits a message crafted with an embedded script payload (e.g., disguised as normal chatbot conversation text) instead of a legitimate query. The plugin stores this payload unsanitized in the chat-sessions table. When a site administrator or support agent later opens the WordPress admin dashboard to review chatbot conversations for lead follow-up or QA, the stored script executes in their authenticated browser session with wp-admin privileges — enabling cookie/session theft, silent creation of a new admin account, or redirection to a credential-phishing page, all without the attacker ever needing valid credentials or the admin clicking a suspicious link.

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
September 9, 2026
Last Modified
September 9, 2026
First Seen
September 9, 2026

Related Vulnerabilities