En 2024, je vous présentais un de ces IP KVM avec le JetKVM. Un petit boitier capable de prendre le contrôle d’un PC à distance mais aussi de le réveiller physiquement même sans fonction Wake On Lan. Le tout en Open-source et avec une finition exceptionnelle. J’ai craqué depuis et je l’ai intégré dans mon réseau.
Reste qu’il y a quelque temps des chercheurs en sécurité ont découvert que ces IP KVM, il en existe toute une galaxie, posent un vrai souci de sécurité. Pas moins de neuf vulnérabilités ont été remontées chez quatre fabricants. La plus sévère permettant de prendre un contrôle total de la machine connectée et donc de lancer des opérations comme si l’attaquant en était le propriétaire assis physiquement devant le clavier de la machine.
Un IP KVM de la marque Luckfox
Problème, ces trous béants dans la sécurité de ces appareils ne sont pas nouveaux. Ils sont décrits comme équivalents aux problèmes de sécurité des premiers appareils IoT lancés il y a dix ans. Les marques GL-iNet, Angeet/Yeeso, Sipeed et JetKVM ont donc mis sur le marché des appareils plus que problématiques.
Et cela pourrait être pire qu’annoncé puisque certains constructeurs plus ou moins identifiés en Chine ont commencé à déployer des clones moins documentés de ces appareils Open Source. Certaines références low-cost ont commencé à inonder le marché sous des noms plus ou moins farfelus. Ci-dessus le Luckfox PicoKVM est proposé à moins de 40€ sur AliExpress. Ce n’est pas le pire du marché, il dispose même d’une page de suivi et le firmware a été mis à jour en février. Mais sans aucune note ou quelque information technique que ce soit… Le problème est que des dizaines de clones sont également proposés autour de lui.
| MARQUE | IP KVM | CVE | VulnerabilitE | CVSS 3.1 | STATUT DU Patch |
|---|---|---|---|---|---|
| GL-iNet | Comet RM-1 | CVE-2026-32290 | GL-iNet Comet KVM insufficient verification of firmware authenticity | 4.2 | Fix being planned. |
| GL-iNet | Comet RM-1 | CVE-2026-32291 | GL-INet Comet KVM UART root access | 7.6 | Fix being planned. |
| GL-iNet | Comet RM-1 | CVE-2026-32292 | GL-INet Comet KVM insufficient brute-force protection | 5.3 | Fixed in v1.8.1 BETA |
| GL-iNet | Comet RM-1 | CVE-2026-32293 | GL-iNet Comet KVM Insecure Initial Provisioning via Unauthenticated Cloud Connection | 3.1 | Fixed in v1.8.1 BETA |
| Angeet/Yeeso | ES3 KVM | CVE-2026-32297 | Angeet ES3 KVM unauthenticated file | 9.8 | No fix available |
| Angeet/Yeeso | ES3 KVM | CVE-2026-32298 | Angeet ES3 KVM OS command injection | 8.8 | No fix available |
| Sipeed | NanoKVM | CVE-2026-32296 | Sipeed NanoKVM configuration endpoint exposure | 5.4 | Fixed in NanoKVM v2.3.1 Fixed in NanoKVM Pro 1.2.4 |
| JetKVM | JetKVM | CVE-2026-32294 | JetKVM insufficient update verification | 6.7 | Fixed in version 0.5.4 |
| JetKVM | JetKVM | CVE-2026-32295 | JetKVM insufficient rate limiting | 7.3 | Fixed in version 0.5.4 |
Le Sipeed NanoKVM Pro un autre type d’IP KVM
Comme toujours, ces chercheurs en sécurité ne sont pas là pour poser un problème mais plutôt pour le résoudre. C’est en juin dernier que ces problèmes ont été remontés aux différents acteurs concernés. Le 10 juin 2025 par exemple, l’info a été posée sur le Github de JetKVM. Le 12 juin, le problème était réparé et une mise à jour était alors proposée aux propriétaires de l’appareil. Mais à la mi-mars 2026, ces mêmes chercheurs ont pu constater que plus de 1300 appareils étaient encore concernés et directement accessibles sur internet. Ils n’étaient que 1000 en juin 2025. Non seulement certaines marques n’avaient pas proposé de solutions, mais elles n’avaient pas pris en compte le problème et continuaient de proposer des appareils-passoires à leurs clients.
Le JetKVM
IP KVM = Mise à jour de firmware régulière obligatoire
Arstechnica présente donc cette liste d’appareils compromis et les éventuelles mises à jour proposées pour les différents modèles. Les solutions Angeet/Yeeso, GL-iNet n’ont toujours pas trouvé de solution depuis juin et sont donc dangereuses. Au mieux GL-iNet a proposé une bêta pour certaines vulnérabilités de son Comet RM-1… ce qui est une réponse bien maigre puisque, par défaut, ces appareils ne proposent pas de mises à jour automatiques des firmwares en version non finalisée. Depuis, la marque a proposé un nouveau firmware qui semble corriger le problème, le 20 mars 2026, soit trois jours après la publication de Arstechnica… Comme quoi c’est surtout l’absence de volonté de laisser du temps à ses ingénieurs pour faire ce travail de sécurité obligatoire plutôt qu’un vrai casse-tête technique.
A noter que les solutions IP KVM « maison » sur une base de carte de développement peuvent être tout aussi compromises. Il est donc, là encore, nécessaire de faire un travail de veille et de mise à jour régulier.
Dans tous les cas, si vous utilisez un IP KVM, faites un petit tour sur la page de support du constructeur pour vérifier la présence d’une éventuelle mise à jour depuis la mi-Mars. Et si vous avez le moindre doute, ne fermez pas les yeux et débranchez votre IP KVM de votre réseau. Le risque de perdre toutes vos données, ou pire, est trop grand pour jouer avec le feu. Pour ma part, j’ai une alerte régulière qui me dit de faire un tour pour vérifier la présence de mises à jour de ces appareils critiques.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
A ma connaissance, ce sont des clones d’un projet appelé PiKVM. J’ai installé chez moi la version open source de ce projet sur un Rpi qui traînait dans mes tiroirs et cela fonctionne très bien (derrière un VPN bien évidemment, jamais d’accès direct par internet). Le suivi logiciel est excellent, même pour la version open source. Rien à voir avec le suivi et l’absence de transparence du logiciel de tous ces clones…
Est-ce qu’on peut prendre en main un PC à distance via une tablette android avec cette solution ? Il suffit d’un simple navigateur pour accéder au PC distant ?
@sgspk: De quelle solution parles-tu ?
@François: Il ne faut pas jeter l’eau avec le bébé hors du bain. Certains de ces produits ont leurs propres atouts et proposent un vrai service. Le problème des produits PIKVM, c’est leur tarif. Je ne dis pas qu’il n’est pas justifié, c’est juste que pour un simple particulier qui veut résoudre le souci de la prise de contrôle d’un PC à distance pour aider, par exemple, un parent. C’est difficile à financer.
@Pierre Lecourt: oui tu as raison pour le tarif même si leur produit semble de très bonne qualité. Mais leur suivi logiciel est vraiment excellent et on peut en faire un soi même avec un RPi même modeste. C’est la solution que j’ai adoptée il y a 4 ans.
@sgspk: Oui en général l’appareil affiche une page web où tout le contrôle se fait.
Me demande ce que ce genre de solution matériel apportent de plus que les bons vieux wake on lan logiciel et SSH.
Et franchement, confier une tâche aussi sensible que la prise de contrôle à distance d’un ordi à du matériel chinois, c’est un chouia kamikaze quand même…
@El: Il suffit de lire la doc.
Pour le coup, JetKVM est européen. Les confondateurs sont Allemands et la société mère est en Estonie.
merci pour la doc mais je n’ai pas ce genre de matériel. En y réfléchissant, je ne vois pas ce que ça peut être d’autre qu’un gadget.
Il n’y a rien de plus sûr que le SSH pour contrôler à distance un ordi. Maintenant, chacun son truc.
C’est vrai que j’utilise et j’apprécie le CometPOE de GL.iNET, qui permet de jouer confortablement avec un PC comme si c’était un vrai petit serveur… Mais évidemment, on ne peut pas comparer ce type de produit à un vrai iDRAC/iLO/iRMC … On a ce pour quoi on paie, et ces produits ne sont pas prévus pour être déployés dans une entreprise, le risque est donc moindre, puisque cantonnés à des particuliers (qui, en plus, vu le type de produit, devraient connaître les risques ! ;-)
@El: Rien à voir avec SSH, mais plutôt avec des produits comme iLO ou assimilés sur la gestion headless de machines.
SSH ne permet pas de relancer des machines plantées, d’accéder à l’UEFI, de réinstaller complètement un serveur à distance, etc. C’est juste un shell distant.
@El: Je sais pas, tu dis que tu te demandes l’intérêt du truc, je te réponds que c’est dans la doc qui est disponible en ligne et tu réponds en disant que tu n’as pas le matériel. J’ai comme l’impression que ta question n’appelait pas de réponse parce que tu t’es forgé une opinion préalable. Tu as tout à fait le droit de dire que tu préfères une solution 100% software, pas de problème. Mais ignorer les réponses pour éviter de devoir y réfléchir n’est pas la meilleure solution.
J’ai un lecteur qui a au travail un serveur Xeon sur carte mère SuperMicro SANS WoL par exemple (j’ai exhumé son email) et qui a investi dans un appareil de ce genre. Parce que cela lui permet de piloter la machine à distance sans avoir a sortir en pleine nuit pour éviter de bloquer la production. C’est super anecdotique mais ce n’est pas inintéressant comme démarche. La solution alternative serait de changer de serveur, c’est une idée, mais la dépense n’est pas tout à fait la même. Et comme sa boîte ne voit pas le problème à ce qu’il se farcisse les kilomètres de bagnole de chez lui au boulot en cas de pépin en pleine nuit, il préfère ne pas trop les brusquer et opter pour un produit de ce type. Gadget ? Pas gadget ? Comme d’habitude, c’est suivant le profil de chacun.
Oui le SSH c’est super et le Wake-on-LAN aussi. Maintenant comment faire quand la machine à contrôler ne propose pas de WoL ? Pour moi le combo JetKVM + Tailscale n’est absolument pas un gadget. Maintenant, comme tu dis, chacun son truc.
Ben pour relancer une machine plantée, t’as le wake on lan. Et je ne vois pas trop dans quel cas on aurait besoin de réinstaller complètement un serveur à distance… Si c’est un serveur pro, on un accès physique à la machine, si c’est un VPS, pas besoin de ce matériel, si c’est un serveur perso, encore moins.
Et non, SSH n’est pas juste un shell distant : c’est un protocole de communication chiffré dont la sécurité est particulièrement éprouvée.
@ Pierre Lecourt : je n’avais pas compris ta réponse, ce n’était pas de la mauvaise foi. J’ai cru que tu me répondais sarcastiquement que je n’avais qu’à en acheter un et lire la doc…
Mais ta deuxième réponse est intéressante. Tu pouvais me dire tout ça dès ta première réponse au lieu de m’envoyer un peu bouler sur les bords ;o)
@El: Le prend pas mal, je n’envoie jamais bouler personne de prime abord. C’est juste que tous les liens sont dans le billet et que j’ai eu l’impression que tu ne voulais pas vraiment de réponse. Ces produits sont vraiment intéressants. Par exemple pour quelqu’un qui dépanne beaucoup de machines, avoir une petite flotte de ces outils pour faire face à plein de profils peu avoir du sens.
Je pense que les gens qui s’intéressent à ce genre de billet connaissent tous le SSH et ses qualités. Il n’est pas question, comme d’habitude, de dire que tel ou tel truc est mieux ou moins bien. C’est juste des histoires de profils et de besoins.
Pas de soucis Pierre, je ne l’ai pas mal pris.
Et merci pour les dernières précisions que tu apportes. En effet, dans le type de situation dont tu parles, ça a du sens d’utiliser ce matériel.
@El: C’est donc que tu n’es pas client de ce type de produit ;-) Tous les serveurs pro utilisent ce genre de solution, mais directement intégré à leurs cartes mère (iLO / iRMC, etc), ce qui va bien plus loin, car ces solutions font également un audit permanent du matériel du serveur. Aucun pro digne de ce nom va aller s’installer dans une salle info pour installer ou dépanner un serveur planté, y accéder physiquement après mise en place est vraiment rare, sauf pour remplacer un matériel défectueux. On les gère par automatisation via l’API redfish. Pour arriver jusqu’au SSH, il faut déjà un serveur fonctionnel avec un SE installé, et ne permettra jamais d’aller modifier le BIOS par exemple.
Cela fait donc sens de proposer ce type de produit pour des matériels plus accessibles qui n’en sont pas nativement dotés, ils facilitent vraiment la vie. Si j’utilise essentiellement l’iRMC et l’API Redfish, j’ai également des KVM de GL.iNet que je trouve très efficace pour mes besoins.
@Pierre Lecourt:
Pour aider un parent, un compte sans droits ni shell sur le Linux de chez soi et le serveur ssh des 2 côtés (sous FW côté proche susceptible de devoir être aisé)… un script avec la clef ssh sans passphrase sur le PC du proche qui permet d’établir une connexion reverse-tunnel sur un port local de sa machine vers ce compte sans droit… et en cas de pépin de configuration (faut quand même que ça boot de l’autre côté) ou de montrer une manip, le proche n’a qu’a double cliquer sur le script et on se connecte chez lui, remontant le reverse-tunnel pré-établi, sans aucun besoin de configuration FW/NAT de son côté. On doit juste ouvrir (éventuellement temporairement) le port de son serveur ssh de son côté avant établissement du tunnel.
OK, sous Windows ça marche moins bien et la plupart des solutions sans config passent par un tiers qu’on espère de confiance (en mettant les couches du même nom!)… mais l’autre avantage d’un Linux côté qqun qui n’y connaît pas grand chose, c’est que d’un compte utilisateur il ne cassera jamais rien non plus!
Jamais compris, pour ma part, l’intérêt de ces bidules à part que c’est un truc de plus à maintenir sur son réseau et qui ne sera plus maintenu un jour (éventuellement dès l’achat) par le fabricant.
@El: Je vais te répondre : avec un KVM tu accèdes à tout le PC à distance, y compris au BIOS/UEFI ou à un Grub qui a planté. Tu peux tout faire à distance, y compris installer un OS (ça émule même un lecteur DVD avec une ISO dedans).
J’ai 3 nanokvm sur mes machines rackées, c’est super utile pour mettre à jour le bios à distance, en plus les nanokvm ont un petit espace de stockage sur lequel on peut stocker le fichier du bios.
Pas besoin d’écran/clavier/souris branchés à l’arrache dans la baie.
Je m’en sert aussi pour faire du pseudo WOL sur une de mes machines, parce que ça déconne sec sans cela.
Ou plus rarement pour accéder à une machine dont le LAN est en rade.
Bref pour moi c’est un gadget indispensable.