Termix EUVD-2026-62857

Requires a valid authenticated Termix session (JWT) - per CVSS PR:L this is an authenticated attack, so an attacker must be able to obtain an account, which is trivial on instances that permit self-registration and harder on locked-down single-tenant deployments. The specific trigger is calling GET /host/db/host/:id/password with field=password or field=sudoPassword against host IDs the caller does not own; exploitation is enabled by sequential integer host IDs (making enumeration reliable) and by the endpoint's fallback that resolves the host in the owner's context after the requester-scoped lookup fails. Limiting factors: the instance must have more than one user and contain hosts with stored SSH/sudo passwords, and the value of the leak scales with how many other tenants' credentials exist. No special client platform or user interaction is needed.

This is a genuine high-priority issue, not a paper-high CVSS. The vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H) describes a remotely reachable, low-complexity attack needing only a low-privilege account - exactly the profile of a self-service or multi-user Termix instance - and the scope change is justified because harvested SSH/sudo passwords let the attacker pivot to systems entirely outside Termix. The I:H rating reflects that downstream control, not integrity impact on Termix's own data, which is worth noting when reconciling the 9.6 with a read-only disclosure bug. No EPSS score, KEV listing, or public PoC was provided, so real-world exploitation pressure is currently unquantified; the practical bar is simply having any valid account, which on instances that allow open registration is very low. Given that a single compromised low-privilege account can cascade into full compromise of every managed host, even a small self-hosting operator running Termix should treat patching as urgent. Missing signals (EPSS, PoC status) mean I cannot confirm active or imminent exploitation - treat urgency as driven by impact and ease, not by observed attacks.

An attacker registers or obtains a low-privilege Termix account and authenticates to get a JWT. They script requests to GET /host/db/host/:id/password?field=password and ?field=sudoPassword while incrementing the numeric id, dumping other users' plaintext SSH and sudo passwords, then use those credentials to log directly into the managed servers and take control. The low attack complexity (AC:L) and lack of required user interaction make this straightforward to automate; no public exploit code is identified at time of analysis.