Uptime Kuma: Lücke erlaubt Admins Codeausführung unter Bedingungen, latest ohne Fix

Das Projekt Uptime Kuma hat am 2. November 2026 die Details einer Lücke veröffentlicht, über die ein angemeldeter Admin bei Schreibzugriff auf Dateien Code auf dem Monitoring-Server ausführen kann. Der Fix steckt seit dem 26. Oktober in Version 2.5.8. Am 31. Oktober folgten Version 2.5.9 und eine zweite Meldung zu manipulierbaren RSS-Feeds öffentlicher Statusseiten.

Betroffen sind Instanzen ab 1.0.6 unter 2.5.9, außerhalb von Docker greift die Apprise-Lücke nur bei installiertem Apprise. Besonders achten sollten Admins auf Container mit den Tags latest oder 1, denn diese erhalten den Apprise-Fix nicht. Ein Update gehört ins nächste Wartungsfenster, bei aus dem Internet erreichbarer Anmeldeseite sollte es sofort erfolgen.

Was ist passiert?

Die schwerere Lücke (GHSA-v2p3-6f5h-6hhf) sitzt in der Apprise-Anbindung von Uptime Kuma, nicht in Apprise selbst. Das Programm übergab die eingetragene Apprise-URL laut Advisory ohne den Trenner -- an das Kommandozeilenprogramm. Beginnt der Wert mit einem Bindestrich, liest Apprise ihn als Option. Die Apprise-Dokumentation beschreibt --plugin-path als Pfad, der nach eigenen Python-Plugins durchsucht wird, und --config als Option, die Konfigurationen auch von einem entfernten Server lädt.

Die zweite Lücke (GHSA-86ch-2247-gr56) betrifft den Feed unter /status/<slug>/rss. Laut Advisory baute Uptime Kuma den Link im Feed aus dem Host-Header der Anfrage und speicherte die Antwort fünf Minuten im Cache, ohne den Host im Cache-Schlüssel zu berücksichtigen. Eine präparierte Anfrage bei abgelaufenem Cache reichte, damit alle Abrufer in dieser Zeit einen Link auf eine fremde Domain erhielten. Das geht ohne Anmeldung und lässt sich wiederholen.

Wer ist betroffen?

Die Apprise-Lücke betrifft laut Advisory die Versionen ab 1.0.6 bis einschließlich 2.5.7. Die RSS-Lücke betrifft 2.1.0 bis 2.5.8 und setzt eine öffentliche Statusseite voraus. In Docker-Images ist Apprise fest enthalten, auch in den Slim-Varianten.

Einen Fix für die Reihe 1.x nennt das Advisory nicht, und der Quelltext von 1.23.17 enthält den Trenner nicht. Die Sicherheitsrichtlinie des Projekts führt die Docker-Tags 1, 1-debian, latest und debian als veraltet. Laut Docker Hub stammen latest und 1 vom 16. September 2026, 2 und 2.5.9 vom 31. Oktober. Die RSS-Lücke betrifft die alte Reihe nicht.

Wie kritisch ist das?

Die Apprise-Lücke ist im Normalfall keine Lücke für anonyme Angreifer. Die Release Notes kennzeichnen sie als „Admin Only“, der GitHub-Eintrag nennt CVSS 4.0 mit 8.7 und hohe erforderliche Rechte. Der Weg führt also über ein übernommenes oder schwaches Konto. Der Quelltext zeigt eine Ausnahme, die das Advisory nicht nennt: Ist die Anmeldung in den Einstellungen deaktiviert, entfällt diese Hürde. Für Codeausführung braucht der Angreifer zusätzlich eine Möglichkeit, eine Python-Datei auf dem Server abzulegen. Dann läuft der Code mit den Rechten des Uptime-Kuma-Prozesses, und laut Advisory sind Datenbank und Umgebungsvariablen lesbar. Ein Ausbruch aus dem Container ist demnach möglich, wenn der Docker-Socket eingebunden ist. Ohne Schreibzugriff bleibt Server-Side Request Forgery: Der Server ruft fremde URLs ab.

Das Advisory enthält einen Proof of Concept. Hinweise auf Angriffe nennen die Meldungen nicht. Die RSS-Lücke bewertet GitHub mit CVSS 3.1 und 4.3. Diese Lücke eignet sich für Phishing, erlaubt aber laut Advisory weder XSS noch Codeausführung oder Datenabfluss. Beide Meldungen haben bisher keine CVE-Nummer.

Was sollten Admins jetzt tun?

• Inventar: alle Instanzen erfassen, Version in der Oberfläche ablesen und Image-Tag prüfen. Ein Image ohne Tag bedeutet latest.
• Update: auf 2.5.9 aktualisieren oder den Tag 2 nutzen, passend dazu 2-slim oder 2-rootless.
• Altbestand: Instanzen auf latest oder 1 nach der Migrationsanleitung des Projekts auf die Reihe 2 heben, vorher sichern.
• Anmeldung: Passwort prüfen und stärken, Zwei-Faktor-Anmeldung aktivieren, die Oberfläche möglichst nicht frei ins Internet stellen. Deaktivierte Anmeldung nur hinter einem vorgeschalteten Schutz betreiben.
• Prüfung: Apprise-Benachrichtigungen einzeln öffnen und auf eine URL achten, die mit einem Bindestrich beginnt. Ein unauffälliger Befund schließt eine Ausnutzung nicht aus, denn über die Testfunktion bleibt kein Eintrag zurück.
• Härtung: den Docker-Socket nur einbinden, wenn die Docker-Überwachung ihn wirklich braucht.

Einordnung für Unternehmen

Da Uptime Kuma nur ein Konto kennt, bleibt die Apprise-Lücke eine zweite Stufe nach einem gestohlenen Login. Heikel wird sie dort, wo mehrere Personen dieses Konto teilen oder Uptime Kuma Zugangsdaten zu überwachten Systemen speichert. Die größere Baustelle dürfte der alte Tag sein: Wer latest nutzt, bekommt die Reihe 2 nicht. Fachberichte lagen bei Redaktionsschluss nicht vor.

Passende Anleitungen auf S-EDV

• Uptime Kuma installieren: Monitoring mit Docker & Nginx Proxy Manager
• Nginx als Reverse Proxy mit TLS manuell einrichten

Quellen

• Uptime Kuma: Advisory zur Apprise-Lücke (GHSA-v2p3-6f5h-6hhf)
• Uptime Kuma: Advisory zum RSS-Feed (GHSA-86ch-2247-gr56)
• Uptime Kuma: Release Notes zu 2.5.8
• Uptime Kuma: Release Notes zu 2.5.9
• Uptime Kuma: Sicherheitsrichtlinie und unterstützte Docker-Tags
• Docker Hub: Tags von Uptime Kuma
• Apprise: Dokumentation der Kommandozeile