Calendar+ (An Accessible Events Calendar) WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+

High-severity findings.

Audited release

2.2.15

Findings

3

Worst severity

high

Content hash

2eb5980af1dd4d0c2eba5eae… Copy

Findings

• high Unauthenticated REST deletion of arbitrary event dates via inverted permission check

  auth_bypass

  DELETE /wp-json/calendar-plus/v1/events/{id}/dates/{date_id} is gated by edit_item_permissions_check. That helper only returns WP_Error when get_post($id) is truthy AND the user lacks edit_calendar_events or manage_calendar_plus. If the event ID does not exist (0, 999999999, a purged post), the if-body is skipped and the callback returns true for unauthenticated and Subscriber users. delete_item_date then calls calendarp_delete_event_cell(date_id) with no check that the cell belongs to {id}, so any wp_calendarp_calendar row can be removed. Date IDs are sequential integers; an unauth client can wipe the entire occurrence table (public calendar, widgets, iCal, archives) without a nonce. Cookie-authenticated low-priv users can do the same using the wp_rest nonce localized on the public calendar shortcode. PATCH uses a non-existent edit_item_date_permissions_check method (fatal/deny, not an additional bypass).

  includes/rest-api/endpoints/class-calendar-plus-rest-endpoints-event.php:109-205

  Recommendation

  Deny by default: if the event post is missing, return 404/forbidden. Require current_user_can('manage_calendar_plus') (and edit_post on that event) before any mutation. Bind date_id to the route event id inside delete_item_date and reject mismatches. Implement the missing edit_item_date_permissions_check with the same deny-by-default logic.

• medium Unauthenticated REST disclosure of unpublished event occurrence rows

  information_disclosure

  GET /wp-json/calendar-plus/v1/events/{id}/dates uses get_items_permissions_check, which returns true for everyone unless context=edit. get_item_dates then returns calendar_plus()->generator->get_all_event_dates($id) with no current_user_can_read() / post_status check (unlike GET /events, which skips unreadable events). Guessable numeric IDs therefore leak from_date/until_date/from_time/until_time/series_number for draft, private, and password-protected calendar_event posts. Those date_id values are also the identifiers needed for the unauthenticated DELETE bypass on the sibling route.

  includes/rest-api/endpoints/class-calendar-plus-rest-endpoints-event.php:89-193

  Recommendation

  Load the event with calendarp_get_event() and return 404 unless current_user_can_read() (published/public) or the requester can edit that event. Do not return calendar rows for missing or non-event IDs.

• medium CSRF on AJAX calendar-cell time updates (missing nonce)

  csrf

  wp_ajax_calendarp_edit_calendar_cell is reachable by any logged-in user who holds manage_calendar_plus (Administrator and the plugin's calendarp_events_manager role). The handler never calls check_ajax_referer/wp_verify_nonce. A forged POST to admin-ajax.php with action=calendarp_edit_calendar_cell, cell_id, from_time, until_time (and optional edit_all) updates wp_calendarp_calendar times for one occurrence or every row for that event, then sets _has_custom_dates. The admin calendar UI (admin.js) posts exactly those fields with no nonce. The public React calendar then displays the attacker-chosen times. Subscriber cannot invoke this directly; exploitation is CSRF of a Calendar Plus manager.

  includes/ajax.php:3-84

  Recommendation

  Call check_ajax_referer() with a dedicated action before mutating rows, localize that nonce only on the admin calendar screen, and keep the manage_calendar_plus capability check.

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.