Termix: any authenticated user can read other users' stored SSH and sudo passwords

Impact

Termix's host-password endpoint resolves a numeric host ID against the owner's context when the requester-scoped lookup fails, so any user holding a valid JWT can walk sequential host IDs and pull back other users' plaintext SSH and sudo credentials. Termix is a web console for managing servers over SSH, so the stolen credentials are exactly the ones that log into the fleet - and the sudoPassword field means the attacker gets root on those hosts, not just shell. The blast radius is not confined to the Termix instance: the credentials work directly against every managed system, including any GPU node or management host registered by another operator. Recovery is not just patching, because every credential ever stored in the instance must be treated as disclosed.

Who can reach it

Any authenticated Termix user with a valid JWT - a low-privilege account is enough. No ownership of the target host and no access to the underlying servers is required beforehand.

What to do

Upgrade Termix to 2.6.1, which fixes the ownership check; that is a container or service restart of the Termix instance and does not touch managed hosts. Then rotate every SSH and sudo password that was stored in the instance, on the assumption they were readable by all users while the flaw was live - that rotation, not the upgrade, is the expensive part, and it touches each managed node.

References