Ghost: Die Autorenrolle loescht fremde Beitraege und Seiten

Die Rechtepruefung kennt einen Eigentumszweig fuer Mitwirkende, aber keinen fuer Autoren beim Loeschen, weshalb dort nie geprueft wird.

Advisory-ID: TP-2026-107
Produkt: Ghost (Publishing-Plattform fuer Blogs und Newsletter, Node.js)
Schwachstellentyp: Fehlende Autorisierung (CWE-862)
CVE: CVE-2026-105680
CVSS 3.1: 6.5 (Mittel) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Betroffene Versionen: >= 5.81.0, < 6.60.0
Hersteller-Advisory: GHSA-x3mg-q38v-m562
Behoben in: 6.60.0
Gemeldet: 03. Juni 2026

Zusammenfassung

Die Autorenrolle in Ghost darf eigene Entwuerfe anlegen und verwalten, fremde Inhalte jedoch nicht anfassen. Beim Loeschen greift diese Begrenzung nicht: ein Konto mit dieser Rolle entfernt Beitraege und Seiten beliebiger anderer Nutzer, auch veroeffentlichte und auch die des Eigentuemers der Website. Die Rechtepruefung besitzt einen eigenen Zweig, der bei der Rolle Mitwirkender das Eigentum prueft, und einen weiteren fuer das Bearbeiten durch Autoren, aber keinen fuer das Loeschen durch Autoren. Der Aufruf faellt deshalb in einen Sammelzweig, in dem die bereits erteilte Berechtigung mit einer Oder-Verknuepfung weitergereicht wird, sodass die Eigentumsfrage nie gestellt wird. Ueber die Sammelloeschung mit Filter entfernt dasselbe Konto in einer einzigen Anfrage jeden passenden Beitrag der gesamten Website.

Ursache

Die Funktion permissible in core/server/models/relations/authors.js:373-385 fuehrt Eigentumszweige fuer das Loeschen durch Mitwirkende und das Bearbeiten durch Autoren, besitzt aber keinen Zweig fuer die Kombination aus Autorenrolle und Loeschen. Ein solcher Aufruf landet daher im Sammelzweig hasUserPermission = hasUserPermission || isPrimaryAuthor(), in dem der erste Operand bereits wahr ist, weil die Autorenrolle das globale Recht zum Loeschen von Beitraegen traegt, womit die Oder-Verknuepfung unabhaengig vom Eigentum wahr bleibt. Die nachgelagerte Pruefung in post.js:1436 laesst den Vorgang ebenfalls durch, da bei einer Loeschung keine Sichtbarkeit geaendert wird. Die Sammelloeschung uebergibt ueberhaupt keine Objektkennung, weshalb permissible mit einem undefinierten Modell aufgerufen wird und der Dienst in services/posts/posts-service.js:250 allein nach dem vom Aufrufer gelieferten Filter loescht, ohne nach Urheberschaft einzugrenzen. Dass die Luecke so lange blieb, zeigt der Testbestand: fuer das Loeschen durch Mitwirkende existiert ein Test, fuer das Loeschen durch Autoren keiner.

Proof of Concept

# Voraussetzung: ein Konto mit der Rolle Autor, wie es jede gewoehnliche
# Mitarbeitereinladung erzeugt. Der Eigentuemer hat einen Beitrag angelegt.

# Einzeln:
DELETE /ghost/api/admin/posts/<id-des-fremden-beitrags>/      -> 204

# Als Kontrolle dieselbe Anfrage als Mitwirkender:
DELETE /ghost/api/admin/posts/<id-des-fremden-beitrags>/      -> 403

# Per Filter, in einer einzigen Anfrage:
DELETE /ghost/api/admin/posts/?filter=status:draft

Der Unterschied zwischen 204 und 403 zeigt die Luecke unmittelbar: fuer die Rolle Mitwirkender greift der Eigentumszweig, fuer die Autorenrolle fehlt er. In unserer Reproduktion loeschte ein Autorenkonto einen Entwurf, einen veroeffentlichten Beitrag und eine Seite des Eigentuemers.

Auswirkung

  • Dauerhaftes Loeschen von Beitraegen und Seiten aller anderen Rollen durch ein Konto mit der niedrigsten inhaltlichen Schreibrolle.
  • Vollstaendige oder gezielte Loeschung der Inhalte einer Website ueber die Sammelloeschung mit Filter, in einer einzigen Anfrage.
  • Kein Schutz durch den Veroeffentlichungsstatus, da Entwuerfe und veroeffentlichte Inhalte gleichermassen betroffen sind.
  • Keine Vertraulichkeitsverletzung, die Wirkung liegt allein auf Integritaet und Verfuegbarkeit der Inhalte.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen