SmartIT Desktop Manager 10 and earlier contain four hard-coded credential vulnerabilities, affecting SSH, AES communication keys, SFTP, and remote
SmartIT Desktop Manager from Juxin Information has been disclosed to contain 4 vulnerabilities, corresponding to CVE-2026-85146, CVE-2026-85147, CVE-2026-85148, and CVE-2026-85149. TWCERT has classified them as TVN-202609001, with a public disclosure date of 2026-09-04. The advisory states that affected versions are SmartIT Desktop Manager 10 and earlier, and the remediation is to update to version 11 and later. The common core of these 4 issues is Use of Hard-coded Credentials, and they can be triggered by unauthenticated remote attackers.[1]
From the advisory title, it is clear that this is not a single flaw, but a systemic risk centered on fixed credentials. When a management tool or agent writes account names, passwords, or keys directly into code, anyone who can obtain the program contents may, without logging in, turn that into direct access to the host, communication content, or file system.[1]
The issue in CVE-2026-85146 is that remote unauthenticated attackers can obtain the SSH service account and password for the SmartIT Agent from the code, meaning SSH access no longer depends on a separate secret-management mechanism and is instead exposed within the application itself.[1]
CVE-2026-85147 exposes another specific password that can be used to obtain the AES encryption key for communications. This design causes the encryption mechanism to lose its intended protection boundary, because the password is not only a login credential but also indirectly a gateway to the materials used to protect communications.[1]
CVE-2026-85148 is more direct: the advisory explicitly states that an attacker can use a fixed password to remotely access the user's host. When a system uses a fixed password as the basis for authentication, the weakness is no longer just a secret leak, but may directly become a remote login risk at the host level.[1]
CVE-2026-85149 involves the SmartIT Agent's SFTP service account and password. Once an attacker obtains this information, they can further browse the user host's file system, extending the issue from remote access to file visibility and data exposure.[1]
Although the four vulnerabilities map to different functional areas, their attack surface is built on the same weakness pattern: hard-coding sensitive credentials into code. The danger lies not only in the possibility that credentials may be recovered by reverse engineering or by inspecting the program, but also in the fact that if the same set of credentials is reused in multiple places, a single leak can affect SSH, AES communication keys, and SFTP access, among other assets.[1]
The advisory clearly identifies the affected product as SmartIT Desktop Manager 10 and earlier, so any deployment that remains within that version range should be considered exposed to risk.[1]
According to the CVSS descriptions, CVE-2026-85146 and CVE-2026-85148 are rated Critical, CVE-2026-85147 is High, and CVE-2026-85149 is Medium, indicating that the impact spans confidentiality, integrity, and availability, with different consequences for each flaw.[1]
In practice, remote unauthenticated vulnerabilities like these are especially sensitive in management software. Because such tools typically sit in endpoint management, agent control, or remote operations chains, abuse can affect not just a single endpoint but also the overall management process and the trust foundation of the host fleet.[1]
The first measure is to immediately update to SmartIT Desktop Manager 11 and later, which is the official remediation specified in the advisory.[1]
Second, inventory all currently operating SmartIT Desktop Manager 10 and earlier nodes, especially hosts with remote operations, agent communication, and file exchange functions, to ensure that no remotely reachable deployment points are missed.[1]
Third, check whether the same credentials are reused for SSH, SFTP, communication encryption, or other control channels. If so, replace them at the same time with independent and unique passwords or keys to avoid lateral risk from a single point of exposure.[1]
Fourth, it is recommended to apply the principle of least privilege to management interfaces, agent communications, and file exchange services, reducing the operational scope even if credentials are obtained, and to include abnormal logins, SFTP access, and management channel connections in audit monitoring.[1]
Fifth, for exposed older versions, check both before and after upgrading whether the host shows any unknown SSH, SFTP, or remote login activity, and rebuild related credentials and rotate communication keys if necessary to reduce residual risk.[1]