
Eine gespeicherte Cross-Site-Scripting-Schwachstelle (XSS) in der Blog-Beitrag-Funktion von ERPNEXT v15.67.0 ermöglicht es Angreifern, beliebige Web-Skripte oder HTML über einen manipulierten Payload auszuführen, der in das Inhaltsfeld injiziert wird.
📌 Zusammenfassung
Eine gespeicherte Cross‑Site‑Scripting (XSS)‑Schwachstelle existiert im Blog‑Modul von ERPNext (v15.67.0) / Frappe (v15.72.4). Ein authentifizierter Benutzer, der Blog‑Beiträge erstellen oder bearbeiten kann, kann präpariertes HTML/JavaScript in das Feld content injizieren. Dieses Payload wird gespeichert und im Browser jedes Benutzers ausgeführt, der die Blog‑Beitragsseite aufruft, was beliebige Skriptausführung, Informationsoffenlegung, Denial of Service und andere clientseitige Angriffe ermöglicht. Administratorrechte sind nicht zwingend erforderlich – jeder Benutzer mit der Berechtigung, Blog‑Beiträge zu erstellen/bearbeiten, kann die Schwachstelle ausnutzen.
Schwachstellentyp: Gespeichertes Cross‑Site Scripting (CWE‑79)
Betroffene Produkte: ERPNext / Frappe
Betroffene Versionen (gemeldet):
Betroffene Komponente: ERPNext Blog‑Modul
Route: /app/blog-post/<blog_name>
Verwundbares Feld: content (Formular zum Erstellen/Bearbeiten von Blog‑Beiträgen)
Angriffsart: Remote (erfordert Authentifizierung und Berechtigungen zum Erstellen von Blog‑Beiträgen)
Schweregrad: Hoch (clientseitige Codeausführung, Datendiebstahl, mögliche Session‑Übernahme)
Geschätzter CVSS‑v3.1‑Score: 7.5 (Hoch) — Schätzung; die maßgebliche Zuweisungsstelle sollte die endgültige Bewertung berechnen
Status: Nicht behoben (Stand der Meldung)
Entdeckt von: Mohammed Aloli
Datum der Entdeckung: Nicht angegeben
CVE‑ID: CVE-2025-56379
Nur in autorisierten / Laborumgebungen testen. Führen Sie den Test NICHT gegen Systeme aus, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Genehmigung zum Testen haben.
Schritte zur Reproduktion
Melden Sie sich an der Ziel‑ERPNext‑Instanz als Benutzer mit der Berechtigung zum Erstellen/Bearbeiten von Blog‑Beiträgen an.
Navigieren Sie zur Route zum Erstellen/Bearbeiten eines Blog‑Beitrags, z. B.:
/app/blog-post/<blog_name>
Fügen Sie im Feld content das Payload ein und speichern Sie den Beitrag:
Öffnen Sie die Blog‑Beitragsseite (/app/blog-post/<blog_name>) als anderer Benutzer (oder als derselbe Benutzer in einem frischen Browser). Das Payload wird im Browser des Betrachters ausgeführt (hier: alert("xss")).
Hinweise: Das PoC verwendet einen einfachen onerror‑Alert. Echte Angriffe könnten Cookies exfiltrieren, Aktionen im Namen des Opfers ausführen oder entfernte Skripte laden (abhängig von CSP‑ und Cookie‑Flags).
Ein Angreifer, der Blog‑Beiträge erstellen oder bearbeiten kann, speichert ein bösartiges Skript im Feld content. Jeder Benutzer – einschließlich Administratoren –, der die Blog‑Beitragsseite besucht, führt das Skript des Angreifers in seinem Browser‑Kontext aus. Zu den Konsequenzen gehören Session‑Diebstahl (wenn Cookies nicht HttpOnly sind), erzwungene Aktionen in der Sitzung des Opfers, Datenextraktion aus Seiten, auf die der Angreifer zugreifen kann, UI‑Redress‑Angriffe und potenzieller DoS clientseitiger Komponenten.
content‑HTML bei der Eingabe und/oder escapen Sie es bei der Ausgabe mit einem sicheren HTML‑Sanitizer, der gefährliche Tags und Attribute entfernt (entfernen Sie on*‑Attribute, javascript:‑URIs, <script>, `` usw.). Bevorzugen Sie gut gepflegte Bibliotheken.<p>, <b>, <i>, <ul>, <li>, <a href> mit strenger href‑Validierung). Untersagen Sie Inline‑Event‑Handler.'unsafe-inline' vermeiden, bei Bedarf Nonce‑/Hash‑basierte Skriptfreigaben verwenden).https://github.com/frappe/erpnexthttps://github.com/frappe/frappehttps://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.htmlAutor: Mohammed Aloli
Dieser Bericht dient ausschließlich Verteidigungs‑, Abhilfe‑ und Sensibilisierungszwecken. Versuchen Sie nicht, diese Schwachstelle gegen Systeme auszunutzen, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Genehmigung zum Testen haben. Wenn Sie ERPNext/Frappe betreiben, wenden Sie Fixes an, setzen Sie die Bereinigung durch und befolgen Sie die oben genannten Empfehlungen.
HttpOnly sind, und setzen Sie geeignete SameSite‑Attribute, um Cookie‑Diebstahl und CSRF‑ähnliche Risiken zu reduzieren.