Skip to content

CVE-2026-121624: Improper certificate validation in Supremo Remote Desktop

As mentioned in a previous article, TLS is meant to provide three properties: authentication, confidentiality and integrity. Of the three, authentication is the one most often overlooked. Confidentiality and integrity are only meaningful if the client first establishes that it is talking to the legitimate server, and that guarantee depends entirely on one step: validating the certificate the server presents.

When a client encrypts the connection but does not verify the certificate, the channel is still private against a passive eavesdropper, but offers no protection against an active man-in-the-middle. The attacker simply presents a certificate of their own, the client accepts it, and the attacker becomes one of the two endpoints of the "secure" channel.

This post documents such a case in Supremo Remote Desktop, the method used to identify it, its impact, and the fix released by the vendor.

What Supremo is

Supremo is a remote desktop product by Nanosystems S.r.l., available for Windows and macOS, which according to the vendor is used by 1.4 million users. It is used to take control of a machine over the internet: a support technician connecting to a customer's PC, a system administrator reaching a server, a user logging into a home computer from the office. The traffic between the client and the Supremo servers travels over TLS, as expected for a protocol that carries screen contents, keystrokes and credentials.

The issue lies in what the client does when it receives the server's certificate.

The missing validation

The vulnerability is an improper certificate validation (CWE-295) in the client-server communication. The Supremo client opened a TLS connection and accepted whatever certificate the other side presented, without verifying that it had been issued for the Supremo servers by a trusted certificate authority.

The TLS session remains encrypted, but if an attacker is positioned in the middle of the connection, they can present their own certificate, which the client accepts. From that point the attacker is one of the two endpoints of the channel, decrypting the traffic on one side and re-encrypting it on the other. Confidentiality holds against a passive eavesdropper, but is lost against an active one.

The attack vector is Adjacent, not Network: the attacker must hold a man-in-the-middle position on the same local network as the victim, for example on public Wi-Fi, behind a compromised router, or on an untrusted corporate network. This is not reachable by an arbitrary internet host, but it is not a demanding prerequisite either.

Identifying the issue with certmitm

The testing was performed with certmitm, a tool written by Aapo Oksman that automates this class of checks. certmitm sits in the middle of a TLS connection and systematically attempts a set of certificate manipulations, a self-signed certificate, a certificate with a replaced public key, a certificate signed by the wrong CA, and observes whether the client accepts any of them and proceeds to send application data.

A correctly implemented client rejects all of these and the connection terminates at the handshake. A vulnerable client accepts one or more of them, at which point certmitm can read the plaintext. The tool reduces the question "does this client validate certificates correctly?" from a manual inspection to a check that can be pointed at the traffic directly.

The arrangement is a standard man-in-the-middle setup: the victim machine was placed on a controlled Wi-Fi access point, its TLS traffic redirected through certmitm with a pair of iptables NAT rules, and the Supremo client was opened.

certmitm reported Supremo accepting the manipulated certificates and sending its data through the intercepted session, with no handshake failure and no warning presented to the user.

A full recording of the procedure is below:

Impact

With the TLS session intercepted, the application-layer protocol is readable in clear text. In Supremo's case this includes:

Because the attacker holds a man-in-the-middle position rather than merely observing, the data exchanged between client and server can also be modified, not only read.

The password hash deserves a note, as "it is hashed" is often taken as sufficient protection. A plain SHA-256 of a password is not safe to disclose: SHA-256 is a fast hash, which allows an attacker to test a very large number of candidate passwords per unit of time, and without a salt identical passwords produce identical digests. If the hash is also the value the protocol accepts for authentication, its disclosure is equivalent to disclosing the password. In either case it is credential material that should not be readable on the wire.

The license code is the licensed asset on which the product's entitlement model depends, and it is exposed in the same way.

Remediation

The issue was reported to Nanosystems and subsequently addressed by the vendor.

The vulnerability affects all versions before 5.0. It was fixed in version 5.0, released on 18 August 2026. Versions 5.0 and later were retested and the issue is no longer reproducible: the client now rejects the manipulated certificates.

Users should update to Supremo 5.0 or later. The product includes an automatic update mechanism, so most installations should already be covered, but this is worth verifying on systems that are updated infrequently, which is a common condition for the machines on which remote desktop software is installed.

Conclusions

The vulnerability is not technically elaborate. It involves no memory corruption and no novel cryptographic weakness: the client establishes a TLS connection and omits the verification of the peer's identity. Certificate validation is among the most frequently omitted steps in TLS implementations, precisely because the connection appears to function correctly without it, up to the point where an active attacker is present, which is the only situation it is intended to defend against.