CVE-2026-79762 in Termix
Summary
by MITRE • 09/24/2026
Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. From 1.7.0 until 2.5.1, Termix derives the keys that wrap OIDC and WebAuthn users' Data Encryption Keys from committed default strings and the public userId salt in src/backend/utils/user-crypto.ts. Because OIDC_SYSTEM_SECRET and WEBAUTHN_SYSTEM_SECRET are not configured by the project's default deployment artifacts, an attacker with an offline SQLite database copy can derive the wrapping key, recover each affected user's DEK, and decrypt stored SSH passwords, private keys, and key passphrases. Password-authenticated users are not affected by this specific key derivation path. This issue is fixed in version 2.5.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in Termix versions ranging from 1.7.0 to 2.5.1 represents a critical failure in cryptographic key management, specifically concerning the protection of sensitive user credentials stored within the application's SQLite database. Termix is designed as a web-based server management platform that provides SSH terminal access, tunneling capabilities, and file editing functionalities. To secure data at rest, such as SSH passwords, private keys, and their associated passphrases, the system employs Data Encryption Keys (DEKs) which are themselves wrapped by higher-level wrapping keys derived from user-specific salts and system secrets. The core technical flaw lies in the implementation of these derivation mechanisms within the src/backend/utils/user-crypto.ts module for users authenticated via OpenID Connect OIDC or WebAuthn protocols.
The root cause of this vulnerability is that the application derives the cryptographic keys used to wrap DEKs from committed default strings rather than unique, securely generated secrets configured during deployment. Specifically, the system relies on hardcoded values for OIDC_SYSTEM_SECRET and WEBAUTHN_SYSTEM_SECRET because these configuration parameters are not set by the project's default deployment artifacts. Consequently, every instance of Termix running with default settings utilizes identical secret material to generate wrapping keys for all affected users. This lack of entropy in the key derivation process means that an attacker who gains access to a copy of the SQLite database can systematically derive the exact same wrapping keys used by the legitimate application server.
The operational impact of this flaw is severe, as it allows for the complete compromise of stored sensitive data without requiring active network interaction or exploitation of remote code execution vulnerabilities. An attacker with offline read access to the Termix SQLite database file can extract the public userId salt and combine it with the known default system secrets to reconstruct the wrapping keys. Once these keys are derived, they can be used to decrypt each affected user's Data Encryption Key. With the DEK recovered, all encrypted credentials stored in the database become accessible, including SSH passwords, private key material, and passphrases required for key-based authentication. This effectively neutralizes the encryption protection intended by the application developers, exposing users' infrastructure access details to unauthorized parties who may have obtained a backup or copy of the database through other means such as server compromise or improper data handling practices.
It is important to note that this specific vulnerability path does not affect password-authenticated users within Termix. The flaw is isolated to the key derivation logic applied exclusively to OIDC and WebAuthn user accounts, meaning those relying solely on traditional username-password authentication remain protected by different cryptographic mechanisms that do not rely on these compromised default secrets. However, for any organization utilizing single sign-on or hardware security keys with Termix, this vulnerability presents a significant risk profile where database exposure directly translates into credential theft.
To mitigate this issue and prevent similar vulnerabilities in future deployments, it is imperative to ensure that the application version is updated to 2.5.1 or later, where the key derivation logic has been corrected to use properly configured secrets rather than hardcoded defaults. For environments still running vulnerable versions, immediate remediation involves manually configuring unique, high-entropy values for OIDC_SYSTEM_SECRET and WEBAUTHN_SYSTEM_SECRET in the deployment configuration files. Additionally, organizations should enforce strict access controls on database storage locations to prevent unauthorized offline copies from being made. From a standards perspective, this vulnerability aligns with CWE-321 Use of Hard-coded Cryptographic Key, as it involves the use of static keys that are not unique per instance or user. Furthermore, in terms of attack vectors, this scenario reflects aspects of ATT&CK technique T1005 Data from Local System Retrieval, where an adversary accesses data directly from local storage after gaining initial access to the system hosting the database files.