Ein Dump, der zu viel wusste

Drückst du in ctop die Taste D, schreibt das Tool den kompletten Container-State ins Log. Das ist beim Debuggen praktisch. Es war bis Juli 2026 auch der schnellste Weg, sämtliche Umgebungsvariablen eines Containers unmaskiert in eine Datei zu schreiben.

Seit Version 0.8.7 maskiert die Einzelansicht Werte von Variablen, deren Name nach Zugangsdaten aussieht: SECRET, PASSWORD, TOKEN, API_KEY. Der State-Dump kannte diese Logik nicht. Er ging an der Anzeige vorbei direkt in den Ring-Buffer, in die Datei aus CTOP_DEBUG_FILE und über den Debug-Socket hinaus.

Version 0.8.8 zieht die Maskierung in ein eigenes Paket, das beide Pfade benutzen. Das Muster ist dabei um AUTH, DSN, CERT, COOKIE und JWT gewachsen. Wichtiger ist die zweite Änderung: Geprüft wird jetzt auch der Wert. Ein postgres://user:pass@host/db fliegt raus, egal ob die Variable DATABASE_URL oder FOO heißt.

runc 1.4.2 schließt drei weitere Escapes

Bis April 2026 lag ctop noch auf runc 1.1.14. Diese Reihe ist end-of-life, und drei Ausbrüche aus dem Container (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) bleiben dort ungepatcht. Version 0.8.6 hob die Abhängigkeit auf 1.4.0.

Im November 2025 kamen drei weitere Meldungen mit hoher Einstufung dazu (GO-2025-4096, GO-2025-4097, GO-2025-4098), gefixt erst ab runc 1.4.1. Version 0.8.7 zieht deshalb auf 1.4.2 nach.

Das betrifft dich nur, wenn du den runC-Connector einsetzt. Er läuft ausschließlich unter Linux und ist nicht der Standard. Wer ctop gegen den Docker-Socket fährt, war nie exponiert.

Warum die CI jetzt auf Commit-SHAs zeigt

Eine GitHub Action, die du als @v4 einbindest, ist ein bewegliches Ziel. Wer das Tag umhängen kann, führt Code in deinem Build aus. Bei einem Projekt, das Binaries für fünf Plattformen ausliefert, wird das teuer.

In 0.8.8 zeigt jede Action auf einen vollen Commit-SHA, mit der Versionsnummer als Kommentar daneben. govulncheck hängt auf v1.5.0 statt auf @latest. Alle sechs Jobs haben ein timeout-minutes, und das Docker-Base-Image ist per SHA256-Digest gepinnt statt per Tag.

0.8.7 hatte davor schon eine Lücke im Workflow selbst geschlossen. Der Tag-Input aus workflow_dispatch landete direkt in einer Shell-Zeile, wer den Workflow auslösen durfte, konnte darüber Kommandos einschleusen. Jetzt geht der Wert über env: und wird nicht mehr in die Zeile interpoliert.

Update auf 0.8.8, und schau in deine alten Debug-Dateien

brew upgrade ctop

Oder als Container: docker pull ghcr.io/eqms/ctop:latest.

Wenn du bisher CTOP_DEBUG=1 in einer Umgebung gesetzt hast, in der echte Zugangsdaten liegen, sieh in die alten Debug-Dateien und den Log-Ring-Buffer. Die Maskierung wirkt ab dem Update, nicht rückwirkend.