Hostzero Logo
Zurück zu den Artikeln

Ist Coolify sicher? Was die CVEs aus 2026 bedeuten — und wie Sie Ihre Instanz absichern

11 kritische Coolify-CVEs, fünf mit CVSS 10.0, 52.890 offene Instanzen — 15.000 davon in Deutschland. Was passiert ist, wer wirklich gefährdet ist und die Absicherungs-Checkliste.

Pascal Ehlert
Juli 2026
Balkendiagramm: 52.890 öffentlich erreichbare Coolify-Instanzen im Januar 2026, Deutschland führt mit 15.000 (Censys)

Am 8. Januar 2026 hat Coolify elf kritische Sicherheitslücken an einem einzigen Tag offengelegt. Fünf davon tragen den Höchstwert CVSS 10.0 — Command Injection, die mit Root-Zugriff auf dem Host endet. Zum Zeitpunkt der Veröffentlichung zählte Censys 52.890 Coolify-Dashboards, die öffentlich aus dem Internet erreichbar waren. Nirgendwo stehen mehr davon als in Deutschland: rund 15.000.

Ist Coolify also sicher? Die kurze Antwort: ja — wenn Sie es wie kritische Infrastruktur betreiben. Für die längere Antwort gibt es diesen Artikel.

Was passiert ist

Coolify ist eine Open-Source-PaaS zum Selbsthosten — eine Alternative zu Heroku, Vercel oder Netlify, die Anwendungen deployt und Server orchestriert. Diese Aufgabe ist der Schlüssel zu allem Weiteren: Coolify muss, um sie zu erfüllen, privilegierte Operationen auf Ihren Hosts ausführen, in der Regel als Root.

Der Disclosure im Januar umfasste elf CVEs. Nach Klassen gruppiert:

Klasse

CVEs

CVSS

Behoben in

Command Injection (DB-Backup/-Import, PostgreSQL-Init, Proxy-Konfiguration, Storage-Mounts) — RCE als Root

CVE-2025-66209 … 66213

10.0 (alle fünf)

4.0.0-beta.451

Private-Key-Leak — Nutzer mit geringen Rechten kann den Root-SSH-Key lesen und sich als Root anmelden

CVE-2025-64420

10.0

gepatcht (betroffen: ≤ beta.434)

Injection über docker-compose.yaml und Git-Eingabefelder — Root-RCE

CVE-2025-64419, -64424, -59156, -59157

9.4–10.0

beta.445 / beta.420.7

Stored XSS über den Projektnamen — wird im Browser des Admins ausgeführt

CVE-2025-59158

9.4

beta.420.7

Aktive Angriffe wurden zum Zeitpunkt der Offenlegung nicht beobachtet — und sind bis heute (Stand: Juli 2026) nicht bekannt. Bei rund 52.000 offenen Instanzen ist das aber kein Grund zur Entwarnung.

Der Januar war nicht das Ende. Bis ins Frühjahr 2026 folgten weitere kritische Lücken — eine Sentinel-Token-Injection mit Host-RCE (CVE-2026-34034), Command Injection beim Deployment (CVE-2026-34038), ein Berechtigungs-Bypass auf fremde Team-Server (CVE-2026-34592). Inzwischen hat Coolify die Beta-Phase verlassen: Nach Jahren mit 4.0.0-beta.4xx-Builds erschien am 27. April 2026 das erste stabile Release v4.0.0 — und auch das aktuelle v4.1.2 (Juni 2026) bringt noch eine seitenlange Liste an Sicherheitsfixes mit. Coolify zu patchen ist ein Laufband, kein einmaliges Ereignis.

Zeitleiste der Coolify-CVE-Wellen 2025–2026: 11 kritische CVEs am 8. Januar 2026, behoben in 4.0.0-beta.451; weitere RCEs bis Frühjahr 2026; erstes stabiles Release v4.0.0 im April 2026, aktuell v4.1.2.

Warum das immer wieder passiert — und warum es nicht „Coolify ist schlecht“ heißt

