EUVD-2026-57900
GHSA-f2g5-m4pp-93xm
Severity by source
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
Network-submitted stored XSS with low-privilege customer submission and required admin interaction; A:N as XSS carries no direct availability impact on the system.
Primary rating from Vendor (Patchstack).
CVSS VectorVendor: Patchstack
Lifecycle Timeline
1DescriptionCVE.org
Customer Cross Site Scripting (XSS) in WpBookingly <= 1.3.2 versions.
AnalysisAI
Stored Cross-Site Scripting in WpBookingly (WordPress plugin by MagePeople Team, versions ≤ 1.3.2) allows a low-privileged attacker - such as an external customer submitting a booking request - to inject malicious scripts into customer-facing input fields that are later rendered unsanitized in the WordPress admin panel. When an administrator views the poisoned booking data, the injected script executes in their browser context, enabling session hijacking, credential theft, or unauthorized admin-level actions. No public exploit code or CISA KEV listing has been identified at time of analysis, but the network-accessible, low-complexity attack surface makes this a meaningful risk for any site accepting public booking submissions.
Technical ContextAI
WpBookingly is a service booking management plugin for WordPress developed by MagePeople Team, identified by CPE cpe:2.3:a:magepeopleteam:wpbookingly:*:*:*:*:*:*:*:*. The vulnerability is rooted in CWE-79 (Improper Neutralization of Input During Web Page Generation - Cross-site Scripting), specifically the stored (persistent) variant, as indicated by the 'Customer XSS' designation: attacker-controlled data submitted through booking intake forms is persisted server-side and later rendered in admin-facing views without adequate output encoding. The CVSS S:C (Scope Changed) metric confirms the injected payload executes in a security context distinct from where it was submitted - typically the WordPress administrator dashboard. WordPress plugins of this type frequently fail to apply wp_kses(), esc_html(), or esc_attr() to booking fields such as customer name, phone number, or notes when displayed in wp-admin booking management screens.
RemediationAI
Update WpBookingly to a version above 1.3.2 once MagePeople Team releases a patched build; the exact fix version is not confirmed in the available data and should be verified at the Patchstack advisory (https://patchstack.com/database/wordpress/plugin/service-booking-manager/vulnerability/wordpress-wpbookingly-plugin-1-3-2-cross-site-scripting-xss-vulnerability) before upgrading. As an interim compensating control, restrict access to the booking submission form to authenticated and trusted users only, eliminating anonymous external attackers from the attack surface - note this trade-off may impact business operations for sites relying on public booking intake. Deploy a WAF rule filtering common XSS patterns (script tags, JavaScript event handlers) in booking-related POST parameters; be aware this may block legitimate special characters in customer name or notes fields. Audit existing booking records in the WordPress admin panel for suspicious HTML or script content as an indicator of prior exploitation before applying the patch.
More in Wpbookingly
View allWpBookingly plugin versions 1.2.9 and earlier contain a local file inclusion vulnerability in their service-booking-mana
Broken access control in the WpBookingly WordPress plugin (Magepeople Inc.) through version 1.2.9 enables network-authen
Missing authorization checks in the WpBookingly WordPress plugin (versions through 1.2.9) allow authenticated low-privil
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today