The official Docker image for Termix contains a critical misconfiguration that allows unauthenticated access to sensitive SSH credentials. An Nginx reverse proxy setup causes the backend to misidentify all incoming requests as originating from localhost.
As a result, the internal API endpoint that exposes stored SSH host information—including server addresses, usernames, and passwords—can be accessed without any login or authentication, posing an extremely high security risk.
Vulnerability Details
Termix’s backend uses the Express framework to determine client IP addresses via const ip = req.ip || req.connection?.remoteAddress.
When deployed with the official Docker image, Nginx proxies all traffic over HTTP/1.1 to the Termix service at 127.0.0.1:8081. Although proxy headers such as X-Real-IP and X-Forwarded-For are set, Termix ignores these in favor of req.ip, which resolves to the proxy’s own address (127.0.0.1).
Consequently, the isLocalhost check in Termix always evaluates to true, granting unrestricted access to the /ssh/db/host/internal endpoint.
The vulnerable code snippet illustrates how the application routes SSH database requests based solely on IP origin detection rather than proper authentication controls. With the default Nginx configuration provided, any user who can reach the proxy can retrieve the entire SSH host database:
textlocation /ssh/ {
proxy_pass http://127.0.0.1:8081;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Because Termix and Nginx share the same container or VM environment, requests to /ssh/db/host/internal bypass authentication entirely.
Researchers have demonstrated this by mapping network assets to identify vulnerable deployments and confirming stable reproduction of the issue. Screenshots of intercepted responses reveal cleartext SSH configurations including hostnames, ports, usernames, and passwords.
Impact and Remediation
Anyone using the official Termix Docker image versions from release-0.1.1-tag through release-1.6.0-tag is at risk.
This vulnerability, tracked as CVE-2025-59951, falls under CWE-284 (Improper Access Control) and CWE-348 (Use of Less Trusted Source), since the service relies on an untrusted source for IP verification and fails to restrict access to a sensitive endpoint appropriately.
Attackers who gain network access to the proxy can exfiltrate SSH credentials, potentially compromising critical infrastructure and lateral movement within enterprise environments.
To remediate, Termix maintainers should replace the req.ip based check with logic that properly validates X-Real-IP or X-Forwarded-For headers and implement robust authentication and authorization controls for the /ssh/db/host/internal endpoint.
For immediate defense-in-depth, operators should restrict access to the SSH database endpoint at the proxy layer, enforce network access controls, and rebuild images after applying the updated validation logic.
A proof-of-concept demonstrates this vulnerability with a simple HTTP GET request to the internal endpoint:
textGET /ssh/db/host/internal HTTP/1.1
Host: 192.168.31.163:8080
Connection: close
Upon execution, the server returns a JSON array of SSH host entries without requiring any credentials. Organizations are urged to audit their Termix deployments, rotate exposed SSH keys and passwords, and upgrade to a patched release once available.
CVE ID: CVE-2025-59951
Affected Versions: release-0.1.1-tag through release-1.6.0-tag
Weaknesses: Improper Access Control (CWE-284); Use of Less Trusted Source (CWE-348)
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
