CVE-2026-17022 is an enumeration vulnerability in a WordPress booking plugin's confirmation workflow. The issue is not missing authorization—it's authorization that checks whether a token exists rather than whether the token belongs to the session making the request. An attacker can iterate through sequential booking IDs and retrieve confirmation data (names, phone numbers, addresses, notes) without any authentication.
The structural weakness is the sequential booking identifier itself. In multi-step wizard flows, developers often maintain state across HTTP requests by passing a token, but they conflate 'this token is valid' with 'this token proves the requester owns this booking.' If the confirmation endpoint accepts a booking_id parameter and returns data based solely on whether that ID exists in the database, you have this vulnerability—regardless of whether the request includes a session cookie, auth header, or any other identity proof.
What to check in your deployment: First, confirm whether your booking plugin version is affected—look for the confirmation or booking-lookup endpoint and test whether passing a sequential ID returns record data without requiring login. Second, audit what fields the endpoint exposes; booking confirmations typically reveal the highest-sensitivity PII (phone numbers, addresses, special requirements notes) compared to other plugin flows. Third, check whether the plugin shares a user database with WooCommerce or other plugins—if booking records cross-reference customer accounts, the enumeration extends beyond booking data into purchase history and shipping addresses.
The patch needs to add explicit session-to-booking binding, not just randomize the token format. Switching from sequential IDs to UUIDs without adding ownership verification merely makes enumeration noisier rather than eliminating it—the underlying assumption that 'valid token implies authorized requester' remains. Verify the fix includes a check that the session or user ID matches the booking's owner before returning any data.
Longer-term: treat booking records as having a security half-life. PII collected under vulnerable versions remains enumerable in historical records even after patching. Audit old booking data, consider whether historical records need retention, and monitor for unusual enumeration patterns in your access logs.