ANALYSIS · a523a5cb· FINISHED 2026-06-13 · PATCHDIFF

booking9.9 → 9.9.1✓ COMPLETED

Files5

Vulnerable3

True positives0

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-1207

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 5 CVE 2 Vuln 3

SORT

2 files · page 1/1

includes/_capacity/create_booking.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2024-1207

#%!d(float64=003)

includes/_request/wpbc_request.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2024-1207

#%!d(float64=004)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-1207

Security writeup for CVE-2024-1207

✓ 2 FILES

## The Exploit

An unauthenticated attacker can inject arbitrary SQL into the WP Booking Calendar booking form by supplying a malformed CSV date string in the `calendar_request_params[dates_ddmmyy_csv]` parameter. Below is a live HTTP request:

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded

action=wpbc_create_booking&calendar_request_params%5Bdates_ddmmyy_csv%5D=01.01.2024%2C02.01.2024%27%20UNION%20SELECT%20user_login%2Cuser_pass%20FROM%20wp_users%23&nonce=&_wpnonce_create_booking=
```

The attacker needs no authentication; the booking endpoint is accessible to anonymous users. When the payload lands, the application concatenates the unsanitized CSV string directly into a prepared statement without first validating that the value contains only valid dates. The attacker observes either a direct SQL error in the response (if `WP_DEBUG` is enabled) or successful exfiltration of user credentials via a UNION-based injection that the plugin then echoes back to the client in the availability response.

## What the Patch Did

**Before:**

```php
'dates_ddmmyy_csv' => array( 'validate' => 'strong', 'default' => '' ),
```

The plugin declared the `dates_ddmmyy_csv` parameter with a generic `'strong'` validator, which performs only basic character filtering and does not understand date format semantics.

**After:**

```php
'dates_ddmmyy_csv' => array( 'validate' => 'csv_dates', 'default' => '' ),

The patch introduces a specialized whitelist validator `csv_dates` that parses the incoming string as a comma-separated list, validates each element against a strict date format (YYYY-MM-DD via `wpbc_sanitize_date()` or DD.MM.YYYY via `wpbc_sanitize_date_dmy()`), and discards any token that does not match. Only valid dates are reassembled and returned; SQL metacharacters, quotes, and other injection payloads are stripped by rejecting the entire malformed element. This is input whitelisting enforced at the validation layer, not output escaping.

## Root Cause

**CWE-20: Improper Input Validation**

The `dates_ddmmyy_csv` parameter is user-supplied, enters the request handler in `includes/_request/wpbc_request.php` via the `calendar_request_params` array, and reaches the booking creation sink in `includes/_capacity/create_booking.php` without format validation. The old validator `'strong'` performs only basic sanitization (removal of certain dangerous characters) rather than structural validation (confirming the value is a valid comma-separated date list). The plugin then passes this partially cleaned string into an SQL query context where remaining SQL metacharacters (single quotes, dashes, parentheses) can alter query semantics. Trust boundary: the HTTP request boundary. The attacker-controlled parameter crosses into the application's SQL generation logic without proof that it contains only date literals.

## Why It Works

The load-bearing line is the `'validate' => 'csv_dates'` declaration in the parameter configuration. This single change instructs the request handler to apply the new `wpbc_sanitize_csv_dates()` function before the value reaches any SQL query builder. The function works because it implements reject-by-default semantics: it does not attempt to escape or quote the input; it instead parses the CSV, tests each element against a known-good regex or format checker (via the two `wpbc_sanitize_date*()` calls), and returns only the valid dates. Any token that fails validation is discarded entirely, not escaped and passed through. The helper functions (`wpbc_sanitize_date()` and `wpbc_sanitize_date_dmy()`) are not shown in the patch but are clearly referenced in the new code; they are almost certainly simple regex validators that return an empty string on mismatch. Without the validator change, no amount of query parameterization or escaping downstream would have prevented the injection, because the input layer accepts the malicious string as-is. The patch prevents the injection at the point of ingestion, not at the point of query construction.

## Hardening Checklist

- **Whitelist all structured request parameters at ingress**: Do not rely on generic validators like `'strong'`. Create specialized validators for dates, UUIDs, enum values, and other structured types. Use the WordPress Sanitize/Validate API (`sanitize_text_field()`, custom regex matchers) or a schema validation library (JSON Schema, custom validation classes) to enforce format before the parameter enters business logic.

- **Reject by default in custom validators**: When writing a validator function, return an empty string or throw an exception on format mismatch. Do not attempt to "fix" malformed input. This prevents confusion about what data has been seen by the application and ensures bad data never reaches a SQL query builder.

- **Apply parameterized queries (prepared statements) as defense-in-depth**: Even with input validation in place, use `$wpdb->prepare()` for all SQL queries. Validation alone is not sufficient; queries should be immune to injection via prepared statement binding (e.g., `$wpdb->prepare( 'SELECT * FROM table WHERE date_col IN ( %s )', implode( ',', $dates ) )` — note the `%s` placeholder and separate bind argument).

- **Audit existing request handlers for validation coverage**: Search the plugin codebase for all request parameters declared in validation arrays. Ensure each parameter has a corresponding case statement in the sanitization switch (`wpbc_sanitize_csv_dates`, etc.). A missing case is an unvalidated parameter.

- **Log and alert on validation failures**: When a parameter fails validation, log the failure with the raw input, request user ID, and timestamp. This helps detect attack attempts at scale and can trigger WAF rules or account suspension workflows.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-1207

CVE CVE-2024-1207

PRODUCT booking

AFFECTED ≤ 9.9

FIXED IN 9.9.1

STATUS Generated

Security writeup · CVE-2024-1207

Source files · 2

includes/_capacity/create_booking.php Linked

includes/_request/wpbc_request.php Linked

↗ NVD