Vulnerability Research Plan: CVE-2026-7525

1. Vulnerability Summary

The My Calendar plugin for WordPress is vulnerable to a missing authorization check in versions up to and including 3.7.9. While the administrative UI restricts low-privilege users (those with "Custom" access like mc_add_events) to only submitting drafts for review, the backend fails to validate if the user has the authority to set the event_approved status. By intercepting and modifying the POST request during event creation or editing, an authenticated attacker can bypass the moderation workflow to directly publish events (event_approved=1) or set other unauthorized statuses.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin.php?page=my-calendar (Administrative event management page)
• Vulnerable Parameter: event_approved
• Required Authentication: Authenticated user with at least mc_add_events capability (Custom level).
• Payload Type: Form-data (POST body)
• Preconditions: The user must be logged in and have permission to access the "Add Event" or "Edit Event" page.

3. Code Flow

1. Entry Point: A user accesses the "Add Event" page (admin.php?page=my-calendar&mode=add).
2. Submission: The user submits the event form. The browser sends a POST request to the same URL or the management handler.
3. Processing (Inferred): The plugin processes the submission (likely in a function handling mode=add or mode=edit).
4. Missing Check: The code extracts $_POST['event_approved']. While the UI only provides a button that sends event_approved=0 (Draft) for low-privilege users, the backend code fails to call current_user_can( 'mc_approve_events' ) before assigning the event_approved value to the event object being saved to the database.
5. Sink: The my_calendar_event_table is updated with the user-supplied event_approved value.

4. Nonce Acquisition Strategy

My Calendar uses standard WordPress nonces for its admin forms. To obtain a valid nonce for the "Add Event" action:

1. Login: Use the security agent to log in as a user with the mc_add_events capability.
2. Navigate: Navigate to the "Add Event" page: /wp-admin/admin.php?page=my-calendar&mode=add.
3. Extract: Use browser_eval to extract the nonce and standard form values.
   • The nonce is typically in a hidden input named _wpnonce.
   • Command: browser_eval("document.querySelector('input[name=\"_wpnonce\"]').value")

5. Exploitation Strategy

The goal is to create a published event as a user who should only be allowed to create drafts.

1. Setup User: Create a user with the Subscriber role and grant them the mc_add_events capability using WP-CLI.
2. Capture Form Data:
   • Navigate to /wp-admin/admin.php?page=my-calendar&mode=add.
   • Extract the _wpnonce.
   • Identify other required fields: event_title, event_begin, event_time, event_end, event_endtime.
3. Craft Malicious POST:
   • Submit a POST request to /wp-admin/admin.php?page=my-calendar.
   • Include mode=add.
   • Include event_title=Malicious Published Event.
   • Set event_approved=1 (The bypass).
   • Include required dates/times (e.g., event_begin=2025-10-10, event_time=12:00:00).
4. Execute Request: Use the http_request tool to send the authenticated POST request.

Example Payload (POST Body):

_wpnonce=[NONCE]&mode=add&event_title=Bypassed+Event&event_desc=This+event+should+be+a+draft&event_begin=2025-01-01&event_time=12%3A00%3A00&event_end=2025-01-01&event_endtime=13%3A00%3A00&event_approved=1&save=Add+Event

6. Test Data Setup

1. Plugin Activation: Ensure "My Calendar" is active.
2. Create Attacker User:

   wp user create attacker attacker@example.com --role=subscriber --user_pass=password
   

3. Grant Permissions: Grant the specific My Calendar capability. My Calendar maps its internal capabilities to WordPress roles/caps.

   # Granting the capability required to add events
   wp user add-cap attacker mc_add_events
   

4. Confirm Permissions: Ensure the user can reach the "Add Event" page but cannot "Approve" (published status).

7. Expected Results

• The server should respond with a 302 Redirect (standard WordPress admin behavior) or a success message indicating the event was added.
• The event should be visible on the public calendar immediately without administrative approval.
• Checking the database will show event_approved = 1.

8. Verification Steps

1. Check Database:

   wp db query "SELECT event_title, event_approved FROM $(wp db prefix)my_calendar WHERE event_title = 'Bypassed Event'"
   

   • Success Criteria: event_approved is 1.
2. Check Visibility:
   • Use mc_event_published logic (from includes/conditionals.php) or simply check the front-end calendar page if it exists.
   • Navigate to the homepage/calendar page and verify the "Bypassed Event" title appears.

9. Alternative Approaches

• Edit Existing Draft: If "Add Event" is hardened, attempt to edit an existing draft event (mode=edit&event_id=X) and change event_approved from 0 to 1.
• Unauthorized Statuses: Instead of 1 (Published), attempt to set event_approved to 2 (Draft/Pending), 3 (Cancelled), or 4 (Hidden/Private) to disrupt site operations.
• AJAX Endpoint: Check if admin-ajax.php handlers exist for event saving that might also be missing authorization checks for the event_approved field. (Check includes/class-mc-ajax.php if present in full source).