| Plugin Name | WP BookWidgets |
|---|---|
| Type of Vulnerability | Authenticated Stored XSS |
| CVE Number | CVE-2025-10139 |
| Urgency | Low |
| CVE Publish Date | 2025-10-15 |
| Source URL | CVE-2025-10139 |
WP BookWidgets (<= 0.9) — Authenticated (Contributor+) Stored XSS: What WordPress Site Owners Need to Know
Published: 15 October 2025
Severity: CVSS 6.5 (Medium / Low priority for immediate widespread exploitation)
CVE: CVE-2025-10139
Affected plugin: WP BookWidgets (versions ≤ 0.9)
Required privilege: Contributor (authenticated)
Fix availability: No official fix available at time of publication
As a Hong Kong security consultant experienced in WordPress incident response, I’ll present a concise, practical analysis of the stored Cross-Site Scripting (XSS) issue discovered in WP BookWidgets (versions up to 0.9). This is a stored XSS that allows an authenticated user with Contributor privileges to inject JavaScript which may execute in other users’ browsers. The CVSS is mid-range, but real-world risk depends on where the plugin renders contributor-submitted content and which accounts view it.
Executive summary (TL;DR)
- WP BookWidgets (<= 0.9) contains a stored XSS that can be exploited by a logged-in Contributor.
- Payloads submitted by Contributors may be persisted and later rendered to other users without proper escaping.
- Consequences include content manipulation, redirects, session theft and potential admin compromise when payloads execute in privileged contexts.
- No official patch is available yet. Immediate actions should focus on reducing exposure: restrict Contributor input, disable the plugin where feasible, sanitize stored data, and deploy virtual patching/WAF rules if you operate a WAF.
- Follow the detection and cleanup playbook below if you suspect compromise.
What is stored XSS and why this matters here
Stored XSS occurs when malicious input is saved on the server (database, files, etc.) and later served to users as part of a web page without proper output encoding. Stored XSS can affect many users over time and is especially dangerous when the stored content is rendered in administrative interfaces, because executed code runs in the context of the viewer (potentially an administrator).
This issue is significant because it can be triggered by a Contributor-level account — a role often used for external writers or guest contributors. If the plugin renders contributor-submitted HTML in admin review screens, previews, or public pages, a malicious script can execute in an admin or editor’s browser and take actions with their privileges.
How the WP BookWidgets issue works (high level)
- A Contributor submits content via the plugin UI (widget content, book widgets, shortcodes, or other inputs).
- The plugin stores that content without sufficient sanitization or mis-escapes it when rendering later.
- When another user (administrator, editor, or visitor) views the page where the content is rendered, the stored JavaScript executes in the viewer’s browser.
- Depending on the page context, the script can steal cookies/session tokens, perform authenticated actions (AJAX requests), inject additional malicious content, or create persistent backdoors.
Because exploitation requires a Contributor account, attackers may attempt to register or otherwise obtain such accounts through social engineering, weak registration controls, or other site weaknesses.
Realistic attack scenarios
- Admin takeover via admin UI rendering
If contributor content is rendered in an admin-only review screen, an attacker may store JS that runs when an admin opens that screen. The script could create a new admin via AJAX or modify options, enabling site takeover. - Credential or token theft from user-facing pages
If submitted content appears on the public site (book preview, embedded widget), injected JS could capture cookies or tokens from visitors and exfiltrate them. - Malvertising / redirects
Attackers can inject redirect scripts or ad code that damages reputation, triggers blacklisting, or causes SEO penalties. - Lateral movement / persistence
Executed JS can be used to upload backdoors, add malicious JavaScript to theme files (via authenticated requests), or create scheduled posts that contain further payloads.
Indicators of compromise (IoC) and what to look for now
If you suspect your site is affected, check the following: