PHP file upload bypass via Plugin installer

CVSS 7.61 Quelle

Beschreibung

### Impact Es ist möglich, dass eine Datei eines anderen Typs als eine Zip-Datei als neues Plugin von einem administrativen Benutzer auf den Plugins eingereicht wird -> Neu hinzufügen -> Plugin-Bildschirm in WordPress hochladen. Wenn FTP-Anmeldeinformationen zur Installation angefordert werden (um die Datei außerhalb des Verzeichnisses "Uploads" zu verschieben), bleibt die hochgeladene Datei vorübergehend in der Medienbibliothek verfügbar, obwohl sie nicht erlaubt ist. Wenn die Konstante "DISALLOW FILE EDIT" auf der Website auf "true" gesetzt ist und FTP-Anmeldeinformationen beim Hochladen eines neuen Themes oder Plugins erforderlich sind, dann erlaubt dies technisch einen RCE, wenn der Benutzer sonst keine Möglichkeit hätte, willkürlichen PHP-Code auszuführen. Dieses Problem betrifft nur Benutzer auf Administratorebene bei einzelnen Site-Installationen und Benutzer auf Super-Admin-Ebene bei Multisite-Installationen, bei denen ansonsten erwartet wird, dass der Benutzer keine Berechtigung zum Hochladen oder Ausführen von beliebigem PHP-Code hat. * Benutzer auf niedrigerer Ebene sind nicht betroffen * Sites, bei denen die Konstante `DISALLOW FILE MODS` auf `true` gesetzt ist, sind nicht betroffen * Sites, bei denen ein administrativer Benutzer entweder keine FTP-Anmeldeinformationen eingeben muss oder Zugriff auf die gültigen FTP-Anmeldeinformationen hat, sind nicht betroffen ### Patches Das Problem wurde am 30. Januar 2024 in WordPress 6.4.3 behoben und auf Zweige zurück zu 4.1 portiert. ### Workarounds Wenn die Konstante 'DISALLOW FILE MODS' als 'true' definiert ist, kann kein Benutzer ein Plugin hochladen und daher ist dieses Problem nicht ausnutzbar.

HerstellerWordPress.org

ProduktWordPress

ProduktfamilieWordPress

Betroffene Versionen>= 6.4.0 <6.4.3, >= 6.3.0 <6.3.3, >= 6.2.0 <6.2.4, >= 6.1.0 <6.1.5, >= 6.0.0 <6.0.7, >= 5.9.0 <5.9.9, >= 5.8.0 <5.8.9, >= 5.7.0 <5.7.11, >= 5.6.0 <5.6.13, >= 5.5.0 <5.5.14, >= 5.4.0 <5.4.15, >= 5.3.0 <5.3.17, >= 5.2.0 <5.2.20, >= 5.1.0 <5.1.18, >= 5.0.0 <5.0.21, >= 4.9.0 <4.9.25, >= 4.8.0 <4.8.24, >= 4.7.0 <4.7.28, >= 4.6.0 <4.6.28, >= 4.5.0 <4.5.31, >= 4.4.0 <4.4.32, >= 4.3.0 <4.3.33, >= 4.2.0 <4.2.37, < 4.1.40

Behobene Versionen6.4.3, 6.3.3, 6.2.4, 6.1.5, 6.0.7, 5.9.9, 5.8.9, 5.7.11, 5.6.13, 5.5.14, 5.4.15, 5.3.17, 5.2.20, 5.1.18, 5.0.21, 4.9.25, 4.8.24, 4.7.28, 4.6.28, 4.5.31, 4.4.32, 4.3.33, 4.2.37, 4.1.40

Nachvollziehbarkeit

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

WordPress Security Releases · Veröffentlichung öffnen ↗

KI-gestützt · ohne Gewährleistung

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 6.4.3, 6.3.3, 6.2.4, 6.1.5, 6.0.7, 5.9.9, 5.8.9, 5.7.11, 5.6.13, 5.5.14, 5.4.15, 5.3.17, 5.2.20, 5.1.18, 5.0.21, 4.9.25, 4.8.24, 4.7.28, 4.6.28, 4.5.31, 4.4.32, 4.3.33, 4.2.37, 4.1.40.

PrioritätGelb

EinordnungZeitnah behandeln: hohes technisches Risiko.

Empfohlene Schritte

Betroffene Systeme identifizieren: WordPress.org WordPress.
Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.

WordPress Security Releases NVD MITRE CVE CISA KEV Suche Web-Recherche