Termix CVE-2026-53546

Requires an authenticated low-privileged Termix account (PR:L) on a multi-user instance, and the target victim's stored credential must be decryptable at request time - i.e., the victim's data key must currently be unlocked. The attacker must know or enumerate a valid hostConfig.id belonging to another user and must control (or be able to point the session at) an SSH server that captures the offered credential. Limiting factors: single-user Termix deployments have no other owner to steal from; if the victim's data key is locked the fallback credential cannot be decrypted; and network reachability to the attacker-controlled SSH destination is needed for the credential to leak. No victim interaction is required (UI:N).

This is a genuine high-priority issue rather than an inflated CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6) is internally consistent with the description: network-reachable WebSocket, low complexity, only a low-privileged authenticated account required, no victim interaction, and a scope change because credentials belonging to other users/systems are exposed. The practical catch is the PR:L prerequisite and the timing condition that the victim's data key must be unlocked, which is why real-world exploitation is targeted (an insider or a compromised low-priv account in a multi-tenant Termix instance) rather than internet-wide worming - no KEV listing and no EPSS score were provided, and no public exploit is identified, so mass automated exploitation is not currently evidenced. That said, the payoff is high (full SSH credential theft enabling lateral movement into the victim's fleet) and the fix is trivial to apply, so any multi-user Termix deployment should treat patching to 2.3.2 as urgent. Confidence in the mechanism is strong because the vendor advisory (GHSA-57gp-39c7-4g9r), PR #874, and the fix commit are all available.

A low-privileged Termix user stands up an SSH server they control, then opens a terminal session supplying a victim's hostConfig.id together with their own attacker ip/port/username. Termix resolves the victim's stored credential via the owner-credential fallback and authenticates outward to the attacker's server, which records the victim's SSH password or private key for reuse against the victim's real infrastructure. No public exploit is identified at time of analysis, but the advisory describes the mechanism precisely enough to reproduce.