Grundursache

Das Admin-Panel von emlog pro enthält einen AI Assistant, der im Auftrag des Admins SQL über POST /admin/ai.php?action=execute_tool ausführen kann. An diesem einen Endpunkt kommen mehrere Probleme zusammen:

1. Kein CSRF-Token. Jede andere destruktive Aktionsdatei in admin/ ruft zuerst LoginAuth::checkToken() auf (z. B. admin/media.php:140). admin/ai.php tut das nie.
2. Die Authentifizierung erfolgt ausschließlich über das Session-Cookie (admin/ai.php:152, User::isAdmin()) — keine Origin-/Referer-Prüfung.
3. Die Schreibbestätigung ist ein hartkodierter öffentlicher String. include/service/ai.php:594: if (trim($confirm_code) !== 'confirm'). Jede gefälschte Anfrage sendet einfach confirm_code=confirm.
4. Reines Lese-SQL benötigt überhaupt keine Bestätigung (include/service/ai.php:578,589) — eine bloße authentifizierte Anfrage kann jede Tabelle per SELECT auslesen.
5. Nur die Tabelle blog ist vor Schreibzugriffen geschützt (include/service/ai.php:591) — user und alle anderen Tabellen sind vollständig beschreibbar.
6. Die Passwort-Schwärzung ist per Alias umgehbar. Die Schwärzung gleicht nur den wörtlichen Ausgabespaltennamen password ab (include/service/ai.php:822-828) — SELECT password AS pwd_hash FROM user liefert den rohen Hash.
7. Das Auth-Cookie hat kein SameSite-Attribut (include/lib/loginauth.php:99), sodass nur das standardmäßige "Lax+POST"-Schonfrist-Fenster von Chrome (etwa die ersten zwei Minuten nach dem Login) zwischen dieser Schwachstelle und einer zuverlässigen Cross-Site-Zustellung steht.

Zusammengenommen: Eine einzige gefälschte Anfrage aus dem Browser eines Admins liest jede Tabelle (einschließlich Passwort-Hashes) und schreibt in jede Tabelle außer blog — inklusive direkter Überschreibung von user.password.

PoC

Teil 1 — Reine Angriffskette (poc_raw_impact.sh)

Isoliert die SQL-/Auth-Bypass-Primitive von der Frage der CSRF-Zustellung. Gegen eine lokale Instanz ausführen, die du kontrollierst:

Das Skript meldet sich als Admin an, extrahiert Passwort-Hashes über die Spaltenalias-Umgehung, überschreibt das Admin-Passwort direkt über die Tabelle user und meldet sich dann mit einem frischen Cookie-Jar erneut mit dem vom Angreifer gewählten Passwort an — was eine vollständige Kontenübernahme beweist, sobald eine authentifizierte Anfrage den Endpunkt erreicht.

Teil 2 — Echte Cross-Site-CSRF-Zustellung (poc_csrf.html)

Beantwortet die SameSite-Frage mit einem echten Browser, anstatt sie vorauszusetzen. poc_csrf.html von einer beliebigen Origin ausliefern, die sich vom Ziel unterscheidet (eine andere IP genügt — Chrome behandelt unterschiedliche konkrete IP-Adressen als getrennte Sites), und einen eingeloggten Admin dazu bringen, sie innerhalb von etwa zwei Minuten nach dem Anmelden zu öffnen:

Das Formular sendet sich beim Laden automatisch ab und übermittelt cross-site einen gefälschten query_database-Aufruf mit confirm_code=confirm.

Live verifiziert: Der gefälschte Cross-Site-POST trug das echte Auth-Cookie des Admins (sec-fetch-site: cross-site, Cookie angehängt), gab 200 {"code":0,"msg":"ok",...} zurück, und die injizierte Zeile wurde per anschließendem authentifizierten Lesezugriff bestätigt. Die Wiederholung derselben Anfrage etwa 48 Minuten später gegen denselben, nun gealterten Cookie-Jar schlug fehl — kein Cookie wurde angehängt und der Server gab eine nicht authentifizierte Weiterleitung zurück, was bestätigt, dass das etwa zweiminütige Lax+POST-Fenster die tatsächliche Einschränkung ist (reflektiert in AC:H).

Auswirkungen

• Voller Datenbank-Lesezugriff: jede Tabelle/Spalte, einschließlich Passwort-Hashes und aller Geheimnisse in emlog_options (SMTP-Zugangsdaten, API-Schlüssel usw.).
• Voller Datenbank-Schreibzugriff auf jede Tabelle außer blog, einschließlich user — Überschreibung von Rolle/Passwort/E-Mail, Ende-zu-Ende als Kontenübernahme demonstriert.
• Beschränkt auf Konten mit role=admin; writer/editor werden durch User::checkRolePermission() blockiert. Keine Privilegienerweiterung von einer niedrigeren Rolle — ein einziger Klick auf einen bösartigen Link durch einen eingeloggten Admin führt zu einer vollständigen, stillen Kompromittierung der Website.

Behebung

LoginAuth::checkToken() zu execute_tool hinzufügen, SameSite=Strict auf dem Auth-Cookie setzen und den statischen confirm_code-String durch ein echtes, pro Sitzung einmalig verwendbares Token ersetzen. Vollständige Details zur Behebung im Advisory.

Zeitleiste der Offenlegung

• 2026-07-31 — Gemeldet über GitHub Security Advisories gemäß emlogs eigener SECURITY.md.
• 2026-08-01 — Der Maintainer veröffentlichte das Advisory und forderte eine CVE an.
• 2026-08-16 — CVE-2026-73847 von GitHub (CNA) zugewiesen.

Anmerkung zur Danksagung: GitHub als CNA veröffentlichte den CVE-Eintrag ohne einen credits-Eintrag, obwohl die GHSA selbst den Melder würdigt und akzeptiert. Ein Korrekturantrag wurde am 2026-08-16 an [email protected] gesendet; dieses README wird aktualisiert, falls der Eintrag korrigiert wird.

Haftungsausschluss

Veröffentlicht, nachdem das Advisory öffentlich war und eine CVE zugewiesen wurde, zu defensiven und lehrreichen Zwecken. Führe dies nicht gegen eine emlog-Instanz aus, die dir nicht gehört oder für die du nicht ausdrücklich zum Testen autorisiert bist.