miracodeai/mira

Timeline

1. 23. Juli 2026Gescannt
2. 23. Juli 2026Gemeldet
3. 27. Juli 2026Vollständig code-gefixt
4. 27. Juli 2026Letztes Release mit Fix

Gefundene Lücken

• Path TraversalKritisch

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Eine öffentliche Fallback-Route in Mira lieferte angefragte Dateien direkt aus, ohne zu prüfen, ob der URL-Pfad das vorgesehene Verzeichnis verlässt. Unangemeldete Besucher konnten so jede für den Server lesbare Datei abrufen, darunter den privaten GitHub-App-Schlüssel, geheime Schlüssel aus der Konfigurationsdatei und die Datenbank mit Session-Tokens und Passwort-Hashes; der App-Schlüssel allein hätte vollen Zugriff auf alle angebundenen Repositories erlaubt. Die Lücke ist behoben.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Eine interne Regel ließ jede Anfrage auf eine Datei mit der Endung .svg ohne Login durch, obwohl dafür eigentlich nur ein einzelner öffentlicher Pfad gedacht war. Darüber ließ sich die Abhängigkeitsgrafik eines beliebigen, auch privaten Repositories unangemeldet abrufen und daraus die interne Datei- und Modulstruktur sowie verknüpfte Repos ablesen. Die Prüfung greift jetzt wie vorgesehen.

• Insecure Default CredsHoch

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Ohne explizit gesetztes Admin-Passwort legte Mira beim ersten Start automatisch ein Adminkonto mit dem Standardpasswort admin an, erreichbar über das öffentliche Login-Formular. Wer ein frisches, noch nicht konfiguriertes Deployment fand, bekam darüber volle Kontrolle über Nutzerverwaltung, Passwort-Resets und Repo-Konfiguration. Ein nutzbarer Standardzugang wird jetzt nicht mehr automatisch angelegt.

• Weak Password HashMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Passwörter wurden nur mit SHA-256 und einem einzigen, fest im Code hinterlegten Salt gehasht, ohne Streckung und ohne individuellen Salt pro Nutzer. Gelangte die Datenbank in fremde Hände, ließen sich damit auch stärkere Passwörter in kurzer Zeit durch Ausprobieren zurückrechnen, und identische Hashes verrieten identische Passwörter zwischen Konten. Mira nutzt inzwischen ein geeignetes Hashverfahren mit Salt pro Nutzer.

• Insecure CookieMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Das Session-Cookie von Mira wurde ohne das Secure-Attribut gesetzt, sodass der Browser es auch über eine unverschlüsselte HTTP-Verbindung mitschickt. Bei Deployments ohne durchgängiges HTTPS oder bei einem Protokoll-Downgrade konnte jemand im selben Netzwerk das Token mitlesen und die Session übernehmen. Das Cookie bekommt das Secure-Attribut jetzt gesetzt.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Der Endpunkt zum Löschen aller Repo-Daten einer Installation prüfte, anders als vergleichbare Admin-Funktionen, nicht, ob der anfragende Nutzer tatsächlich Admin-Rechte hatte. Jeder angemeldete Nutzer, auch ohne Adminrolle, konnte darüber gezielt die Repo-Registrierung einer beliebigen fremden Installation löschen. Die Berechtigungsprüfung ist jetzt nachgerüstet.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Die globale Einstellung, welches KI-Modell Mira für Indexierung und Reviews nutzt, ließ sich über einen Endpunkt ohne Admin-Prüfung ändern. Jeder angemeldete, nicht privilegierte Nutzer konnte damit das für alle Reviews verwendete Modell austauschen, mit entsprechenden Folgen für Kosten und Qualität der Analysen. Der Endpunkt verlangt jetzt Admin-Rechte.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Die Endpunkte zum Registrieren und Synchronisieren von GitLab- und Forgejo-Repositories verlangten keine Admin-Rechte, obwohl vergleichbare Funktionen sie voraussetzen. Ein einfacher angemeldeter Nutzer konnte so beliebige, für den Server erreichbare Repos in Mira aufnehmen und indexieren lassen, mit unnötigen Kosten und ungewollter Datenaufnahme als Folge. Der Zugriff ist jetzt auf Admins beschränkt.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Über die Endpunkte zum Starten, Erzwingen und Abbrechen der Repo-Indexierung ließ sich für beliebige Repositories ein vollständiges Neuindexieren auslösen oder ein laufender Job abbrechen, ohne dass eine Adminrolle geprüft wurde. Das betraf jeden angemeldeten Nutzer und konnte laufende Analysen anderer Repos unterbrechen und unnötige Rechen- und Modellkosten verursachen. Die Berechtigungsprüfung ist jetzt ergänzt.

• Broken Access ControlMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Der Endpunkt zum Abschluss des Setup-Vorgangs, der auch einen Massen-Indexierungslauf für alle konfigurierten Repos anstößt, prüfte nicht, ob der Aufrufer Admin-Rechte besitzt. Ein regulärer angemeldeter Nutzer konnte damit den Einrichtungsprozess einer fremden Instanz abschließen und ungefragt einen aufwendigen Indexierungslauf starten. Der Endpunkt verlangt jetzt eine Admin-Prüfung.

• SSRFNiedrig

  Gemeldet: 23. Juli 2026 · Gefixt: 27. Juli 2026

  Der SSRF-Schutz bei ausgehenden Webhooks blockierte nur IP-Adressen aus internen Bereichen, prüfte aber nicht, wohin ein per Domainname konfiguriertes Ziel tatsächlich auflöst. Wer Zugriff auf die Webhook-Konfiguration hatte, hätte darüber interne Systeme oder den Cloud-Metadaten-Dienst ansprechen und so etwa Zugangsdaten der Server-Umgebung auslesen können. Behoben mit Pull Request 212, veröffentlicht seit Version 0.8.0.

• Race ConditionMittel

  Gemeldet: 23. Juli 2026 · Gefixt: 24. Juli 2026 · Released: 27. Juli 2026 (v0.8.0)

  Liefen zwei Reviews derselben Pull Request gleichzeitig, zum Beispiel nach zwei schnell aufeinanderfolgenden Pushes, postete Mira mangels Sperre dieselben Befunde doppelt als Kommentar. Kein Sicherheitsproblem, aber ärgerlich für alle, die den Pull Request verfolgen. Parallele Reviews sind jetzt pro Pull Request gesperrt, allerdings nur innerhalb eines einzelnen Prozesses, sodass bei mehreren Worker-Prozessen weiterhin doppelte Kommentare auftreten können.

  Öffentliche Meldung ansehen