Safeguard
Vulnerability Analysis•

CVE-2025-59951: Critical Auth Bypass in Termix Docker Image

CVE-2025-59951 is a critical auth bypass in the official Termix Docker image that exposes saved SSH credentials. Upgrade to 1.7.0 and rotate credentials.

Safeguard Security Team
4 min read

CVE-2025-59951 is a critical (CVSS 9.1) authentication bypass in the official Termix Docker image. Behind its bundled Nginx proxy, every request looks local, so an internal endpoint that lists saved SSH hosts and passwords is open without login. The record names 1.6.0 as the fix; the advisory lists 1.7.0, so use 1.7.0 or later.

What's affected

  • Product: Termix, a web-based server management platform with SSH terminal, tunneling and file editing.
  • Weaknesses: CWE-284 (improper access control), CWE-345 (insufficient verification of data authenticity) and CWE-348 (use of less trusted source).
  • Affected per the CVE record: version 1.5.0 and below. The GitHub advisory lists a wider range, from release-0.1.1-tag through release-1.6.0-tag.
  • Fixed: the record says 1.6.0. The advisory lists 1.7.0 as the patched version.
  • Who is exposed: anyone using the official Docker image, a build from the official Dockerfile, or the reverse proxy functionality.
  • CVSS 3.1: 9.1, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. No login and no user interaction.

Source conflict: the CVE text and the advisory disagree on the fixed version (1.6.0 against 1.7.0). Taking 1.7.0 or later is the safe reading, because it satisfies both.

How to check if you're exposed

Find where Termix runs and which image or tag it uses:

docker ps --format '{{.Names}} {{.Image}}' | grep -i termix
docker image ls | grep -i termix

If the tag is 1.6.0 or lower, or you cannot tell, assume you are exposed.

The advisory explains the cause: inside the official image, an Nginx proxy forwards to the backend on the same host, so the backend sees the proxy address as the client address. The check that decides whether a request is local therefore always says yes. That means the quickest exposure test is network based. Ask whether anyone who can reach the Termix port, from a LAN, a VPN or the internet, should be able to read your stored host list. If the answer is no, you need the fix.

Review your access logs for requests to the internal host endpoint named in the advisory from addresses you do not recognize. Absence of hits is not proof of safety, so rotate credentials either way.

What to do now

  1. Upgrade Termix to 1.7.0 or later and redeploy the container from the new image.
  2. Until the upgrade is done, take the Termix port off any shared or public network, or put it behind a VPN or an authenticating proxy.
  3. Treat every SSH host, username and password saved in Termix as potentially exposed. Rotate those credentials and prefer key-based logins.
  4. Check server and proxy logs for unexpected requests to the internal host endpoint.
  5. Review any reverse proxy you run in front of Termix. Make sure client IP handling is explicit and that internal-only routes are not trusted by address alone.
  6. Use the free in-browser dependency scan on your deployment repository to catch the image version in future.

Why it matters

This is a trust-boundary bug, not a memory bug. The backend decided who counts as local by reading the connection address. Once a reverse proxy sits in front, that address is always the proxy, so the "local only" door is open to everyone.

The same mistake shows up in many products. Any rule that says "trust this request because it comes from localhost" breaks when a proxy, container network or tunnel is introduced. Safer designs authenticate the internal route properly, or bind it to a socket that cannot be reached from outside.

The impact is high because the endpoint returns stored SSH addresses, usernames and passwords. A server management tool is a credential vault by another name, so one exposed route can turn into access to every host in it. The record does not flag this as exploited in the wild and it is not on the CISA KEV list.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Is the 1.6.0 fix enough?

The CVE text names 1.6.0, but the advisory lists 1.7.0 as the patched version. Move to 1.7.0 or later to satisfy both.

Do I need to rotate credentials after patching?

Yes if the instance was reachable by anyone untrusted. The endpoint returns stored SSH details, and patching does not undo a past read.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.