CVE-2026-97287 Routing around a working whitelist in Event Tickets

Event Tickets sells tickets and collects RSVPs for WordPress events. Intrudify's autonomous testing engine found that the Tickets Commerce Orders report takes its sort parameter from the request without validation, and that when that parameter arrives as an array, the sort direction is read from the array value and concatenated into the SQL.

The injected expression is evaluated by MySQL against the whole database, so a Contributor, the lowest role that can author a post, can read any table.

The value arrives unvalidated

In src/Tickets/Commerce/Admin_Tables/Orders.php:

$orderby = tribe_get_request_var( 'orderby' );        // line 157
...
if ( ! empty( $orderby ) ) {
    $arguments['orderby'] = $orderby;                // line 211, no validation
}

The direction is taken from the array value

In Order_Repository.php, the repository walks the parameter and decides which part is the column and which is the direction based on whether the key is numeric:

foreach ( $check_orderby as $key => $value ) {
    $order_by = is_numeric( $key ) ? $value : $key;
    ...
    $order    = is_numeric( $key ) ? $default_order : $value;

Sending orderby[purchaser_full_name]=... makes the key a string, so $order becomes the attacker-supplied array value. That value is passed on to the shared query filter.

Why the whitelist does not apply

This is the interesting part. The codebase does validate sort direction:

// common/src/Tribe/Repository.php:756
if ( ! in_array( $order, [ 'ASC', 'DESC' ], true ) ) {
    return $this;
}

That check is correct, strict, and effective. It simply lives in order(), which is reached only by the scalar order parameter. The array form carries its direction inside orderby, so it travels a path that never calls order() and is never checked. The defence exists and the attacker walks around it rather than through it.

The sink

In common/src/Tribe/Repository/Query_Filters.php:

$buffer[] = sprintf( '%s %s', $orderby, $order );

Concatenated into ORDER BY with no escaping, no prepared statement and no column whitelist.

Why the added slashes do not help

WordPress adds backslashes to request values, which usually frustrates injection by breaking out of string literals. Here the value lands in an unquoted SQL context, so there is no string literal to escape from, and the working payload contains no quote characters at all. The protection is irrelevant rather than bypassed.

We confirmed this on a clean installation of WordPress 7.1, PHP 8.3, MariaDB 11 and Event Tickets 5.29.5 from the official wordpress.org package, with no other plugin present, using a stock Contributor account created through Users, Add New. That account's admin menu contains only Dashboard, Posts, Comments, Profile and Tools.

Response times against the same page in the same session, changing only the sort parameter:

The last two form a boolean oracle: true sleeps, false does not. The delay is a multiple of the number of rows the report lists, because MySQL evaluates the ORDER BY expression once per row, which is why three orders produce roughly six seconds from a two-second sleep.

Binary searching that oracle per character recovered the administrator user_login and the first twelve characters of the administrator user_pass hash, both matching the database exactly, entirely from the Contributor session. We also captured the reached statement from the MariaDB general log, confirming the expression arrives in the query rather than being inferred from timing alone.

One note for anyone reproducing it: if the event has zero orders the page still returns 200 and the SQL still reaches the database, but MySQL never evaluates an ORDER BY expression over an empty result set, so nothing sleeps and the bug appears absent. The event needs at least one order.

Contributor is the lowest role that can author a post, and it is a role sites routinely hand to outside writers and guest event organisers. It grants no access to Users, Plugins, Settings or the Tickets screens.

With this vulnerability that account reads administrator password hashes and every user email address, along with every Tickets Commerce order record, which on this plugin means purchaser names, email addresses and payment metadata. The exposure is the whole database, not only the plugin's own tables.

The same sink is reachable through several sibling keys handled by the same switch, including orderby[purchaser_email] and orderby[total_value], so fixing the single parameter we reported would not close it.

Update Event Tickets to 5.29.5.1 or later.

For maintainers, the direction taken from the array form of orderby needs the same ASC and DESC validation the scalar form already receives, applied where the value is consumed rather than in one of the two functions that can consume it. The column name deserves a whitelist for the same reason, since it is also concatenated. More generally, a validation routine that protects one entry point into a shared sink protects only that entry point.

Nothing here is a missing check. The ASC and DESC whitelist is present, strict and correctly written, and a reviewer who finds it can reasonably conclude that sort direction is handled. The vulnerability is that a second path into the same sink does not pass through it.

The mechanism that creates the second path is worth recognising on its own: a parameter that accepts both a scalar and an array, with different code interpreting each shape. PHP makes this easy to do accidentally, because whether a request parameter arrives as a string or an array is entirely the caller's choice. Wherever a function branches on is_numeric($key) or is_array($value) to decide what a value means, the attacker, not the developer, picks which branch runs.

The generalisable check: find the sink first, then enumerate every path that reaches it, and confirm the validation sits on the sink rather than on one of the paths. Auditing from the defence outward, which is the natural direction for a human reading code, systematically misses the routes that bypass it.