The Events Calendar Extension: Test Data Generator WP Registry grade C-. High-severity findings · 1 findingWP RegistryHigh-severity findings · 1 findingOpen the reportC-

High-severity findings.

Audited release

1.2.2

Findings

1

Worst severity

high

Content hash

ff889683242f87684bfe9f27… Copy

Findings

• high Destructive test-data actions require only edit_posts, not manage_options

  missing_capability

  The Events > Test Data screen is registered with add_submenu_page capability edit_posts. parse_request is attached to load-{$menu_hook} (Hooks::on_admin_init) and, after a tribe-ext-test-data-generator nonce, performs mass state changes with no current_user_can: Utils::clear_generated, Utils::clear_all (deletes every Venue/Organizer/Event via the TEC ORM, then every tribe_events_cat term), Utils::reset_tec_settings (delete_option on tribe_events_calendar_options and related TEC/widget/PUE keys), and do_action('tec_ext_test_data_generator_handle_batch') which creates published events/venues/organizers and uploads remote images. WordPress core only checks the submenu cap before firing that load hook, so any role with edit_posts — Contributor, Author, Editor, WooCommerce Shop Manager — can load the page, copy the nonce from wp_nonce_field, and POST. That is below manage_options. Event::create additionally add_filter('user_has_cap') to force tribe_events/post edit_posts and category/tag assign_terms for the create call, so a Contributor who cannot publish through the normal Events UI still inserts post_status=publish events that the public calendar displays. clear_all/reset_tec_settings are site-wide integrity/availability (empty calendar, factory-reset TEC settings including map API keys). Quantity from POST is not absint'd; leftovers are queued with as_enqueue_async_action so the same low-priv user can keep generating in 50-row batches. This is a test-data generator and should not run on production; if it does, these actions must require manage_options (or a dedicated cap) inside parse_request itself, not only as a menu flag.

  src/Tribe/Page.php:105-174

  Recommendation

  Require current_user_can('manage_options') (or a dedicated cap such as manage_tribe_events) at the start of parse_request, and pass that same cap to add_submenu_page. Do not treat wp_verify_nonce as authorization. Remove or hard-disable clear_all/reset_tec_settings on non-development environments (for example WP_ENVIRONMENT_TYPE === 'production'). Drop the user_has_cap override or keep it only for WP-CLI. Cap and absint quantity/content_length before queueing Action Scheduler batches.

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.