
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.
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.
<= 4.2.8.1The 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().
images), this could lead to Remote Code Execution (RCE).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:
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:
{"success":true,"data":{"attachment_id":117}}
4. Verification:
wp-content/uploads/<year>/<month>/poc.jpg.To resolve this vulnerability, developers must:
nopriv declaration if uploading is by design only for authenticated users.current_user_can('upload_files') to ensure only authorized privileged users can upload.check_ajax_referer() to prevent CSRF attacks.wp_handle_upload()) which perform stricter MIME-type and content checks.