WP Travel Engine CVE-2026-17087 Exposes Booking Details Without Authorization

When a booking ID becomes an access decision

CVE-2026-17087 affects WP Travel Engine through version 6.8.4. The plugin accepts an arbitrary booking_id and can bind it to an unauthenticated visitor's session without verifying that the visitor is authorized to view that booking. Private billing details then appear as default values in checkout fields.

Data exposed by the vulnerable flow

Wordfence lists the customer's first name, last name, email address, street address, city, and phone number as exposed fields. The issue does not require a special export function: the normal checkout interface can populate another customer's billing data after the attacker associates a chosen booking ID with the attacker's session.

Why the public nonce is not authorization

Trip pages expose the frontend nonce through the wteL10n global object. That value can provide CSRF protection, but every visitor can obtain it and it does not prove ownership of a booking. The missing control is a separate authorization check that binds the requested booking to an authenticated account, validated session, or another trusted ownership token.

Affected and patched releases

Wordfence identifies versions through 6.8.4 as affected and version 6.8.5 as patched. The CVSS 3.1 base score is 7.5, reflecting network access without privileges or user interaction and a high confidentiality impact. Sites should verify the actual installed release across production, staging, and restored instances rather than relying only on an automatic-update setting.

Update and verification sequence

1. Record the installed version and the current booking and checkout behavior.
2. Confirm backup and recovery readiness for WordPress files and the database.
3. Install WP Travel Engine 6.8.5 or a later patched release from the trusted distribution path.
4. Clear page, object, and deployment caches that may continue serving older code.
5. Retest legitimate booking, lookup, and payment workflows.
6. Verify that a logged-out or unrelated session cannot use an arbitrary booking_id to populate private booking details.

Reviewing earlier exposure

Updating the plugin closes the known authorization gap but does not determine whether booking records were viewed before the change. Preserve relevant web and application logs and look for repeated changes to booking identifiers, access to multiple bookings from one session, and unusual request sequences. No single request string proves compromise; timestamps, session context, response status, and booking access records should be considered together.

If suspicious access is found, preserve the original records before cleanup and determine which booking fields were actually returned, over what period, and to which sessions. Running an affected version and confirming unauthorized disclosure are separate findings, so the number of impacted customers should not be inferred without evidence.

Verification basis

This article was checked against the Wordfence Intelligence record and the CVE record at 16:55 KST on August 17, 2026. Confirm the latest supported release and compatibility requirements through the official distribution channel before production deployment.