A dump that knew too much

If you press the key D in ctop, the tool writes the complete container state to the log. That's handy for debugging. Until July 2026, it was also the fastest way to write all environment variables of a container unmasked to a file.

Since version 0.8.7, the single view masks values of variables whose name looks like credentials: SECRET, PASSWORD, TOKEN, API_KEY. The state dump didn't know this logic. It bypassed the display and went directly into the ring buffer, into the file from CTOP_DEBUG_FILE and beyond the debug socket.

Version 0.8.8 moves the masking into its own package that both paths use. The pattern now includes AUTH, DSN, CERT, COOKIE and JWT grown. More important is the second change: the value is now also checked. A postgres://user:pass@host/db is rejected, regardless of whether the variable DATABASE_URL or FOO is called.

runc 1.4.2 closes three additional escapes

Until April 2026, ctop was still on runc 1.1.14. This series is end-of-life, and three escapes from the container (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) remain unpatched there. Version 0.8.6 raised the dependency to 1.4.0.

In November 2025, three additional reports with high severity were added (GO-2025-4096, GO-2025-4097, GO-2025-4098), fixed only from runc 1.4.1 onwards. Version 0.8.7 therefore catches up to 1.4.2.

This only affects you if you use the runC connector. It runs exclusively on Linux and is not the default. Anyone running ctop against the Docker socket was never exposed.

Why the CI now points to commit SHAs

A GitHub Action that you include as @v4 is a moving target. Whoever can re-tag it executes code in your build. For a project that delivers binaries for five platforms, this becomes expensive.

In 0.8.8, every Action points to a full commit SHA, with the version number as a comment next to it. govulncheck is pinned to v1.5.0 instead of @latest. All six jobs have a timeout-minutes, and the Docker base image is pinned by SHA256 digest instead of by tag.

0.8.7 had already closed a gap in the workflow itself before that. The tag input from workflow_dispatch landed directly in a shell line; whoever was allowed to trigger the workflow could inject commands through it. Now the value goes through env: and is no longer interpolated into the line.

Update to 0.8.8, and check your old debug files

brew upgrade ctop

Or as a container: docker pull ghcr.io/eqms/ctop:latest.

If you previously CTOP_DEBUG=1 in an environment where real credentials are stored, check the old debug files and the log ring buffer. The masking takes effect from the update onward, not retroactively.