logtide-dev/logtide

Timeline

1. 25. Juni 2026Gescannt
2. 25. Juni 2026Gemeldet
3. 26. Juni 2026Vollständig code-gefixt
4. 26. Juni 2026Letztes Release mit Fix

Gefundene Lücken

• XSSHoch

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Über einen Projekt-API-Key ließ sich im Feld service.name HTML-Code einschleusen, der ungefiltert in der Service-Map-Ansicht landete. Er lief dann im Browser mit, sobald jemand mit der Maus über den betroffenen Dienst fuhr, und hatte Zugriff auf dessen Sitzung. Die Ausgabe wird jetzt sauber escaped, zusätzlich bereinigt LogTide den Wert schon bei der Aufnahme.

• Authz BypassHoch

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Bei Zugriff per API-Key fehlte die Prüfung, die Nutzer auf die Dashboard-Daten der eigenen Organisation beschränkt. Mit einem gültigen Schlüssel ließ sich stattdessen eine fremde Organisations-ID angeben und deren Kennzahlen und Ereignisse einsehen. Die Prüfung greift jetzt zentral über die im Schlüssel hinterlegte Organisation, auch an einem sechsten betroffenen Endpunkt, den das Team beim Nachprüfen zusätzlich fand.

• TOCTOU-Race-ConditionHoch

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Bei der Ersteinrichtung von LogTide prüft die Registrierung erst, ob schon ein Admin-Account existiert, und legt danach den neuen an, ohne diese beiden Schritte gegen gleichzeitige Anfragen abzusichern. Wer in diesem kurzen Fenster mehrere Registrierungen parallel schickte, konnte so theoretisch mehr als einen Admin-Account anlegen. Ein Datenbank-Lock sperrt den Ablauf jetzt so, dass nur der erste Versuch durchkommt.

• TOCTOU-Race-ConditionMittel

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Auch bei Limits für API-Keys, Dashboards, Alerts und ähnliche Objekte wurde erst gezählt und dann angelegt, ohne diesen Zwischenschritt gegen parallele Anfragen abzusichern. Wer mehrere Anfragen gleichzeitig schickte, konnte so ein gesetztes Limit überschreiten, was in der Standardinstallation ohne gesetzte Limits aber nicht griff. Zählen und Anlegen laufen jetzt über einen gemeinsamen Lock pro Organisation serialisiert.

• SSRFNiedrig

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Der SSRF-Schutz von LogTide prüft bei ausgehenden Anfragen wie Webhooks zunächst, ob das Ziel auf eine interne Adresse zeigt, verbindet sich dann aber in einem zweiten Schritt erneut, bei dem die Namensauflösung noch einmal ablief. Mit präparierten DNS-Antworten und passendem Timing ließ sich diese Prüfung umgehen, allerdings nur mit Kontrolle über den DNS-Server des Angreifers. Die Verbindung nutzt jetzt fest die bereits geprüfte IP-Adresse.

• Open RedirectNiedrig

  Gemeldet: 25. Juni 2026 · Gefixt: 26. Juni 2026

  Auf den Login- und Registrierungsseiten im Modus ohne Authentifizierung wurde ein Weiterleitungsparameter ungeprüft übernommen. Ein präparierter Link hätte Nutzer nach der Anmeldung unbemerkt auf eine fremde Seite umleiten können, klassisches Material für Open-Redirect-Phishing. Eine gemeinsame Prüffunktion lässt auf beiden Seiten jetzt nur noch Ziele innerhalb von LogTide zu.