CVE-2026-109232: Salon Booking System WordPress XSS Vulnerability

CVE-2026-109232 Overview

CVE-2026-109232 is a stored Cross-Site Scripting (XSS) vulnerability in the Salon Booking System – Appointment Booking for Salons, Barbershops & Spas plugin for WordPress. The flaw affects all versions up to and including 10.31.9. Unauthenticated attackers can inject arbitrary web scripts through the sln[<checkout-field-key>] parameter due to insufficient input sanitization and output escaping. Injected scripts execute whenever a user, including an authenticated administrator, loads a page that renders the stored payload. Exploitation requires that the site administrator has configured at least one custom checkout field of type Html or File, which is a standard documented plugin feature. The weakness is tracked under [CWE-79].

Critical Impact
Unauthenticated attackers can store JavaScript that executes in administrator browsers, enabling session theft, account takeover, and malicious actions in the WordPress admin context.

Affected Products

Salon Booking System – Appointment Booking for Salons, Barbershops & Spas plugin for WordPress
All versions up to and including 10.31.9
WordPress sites with at least one custom checkout field of type Html or File configured

Discovery Timeline

2026-10-16 - CVE-2026-109232 published to NVD
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-109232

Vulnerability Analysis

The vulnerability resides in the checkout flow of the Salon Booking System plugin. When a visitor submits a booking, the plugin accepts user-supplied values via the sln[<checkout-field-key>] parameter array. The input processing path spans src/SLN/Action/Init.php, src/SLN/Form.php, and the shortcode handlers in src/SLN/Shortcode/Salon/AbstractUserStep.php and DetailsStep.php. The values are later rendered in the WordPress admin customer view at views/admin/_customer.php without adequate escaping on lines 110 and 116.

Because the vulnerable parameter is a stored field tied to custom checkout fields of type Html or File, attacker-controlled markup is persisted in the database and reflected into administrative pages. The scope-changed Common Vulnerability Scoring System (CVSS) vector reflects that execution occurs in a different security context than the attacker-controlled input source.

Root Cause

The plugin fails to sanitize input on write and fails to escape output on render. Custom checkout field values keyed by sln[<checkout-field-key>] are stored verbatim and later emitted into HTML contexts without calls to WordPress escaping helpers such as esc_html() or wp_kses_post(). This classic stored XSS pattern is categorized under [CWE-79] (Improper Neutralization of Input During Web Page Generation).

Attack Vector

An unauthenticated attacker visits a public booking page on a vulnerable site, locates a custom checkout field of type Html or File, and submits a crafted payload through the sln[<checkout-field-key>] parameter. The payload is stored with the booking record. When an administrator or other privileged user opens the customer view in the WordPress admin, the injected script executes in their browser session. See the Wordfence Vulnerability Intelligence Report and the WordPress Plugin Change Set for the specific code paths and fix details.

No verified public proof-of-concept code is available. The vulnerability mechanism is described above based on the source references.

Detection Methods for CVE-2026-109232

Indicators of Compromise

Booking records containing HTML tags, <script> elements, or JavaScript event handlers (for example onerror=, onload=) in custom checkout field values.
Unexpected outbound requests from administrator browsers shortly after opening the customer view in wp-admin.
Creation of new WordPress administrator accounts or changes to user roles without a corresponding administrative action.
Unusual POST requests to the booking endpoint with payloads in sln[<checkout-field-key>] parameters.

Detection Strategies

Query the WordPress database for booking metadata containing <, >, script, or javascript: substrings within fields owned by the Salon Booking System plugin.
Review web server access logs for POST submissions to the booking shortcode handler that include encoded HTML or script tokens in sln[] parameters.
Deploy a Web Application Firewall (WAF) ruleset that inspects form submissions targeting the plugin's checkout endpoints for XSS payload patterns.

Monitoring Recommendations

Monitor the installed plugin version and alert when any site runs Salon Booking System at or below 10.31.9.
Enable Content Security Policy (CSP) reporting on administrator pages to surface injected inline scripts.
Audit administrator session activity for anomalous actions following access to customer or booking views.

How to Mitigate CVE-2026-109232

Immediate Actions Required

Update the Salon Booking System plugin to the version that supersedes 10.31.9 and includes the fix referenced in the plugin change set.
Audit all existing booking records for stored HTML or script content and sanitize or remove any entries with suspicious payloads.
Rotate credentials for WordPress administrator accounts that accessed the customer view while the vulnerable version was deployed.

Patch Information

The vendor committed a fix referenced in the WordPress Plugin Change Set for the Salon Booking System plugin. Site operators should upgrade to the patched release that follows 10.31.9. Review the plugin source references for Init.php, Form.php, and _customer.php to confirm the vulnerable code paths are remediated in your deployed build.

Workarounds

Remove any custom checkout fields of type Html or File until the plugin is updated, since exploitation requires this configuration.
Restrict public access to the booking page via IP allowlisting or require authentication where feasible.
Deploy a WAF rule that blocks <script> tags, event handler attributes, and javascript: URIs in POST parameters prefixed with sln[.
Apply strict Content Security Policy headers in the WordPress admin area to prevent inline script execution.

bash

# Example WAF rule concept for blocking XSS payloads in the vulnerable parameter
# ModSecurity-style pseudocode
SecRule ARGS_NAMES "@rx ^sln\[.*\]$" \
  "id:1092320,phase:2,deny,status:403,\
   chain,msg:'Potential XSS in Salon Booking System sln[] parameter'"
  SecRule ARGS "@rx (?i)(<script|javascript:|on[a-z]+\s*=)" "t:none,t:urlDecodeUni"