CVE-2026-53548: Termix: IDOR — Authenticated user can fetch SSH passwords for hosts owned by other users

Published Aug 19, 2026
·
Updated

Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. Prior to 2.6.1, the GET /host/db/host/:id/password endpoint in src/backend/database/routes/host.ts accepts an authenticated user's numeric host ID and the field=password or field=sudoPassword query without enforcing host ownership during credential resolution. A failed requester-scoped lookup can resolve the host with the owner's context and return the owner's plaintext credential, allowing any authenticated user with a valid JWT to enumerate sequential hosts.id values and retrieve SSH or sudo passwords belonging to other users. The disclosed credentials can then be used to access and control managed systems outside the Termix instance. This issue is fixed in version 2.6.1.

Affected Software

1 affected component
Termix<2.6.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Termix to a version that resolves this vulnerability.

    Fixed in 2.6.1

Event History

Aug 19, 2026
CVE Published
via MITRE·08:35 PM
Data Sourced
via MITRE·08:35 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are affected?

Termix versions prior to 2.6.1 are affected. The vulnerable endpoint is accessible to authenticated users, so environments where multiple users manage hosts through the same Termix instance are exposed to cross-user credential retrieval.

2

What does an attacker need to exploit this issue?

An attacker needs a valid Termix JWT and a target numeric host ID. They can enumerate sequential hosts.id values and request either the password or sudoPassword field from the affected endpoint.

3

What is the likely impact if exploitation has occurred?

An attacker can obtain plaintext SSH or sudo passwords for hosts owned by other users. Those credentials may then allow access to and control of managed systems outside the Termix instance.

4

How can teams determine whether they are protected?

Verify that the deployed Termix version is 2.6.1 or later. Versions before 2.6.1 should be treated as vulnerable.

5

What should be done if credentials may have been exposed?

Update Termix to version 2.6.1, then rotate SSH and sudo passwords for managed hosts that may have been accessible through the vulnerable instance. Review access associated with Termix users and JWTs because any authenticated user could have retrieved other users' credentials.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203