actionDeleteForSite propagates deletion to canonical element without independent authorization check
Beschreibung
`ElementsController::actionDeleteForSite()` lädt ein Element mit `checkForProvisionalDraft: true`, was den vorläufigen Entwurf des Benutzers zurückgibt, wenn einer existiert. Es ruft dann `canDeleteForSite()` im Entwurf auf - aber der Entwurfszweig von `Entry::canDeleteForSite()` überprüft nur `creatorId === current user`, was immer vergeht, da der Entwurf vom aktuellen Benutzer erstellt wurde. Die Methode gibt dann die Löschung an das kanonische Element über `deleteElementForSite($canonical)` ohne zweite Autorisierungsprüfung weiter. Ein Benutzer mit `viewEntries + viewPeerEntries + saveEntries + savePeerEntries + editSite` (aber kein `deleteEntriesForSite`) kann den Websiteeintrag eines kanonischen Eintrags löschen. Kontrast: `actionDelete()` macht es richtig (`src/controllers/ElementsController.php:1826+`): ``php // Löst sich auf kanonisch, BEVOR Sie canDelete ausführen, wenn ($element->isProvisionalDraft) { $element = $element->getCanonical(); } // ... dann canDelete-Check läuft auf dem kanonischen `` ## Impact | Scenario | Impact | |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Inhalt für diese Website verloren. | | Single-Site-Eintrag (PropagationMethod::Custom) | `deleteElementForSite()` eskaliert zum vollständigen Hard-Löschen - Element, Inhalt, Strukturknoten, Suchindex entfernt. | | Irreversibilität | Schwer zu löschen, nicht wiederherstellbar über Crafts Recycling-Binde. | Report ID: 1542
Quellen & weiterführende Informationen
Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.
Was ist zur Behebung zu tun?
Auf eine behobene Version aktualisieren: 5.10.11.
Empfohlene Schritte
- Betroffene Systeme identifizieren: Pixel & Tonic Craft CMS.
- 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.