📄 WordPress EventPrime 4.2.8.1 Arbitrary File Upload

# CVE-2026-1657: Unauthenticated Arbitrary File Upload in EventPrime Plugin
    
    > **Disclaimer:** This repository is created for **educational purposes and ethical disclosure only**. The vulnerability has been responsibly reported to the vendor and patched. Do not use this information to exploit systems without proper authorization.
    
    ## Summary
    A **Unauthenticated Arbitrary File Upload** vulnerability was discovered in the **EventPrime** plugin for WordPress (versions <= 4.2.8.1). This flaw allows any unauthenticated visitor to upload files directly into the WordPress `uploads` directory and create attachment records in the Media Library.
    
    The vulnerability exists because a specific AJAX endpoint is explicitly registered with nopriv (publicly accessible) and lacks both authorization checks and proper file content validation. Attackers can abuse this endpoint to cause storage exhaustion, spam the media library, or potentially upload malicious payloads disguised as images.
    
    ## Vulnerability Overview
    * **CVE ID:** CVE-2026-1657
    * **Product:** EventPrime (WordPress Plugin)
    * **Affected Versions:** `<= 4.2.8.1`
    * **Vulnerability Type:** Unrestricted Upload of File with Dangerous Type (CWE-434)
    * **Required Privileges:** None (Unauthenticated)
    
    ## Technical Deep Dive & Root Cause
    The root cause is a combination of insecure AJAX hook registration and insufficient file validation.
    
    **1. Insecure AJAX Endpoint Registration:**
    In `includes/class-eventprime-event-calendar-management.php`, the plugin registers the `upload_file_media` action. Around line 557, it sets {`upload_file_media`: true} in its action map, where `true` indicates `_nopriv` support. Consequently, the gwp_ajax_nopriv_ep_upload_file_media` hook is registers, making the endpoint available to anyone.
    
    **2. Missing Authorization And Nonce Checks:**
    The handler function `upload_file_media()` (in `includes/class-ep-ajax.php`, lines 1659-1697) does not use `current_user_can()` to check for upload privileges, nor does it verify a security nonce.
    
    **3. Flawed Validation Logic:**
    The handler only validates the file extension (e.g., `jpg/jpeg/png/gif`) based on the client-provided filename (lines 1661-1664). It does not perform robust server-side content validation (like `getimagesize()` or `wp_check_filetype_and_ext()`). This implies that malicious scripts or other filetypes renamed to `harmless.jpg` will be written to the disk before WordPress attempts metadata generation.
    
    **4. Persistence:**
    The file is saved using `move_uploaded_file()` directly into `wp_upload_dir()['path']` and a WordPress attachment is created via `wp_insert_attachment()`.
    
    ## Business Impact
    * **Storage Exhaustion (DoS):** An attacker can automate uploads containing large files, consuming all available server disk space or cloud storage quota, potentially bringing down the website.
    * **Media Library Spam:** The attacker can flood the media library with inappropriate or useless images, making it unusable for administrators.
    * **Potential for Further Exploitation:** Combined with other vulnerabilities (such as a Local File Inclusion - LFI, or if the server is misconfigured to execute `images`), this could lead to Remote Code Execution (RCE).
    
    ## Proof of Concept (PoC)
    
    ### Steps to Reproduce
    
    **1. Prepare the Payload:** Create a sample image file on your local machine named `poc.jpg`.
    
    **2. Execute the Request:** Send a multipart/form-data POST request to the public AJAX endpoint without any session cookies:
    
    ```bash
    curl -i \
      -F "[email protected];filename=poc.jpg" \
      "http://TARGET_SITE/wp-admin/admin-ajax.php?action=ep_upload_file_media"
    ```
    
    **3. Observe the Response:** The server will respond with a 200 OK and return a JSON object containing the newly created attachment ID:
    
    ```json
    {"success":true,"data":{"attachment_id":117}}
    ```
    
    **4. Verification:**
    * The file is now stored at `wp-content/uploads/<year>/<month>/poc.jpg`.
    * An administrator visiting the WordPress Media Library will see the uploaded file.
    
    ## Remediation
    To resolve this vulnerability, developers must:
    1. **Restrict Endpoint Access:** Remove the `nopriv` declaration if uploading is by design only for authenticated users.
    2. **Implement Capability Checks:** Use `current_user_can('upload_files')` to ensure only authorized privileged users can upload.
    3. **Validate Nonces:** Implement `check_ajax_referer()` to prevent CSRF attacks.
    4. **Strict File Validation:** Use traditional WordPress image handling functions (like `wp_handle_upload()`) which perform stricter MIME-type and content checks.
    
    ## Timeline
    
    * **Date (2026-01-29):** Reported to Wordfence.
    * **Date (2026-02-17):** Vulnerability patched / Public disclosure.
    
    ## References & Credits
    
    * [Wordfence Vulnerability Database](https://www.wordfence.com/threat-intel/vulnerabilities/id/42aa82ff-0d37-4040-b8fc-84d29534a4b7)
    * [CVE-2026-1657 on NVD](https://www.cve.org/CVERecord?id=CVE-2026-1657)
    * [EventPrime Plugin on WordPress.org](https://wordpress.org/plugins/eventprime-event-calendar-management/)