Coolifys gesamter Job besteht darin, Nutzereingaben — eine Git-URL, eine docker-compose-Datei, einen Datenbanknamen — in privilegierte Operationen auf Ihren Servern zu übersetzen. Eine größere Angriffsfläche kann ein selbst gehostetes Tool kaum haben. Das wiederkehrende Muster in diesen CVEs ist immer dasselbe: Nutzereingaben erreichen eine Shell ohne ausreichende Validierung, über viele unabhängige Code-Pfade.

Dazu kommen das Feature-Tempo eines jungen Produkts — alle oben genannten verwundbaren Versionen tragen noch 4.0.0-beta.4xx im Namen, das erste stabile Release erschien erst im April 2026 — und ein kleines Kernteam: Diese Klasse von Fehlern wird also wieder auftauchen. Fairerweise: Das Projekt patcht schnell und arbeitet über Responsible Disclosure mit Security-Forschern zusammen. Dieser Teil funktioniert.

Die Lehre lautet nicht „Finger weg von Coolify“. Sie lautet: Behandeln Sie es wie Produktionsinfrastruktur, nicht wie ein Wochenend-Tool.

Die ehrliche Einordnung: Wer ist wirklich gefährdet?

Die meisten der elf Januar-CVEs setzen eine Anmeldung voraus. Wenn Sie der einzige Admin sind, niemand sonst einen Account hat und Ihr Dashboard nicht aus dem Internet erreichbar ist, braucht ein Angreifer erst Ihre Zugangsdaten, bevor einer der CVSS-10.0-Bugs relevant wird. Ihr reales Risiko ist deutlich kleiner, als die Schlagzeilen klingen.

Das Problem: Reale Installationen sehen selten so aus.

  • 52.890 Dashboards waren öffentlich erreichbar — 15.000 davon in Deutschland.
  • Es gab auch Vektoren ohne Anmeldung: Host-Header-Injection im Passwort-Reset und ein Rate-Limit-Bypass am Login.
  • In Team-Setups führten mehrere Wege von einem Account mit geringen Rechten zu Root — unter anderem schlicht das Auslesen des privaten SSH-Keys des Root-Nutzers.
  • Über das Stored XSS platziert ein Nutzer mit geringen Rechten Code, der im Browser des Admins ausgeführt wird.

Wenn einer dieser Punkte auf Ihr Setup zutrifft, ist „dafür braucht man einen Login“ keine Verteidigung.

öffentlich erreichbares Coolify-Dashboard im Vergleich zu abgesichertem Setup hinter VPN.

Die Absicherungs-Checkliste

Arbeiten Sie diese Liste ab — auch, wenn Sie nie mit uns sprechen:

1. Updaten — und dranbleiben.
4.0.0-beta.451 ist das absolute Minimum; besser: das aktuelle stabile Release — v4.1.2, Stand Juli 2026. Coolify hat die Beta-Phase am 27. April 2026 mit v4.0.0 verlassen, und allein 4.1.2 bringt eine weitere lange Liste an Sicherheitsfixes. Abonnieren Sie die GitHub Security Advisories des Projekts — neue kritische CVEs kamen zuletzt alle paar Monate.

2. Das Dashboard aus dem öffentlichen Internet nehmen.
VPN (WireGuard/Tailscale) oder eine strikte IP-Allowlist. Dieser eine Schritt beseitigt den Großteil des Januar-Risikos.

3. Secrets rotieren, falls je eine Version ≤ beta.434 lief.
Private Keys waren für Nutzer mit geringen Rechten lesbar. Rotieren Sie SSH-Keys, API-Tokens und Datenbank-Passwörter — ein Update macht ein Leak nicht ungeschehen.

4. RBAC minimal halten.
Jeder Member-Account war eine potenzielle Root-Shell. Vergeben Sie App- und Server-Verwaltungsrechte nur an Personen, denen Sie ohnehin Root geben würden.

5. Control Plane trennen.
Betreiben Sie Coolify nach Möglichkeit auf einem eigenen Host, nicht neben den Produktions-Workloads. Das begrenzt den Schaden, wenn — nicht falls — die nächste Lücke kommt.

6. Monitoring aufsetzen.
Alarme für ungewöhnliche API-Aufrufe, neue SSH-Keys und Konfigurationsänderungen auf dem Coolify-Host.

7. Backups nicht auf dem Coolify-Host lagern.
Eine Root-Kompromittierung der Control Plane darf nicht auch noch Ihre Backups mitnehmen.

