Termix vulnerabilities

Termix is a server management platform that prior to version 2.3.2 accepted the account password as the sole authentication factor for MFA-critical operations. An attacker who obtains a user's password can completely disable TOTP or regenerate backup codes, rendering two-factor authentication ineffective.

Termix is a web-based server management platform that prior to version 2.3.2 had 16 file-manager endpoints that did not verify if the requesting user owns the SSH session identified by `sessionId`. An authenticated attacker who knows or guesses another user's active `sessionId` can access files on the victim's connected SSH host.

Termix, a web-based server management platform, versions 1.7.0 to 1.9.0, has a Stored Cross-Site Scripting (XSS) vulnerability in the File Manager component. The application fails to sanitize SVG file content before rendering, allowing an attacker who has compromised a managed SSH server to plant a malicious file. When previewed by the Termix user, it executes arbitrary JavaScript in the application context. This is fixed in version 1.10.0.

In Termix from 2.4.1 until 2.5.1, an authenticated Termix administrator can store attacker-controlled domain and email values through PATCH /users/acme-ssl-settings and trigger their interpolation into a certbot shell command through POST /users/acme-ssl-request. In acme-ssl-routes.ts, child_process.execSync invokes /bin/sh -c with those values only wrapped in double quotes, so shell metacharacters can execute arbitrary operating-system commands as the Termix backend process. Both HTTP webroot and DNS Cloudflare challenge modes are affected, and compromise exposes Termix databases, process secrets, stored credentials, and network reachability. This issue is fixed in version 2.5.1.

Termix before version 2.6.1 contains a vulnerability in the GET /host/db/host/:id/password endpoint that does not enforce host ownership during credential resolution. An authenticated user can enumerate host IDs and retrieve SSH or sudo passwords belonging to other users.

Termix before version 2.3.2 contains a vulnerability in the terminal WebSocket that allows an authenticated low-privileged user to use another user's credentials to connect to an attacker-controlled SSH server. This can lead to disclosure of SSH passwords or private keys.

Termix before version 2.3.2 contains a vulnerability in the SSH tunnel teardown path that interpolates user-controlled data into a pkill command pattern. An authenticated user can inject a shell command that executes when the tunnel is disconnected.

Termix is a web-based server management platform that prior to version 2.3.2 had a vulnerability in the `POST /ssh/tunnel/connect` endpoint. This vulnerability allowed OS command injection through user-controlled fields being interpolated directly into a shell command.

Termix is a web-based server management platform that was vulnerable to OS command injection in the GET /ssh/file_manager/ssh/resolvePath endpoint prior to version 2.3.2. This allows authenticated users to execute arbitrary commands on the connected remote host.

Termix prior to version 2.1.0 contains a command injection vulnerability in Docker container management endpoints, where the containerId parameter is directly interpolated into shell commands, allowing an authenticated attacker to achieve remote code execution on the managed server.

Termix versions 1.5.0 and below, when using the official Docker image or an Nginx reverse proxy, incorrectly identifies the client IP as the proxy IP, causing isLocalhost to always return True. This makes the /ssh/db/host/internal endpoint accessible without login or authentication, exposing stored SSH host information including addresses, usernames, and passwords.

Termix versions 2.5.0 through 2.5.1 have a vulnerability in the /homepage/proxy endpoint that passes the url parameter to http.get or https.get without destination restrictions. URL validation is only syntactic, allowing requests to loopback, RFC1918, link-local, and cloud metadata destinations. An authenticated low-privilege user can exfiltrate internal service data and cloud credentials.

Termix from version 2.4.0 to 2.5.1 accepted the account password as the sole reauthentication factor in endpoints for disabling TOTP and regenerating backup codes. The refactor regressed the two-factor check, allowing an attacker with a victim's session and knowledge of the password to disable 2FA without access to an authenticator.

Termix from version 1.7.0 to 2.5.1 derived keys that wrap OIDC and WebAuthn users' Data Encryption Keys from committed default strings and the public userId salt. An attacker with an offline SQLite database copy can derive the wrapping key and decrypt stored SSH passwords, private keys, and key passphrases.

Termix versions 1.7.0 through 2.5.1 derive a grep pattern from user-controlled public-key input and interpolate it into shell commands executed on the target host during SSH key deployment. An authenticated user can inject shell syntax and execute commands with the privileges of the selected remote account. The issue is fixed in version 2.5.1.

Termix versions 2.5.0 through 2.5.1 allow authenticated users to configure webhook or ntfy notification channels with attacker-controlled destination URLs and trigger server-side requests via the notification-channel test endpoint. The lack of destination allowlisting or private-address blocking permits blind requests to internal HTTP services. The issue is fixed in version 2.5.1.

Termix versions 1.7.0 through 2.5.1, in the POST /credentials/:id/deploy-to-host endpoint, resolves credential and target-host records from attacker-controlled credentialId and targetHostId values without verifying ownership. Differential errors reveal record existence and authType values, and a key-authenticated victim host can receive an outbound SSH connection attempt using the attacker's public key. The issue is fixed in version 2.5.1.

Termix versions 1.8.0 through 2.5.1 allow authenticated users to access the server-stats API without per-host authorization. GET /status, GET /status/:id, and POST /clear-connections expose host state and let a regular user clear the global SSH connection pool. The issue is fixed in version 2.5.1.

In Termix before 2.3.2, the POST /host/db/proxy/test endpoint accepts singleProxy, proxyChain, and testTarget fields without validating destination addresses. The testProxyConnectivity path uses raw TCP and SOCKS connections to attacker-selected hosts and ports, allowing an authenticated user to probe localhost, private networks, link-local metadata services, and other infrastructure. Connection errors disclose host reachability, and metadata access can expose cloud credentials.

In Termix before 2.3.2, the POST /database/export endpoint creates a user export that includes the global settings table even though the rest of the export is user-scoped. The settings table contains password-reset artifacts, allowing a low-privileged authenticated user to recover another account's reset code and complete the password-reset flow. Successful exploitation results in local-user account takeover and administrative compromise when the victim is an administrator.

In Termix before 2.3.2, the archive creation endpoint passes selected file basenames to tar without an end-of-options marker and without making operands unambiguously relative. A user can select basenames beginning with GNU tar options such as --checkpoint=1 and --checkpoint-action=exec, causing tar to interpret them as options. The resulting checkpoint action executes commands on the managed SSH host with the privileges of the connected SSH account, allowing file disclosure, modification, and service disruption.

Termix is a web-based server management platform that prior to version 2.1.0 had vulnerabilities in the extractArchive and compressFiles endpoints. The use of double quotes for shell command construction allowed command injection on the remote SSH host.

Termix is a web-based server management platform that prior to version 2.1.0 issued a temporary JWT for TOTP-enabled accounts. This token, which should only be used in the two-factor authentication process, was accepted by the auth middleware on standard endpoints, effectively reducing security to single-factor.