d3kc4rt1/cve-2026-1657Nicht authentifiziertes Hochladen beliebiger Dateien im EventPrime Plugin
Haftungsausschluss: Dieses Repository dient ausschließlich Bildungszwecken und der ethischen Offenlegung. Die Schwachstelle wurde verantwortungsvoll an den Hersteller gemeldet und behoben. Verwenden Sie diese Informationen nicht, um Systeme ohne entsprechende Autorisierung auszunutzen.
Im EventPrime-Plugin für WordPress (Versionen <= 4.2.8.1) wurde eine nicht authentifizierte Schwachstelle für beliebigen Datei-Upload entdeckt. Dieser Fehler ermöglicht es jedem nicht authentifizierten Besucher, Dateien direkt in das WordPress-Verzeichnis uploads hochzuladen und Anhangsdatensätze in der Mediathek zu erstellen.
Die Schwachstelle existiert, weil ein bestimmter AJAX-Endpunkt explizit mit nopriv (öffentlich zugänglich) registriert ist und sowohl Autorisierungsprüfungen als auch eine ordnungsgemäße Dateiinhaltsvalidierung fehlen. Angreifer können diesen Endpunkt missbrauchen, um Speicherplatz zu erschöpfen, die Mediathek mit Spam zu überfluten oder potenziell schädliche Nutzlasten hochzuladen, die als Bilder getarnt sind.
<= 4.2.8.1Die Grundursache ist eine Kombination aus unsicherer AJAX-Hook-Registrierung und unzureichender Dateivalidierung.
1. Unsichere AJAX-Endpunkt-Registrierung:
In includes/class-eventprime-event-calendar-management.php registriert das Plugin die Aktion upload_file_media. Etwa in Zeile 557 setzt es {upload_file_media: true} in seine Aktionszuordnung, wobei true die _nopriv-Unterstützung angibt. Folglich wird der Hook gwp_ajax_nopriv_ep_upload_file_media registriert, wodurch der Endpunkt für jedermann verfügbar ist.
2. Fehlende Autorisierungs- und Nonce-Prüfungen:
Die Handler-Funktion upload_file_media() (in includes/class-ep-ajax.php, Zeilen 1659-1697) verwendet weder current_user_can(), um Upload-Berechtigungen zu prüfen, noch verifiziert sie eine Sicherheits-Nonce.
3. Fehlerhafte Validierungslogik:
Der Handler validiert nur die Dateierweiterung (z. B. jpg/jpeg/png/gif) basierend auf dem vom Client bereitgestellten Dateinamen (Zeilen 1661-1664). Er führt keine robuste serverseitige Inhaltsvalidierung durch (wie getimagesize() oder wp_check_filetype_and_ext()). Das bedeutet, dass bösartige Skripte oder andere Dateitypen, die in harmless.jpg umbenannt wurden, auf die Festplatte geschrieben werden, bevor WordPress versucht, Metadaten zu generieren.
4. Persistenz:
Die Datei wird mit move_uploaded_file() direkt in wp_upload_dir()['path'] gespeichert und über wp_insert_attachment() wird ein WordPress-Anhang erstellt.
images ausführt) könnte dies zu Remote Code Execution (RCE) führen.1. Nutzlast vorbereiten: Erstellen Sie eine Beispielbilddatei mit dem Namen poc.jpg auf Ihrem lokalen Rechner.
2. Anfrage ausführen: Senden Sie eine multipart/form-data-POST-Anfrage an den öffentlichen AJAX-Endpunkt ohne Sitzungs-Cookies:
curl -i \
-F "[email protected];filename=poc.jpg" \
"http://TARGET_SITE/wp-admin/admin-ajax.php?action=ep_upload_file_media"
3. Antwort beobachten: Der Server antwortet mit 200 OK und gibt ein JSON-Objekt mit der neu erstellten Anhangs-ID zurück:
{"success":true,"data":{"attachment_id":117}}
4. Verifizierung:
wp-content/uploads/<year>/<month>/poc.jpg gespeichert.Um diese Schwachstelle zu beheben, müssen Entwickler:
nopriv-Deklaration, wenn das Hochladen nur für authentifizierte Benutzer vorgesehen ist.current_user_can('upload_files'), um sicherzustellen, dass nur autorisierte privilegierte Benutzer hochladen können.check_ajax_referer(), um CSRF-Angriffe zu verhindern.wp_handle_upload()), die strengere MIME-Typ- und Inhaltsprüfungen durchführen.