Wann selbst gehostetes Coolify eine gute Wahl ist

Wir reden Ihnen kein Tool aus, das passt. Betreiben Sie Coolify weiter selbst, wenn:

  • darauf Side-Projects, interne Tools oder Staging laufen — nichts, wonach ein Kunde oder eine Aufsichtsbehörde fragen würde.
  • Sie alleiniger Admin sind, das Dashboard hinter einem VPN liegt und Updates innerhalb von Tagen eingespielt werden, nicht Monaten.
  • Sie den Betrieb gern selbst machen — das geht vielen so, und Coolify ist ein gutes Produkt.

Wann es das nicht mehr ist

Die Rechnung kippt, wenn:

  • Kundendaten oder Produktions-Workloads eines Unternehmens darauf laufen — erst recht unter DSGVO oder im Anwendungsbereich von NIS2.
  • mehrere Personen Accounts haben. Jede davon war im Januar eine CVE von Root entfernt.
  • die Frage „Wer spielt einen kritischen Patch innerhalb von 24 Stunden ein — auch im Urlaub?“ keine Antwort hat.

Die Software ist kostenlos, die Betriebspflicht ist es nicht. Es ist dasselbe Argument wie bei Alpha-Storage: Irgendjemand muss das Risiko tragen. Entweder Ihr Team — mit Update-Disziplin, Monitoring und Rufbereitschaft — oder Sie bezahlen jemanden dafür.

Was wir tun

Hostzero betreibt Open-Source-Infrastruktur für EU-Unternehmen aus unserem Frankfurter Rechenzentrum. Für Coolify-Setups, die aus dem DIY-Stadium herausgewachsen sind, heißt das: ein Security-Audit Ihrer bestehenden Instanz (Erreichbarkeit, Versionen, RBAC, Secret-Rotation), gehärteter Managed-Betrieb — Dashboard nur per VPN, Monitoring, Patches mit SLA — oder, wo es besser passt, die Migration auf eine Plattform, die wir ohnehin im großen Maßstab betreiben.

Sprechen Sie mit einem Experten — 30 Minuten, kein Verkaufsgespräch. Beschreiben Sie uns Ihr Setup, und wir sagen Ihnen ehrlich, ob die Checkliste oben für Sie ausreicht.

Häufige Fragen

Ist Coolify 2026 sicher nutzbar?
Ja, unter Bedingungen: aktuelle Version, Dashboard nicht öffentlich erreichbar, Secrets rotiert (falls eine verwundbare Version lief) und eine klare Zuständigkeit fürs Patchen. Das Projekt selbst wird aktiv gepflegt und behebt Lücken schnell.

Welche Version behebt die Lücken?
4.0.0-beta.451 schließt die Januar-Welle; spätere Lücken wurden in Folge-Releases behoben. Inzwischen hat Coolify die Beta-Phase verlassen — Stand Juli 2026 ist v4.1.2 aktuell. Fahren Sie das neueste stabile Release und prüfen Sie die Security Advisories des Projekts.

Wurden die Coolify-Lücken aktiv ausgenutzt?
Bis Juli 2026 sind keine Angriffe in freier Wildbahn bestätigt. Bei rund 52.000 öffentlich erreichbaren Instanzen sollten Sie trotzdem davon ausgehen, dass Scanner danach suchen.

Ich betreibe Coolify allein, als einzelner Nutzer. Bin ich betroffen?
Ihr Risiko ist deutlich geringer — die meisten CVEs brauchen einen angemeldeten Nutzer. Aber Passwort-Reset und Rate-Limit-Bypass funktionierten ohne Anmeldung; ein offenes Dashboard bleibt ein Risiko. Legen Sie es hinter ein VPN.

Sollte ein Unternehmen Coolify produktiv einsetzen?
Das Problem ist nicht die Kategorie, sondern der Betrieb. Wer unter DSGVO oder NIS2 fällt, betreibt Coolify mit derselben Sorgfalt wie jedes andere Tool mit Root-Zugriff auf die Server — oder lässt es betreiben.

Haben Sie Fragen zu diesem Thema?

Unsere Experten beraten Sie gerne zu Ihrer individuellen Strategie.

Beratungsgespräch vereinbaren