Event Tickets Extension: Per Event Checkin API WP Registry grade B. Medium-severity findings · 1 findingWP RegistryMedium-severity findings · 1 findingOpen the reportB

Medium-severity findings.

Audited release

1.1.0

Findings

1

Worst severity

medium

Content hash

a076fb830714e971abcb23ca… Copy

Findings

• medium Per-event check-in API key authorizes any event: validation trusts client event_id, not the ticket's event

  auth_bypass

  The extension's purpose is to let the Event Tickets Plus QR app check in 'this Event Only' using a key stored in _et_event_api_key. Api_Handler::alter_default_api_with_event_api is the sole extra gate on the parent public check-in route (GET /wp-json/tribe/tickets/v1/qr, no permission_callback; API key is auth). After looking up the post that owns the submitted api_key, it only checks $posts[0]->ID != $qr_data['event_id'] and then returns true. qr_data['event_id'] is copied from the REST request in the parent's prepare_qr_arr() and is not a registered CHECK_IN_args field, so the client can set it independently of ticket_id. Parent check_in() then validates security_code against ticket_id and calls $service_provider->checkin($ticket_id, true); event_id is used only for the optional happening-now window, not to confirm the attendee belongs to that event. A Community Tickets organizer or door volunteer who was given event A's key (shown in add_community_tickets_api_box / the event metabox) can therefore check in event B attendees and receive attendee_data (name/email) by sending api_key=A, event_id=A, and B's ticket_id+security_code. The official app puts the QR's event_id on the wire, so an unmodified scan of B with A's key fails; a crafted request does not. The malformed-looking meta_query still matches the key value (WP_Query AND-combines meta_key with the nested clause); this is not a 'any key works' bypass. Site-wide tickets-plus-qr-options-api-key remains global by parent design and is not this finding.

  src/Tribe/Api_Handler.php:55-89

  Recommendation

  After resolving the API key to an event post, load the attendee's event from ticket_id (provider event meta / tickets.data_api) and require that ID to equal the key's event. Do not treat request event_id as authorization. Also hook tec_tickets_requested_api_is_valid (the 5.7.0 replacement) in addition to the deprecated event_tickets_plus_requested_api_is_valid filter.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.