L'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté le 9 novembre quatre vulnérabilités à son catalogue des vulnérabilités connues et exploitées (KEV), en s'appuyant sur des preuves d'exploitation active. Les failles touchent GPUStack, SignalWire FreeSwitch, OpenBSD OpenSSH et IBM Aspera Faspex, et exposent les organisations qui utilisent des déploiements vulnérables à un risque d'accès non autorisé, d'exécution de commandes ou d'élévation de privilèges.
L'alerte de la CISA fixe ces priorités de remédiation pour les organisations concernées. Des comptes rendus techniques publics décrivent des attaques contre OpenSSH sous Linux et contre GPUStack, tandis que l'avis de l'éditeur de FreeSWITCH confirme également une exploitation dans la nature.
Les quatre ajouts au catalogue sont les suivants :
- CVE-2026-102895, GPUStack : authentification incorrecte permettant un accès administrateur sans identifiants. L'éditeur indique que les versions antérieures à 2.2.0 sont affectées et recommande la version 2.2.0 ou ultérieure.
- CVE-2026-116779, SignalWire FreeSwitch : injection de code pouvant exposer la configuration et les identifiants, donner aux attaquants le contrôle des appels et permettre l'exécution de commandes.
- CVE-2026-123158, OpenBSD OpenSSH : faille liée à un code d'état ou une valeur de retour inattendus, connue sous le nom de SSHole, qui peut contourner l'authentification sous Linux.
- CVE-2026-123218, IBM Aspera Faspex : autorisation incorrecte permettant à un utilisateur authentifié d'envoyer un message spécialement conçu et d'élever ses privilèges.
The Hacker News fait état de scores de gravité CVSS de 9,8 pour les failles GPUStack, FreeSwitch et Faspex, et de 8,1 pour SSHole. Il date respectivement leurs correctifs de juillet, octobre, novembre et novembre 2026.
Les attaques contre OpenSSH incluent des tentatives de maintien d'accès
The Hacker News indique que Previdian a recensé 22 tentatives d'exploitation de SSHole provenant de 14 adresses IP uniques, remontant au 6 novembre. Dans un message publié le 7 novembre, Defused Cyber a indiqué avoir observé un petit nombre d'acteurs ciblant cette faille, et que l'activité n'était pas encore généralisée.
GreyNoise situe la première tentative contre son réseau de pots de miel, des systèmes utilisés pour observer les attaques, à 00 h 46 UTC le 7 novembre. L'entreprise a signalé une activité confirmée après exploitation, provenant de six adresses IP sources et représentant 18 chaînes d'attaque distinctes.
Ces chaînes comprenaient de la reconnaissance, des requêtes vers les services de métadonnées cloud, des tentatives de lecture des hachages de mots de passe et des clés SSH root, ainsi que des efforts pour modifier le fichier authorized_keys afin de conserver l'accès. Dans au moins un cas, les attaquants ont déployé TAC Agent, un programme Python de commande et contrôle capable d'exécuter des commandes shell, de collecter des informations système, de lister des répertoires, de transférer des fichiers et de se mettre à jour.
Le rapport cite également des observations de watchTowr sur l'exploitation de SSHole à des fins de botnet et de minage de cryptomonnaies.
GPUStack peut prendre un trafic distant pour un administrateur local
L'avis de GPUStack décrit un défaut de confiance dans get_current_user, dans gpustack/api/auth.py. Avant la version 2.2.0, les requêtes considérées comme provenant de la boucle locale (loopback), c'est-à-dire de l'adresse réseau locale de l'hôte lui-même, recevaient automatiquement l'identité d'administrateur intégrée lorsque force_auth_localhost valait False, sa valeur par défaut.
Deux chemins pouvaient déclencher ce comportement. Dans un déploiement auto-hébergé classique, avec un reverse proxy sur la même machine redirigeant vers 127.0.0.1, les requêtes distantes arrivaient à GPUStack avec une adresse de socket locale. Aucun identifiant ni en-tête forgé n'était nécessaire. L'avis indique que ce chemin a été vérifié de bout en bout sur le commit HEAD 6bee5883. Sinon, un attaquant pouvait fournir X-GPUStack-Real-IP: 127.0.0.1 pour faire paraître une requête locale.
Cet accès permettait aux attaquants de consulter et de modifier les utilisateurs, les modèles, les workers et la configuration ; de lire les identifiants des workers et les secrets des fournisseurs cloud ; et de créer des clés API administrateur persistantes avec la portée ["*"], utilisables ensuite depuis n'importe quelle adresse IP source. Des fonctionnalités d'administration, dont POST /v2/inference-backends/from-yaml, pouvaient ensuite exécuter du code sur les hôtes workers.
Les mainteneurs signalent une exploitation sur un déploiement en version 2.1.1, où des backends personnalisés créés par les attaquants ont exécuté des reverse shells, donnant un accès distant aux commandes. Ils remercient pour leurs signalements indépendants Nikko Enggaliano, Wei Yunzhou, ainsi que Rui Yang et Haoyu Wang, de l'université Johns Hopkins. L'exploitation active a été signalée par Javier Sixto, d'Ulex Innovative Systems. The Hacker News date l'avis au 31 juillet.
Les messages de chat FreeSWITCH peuvent atteindre les interfaces de commande
L'avis FreeSWITCH explique que sofia_presence_handle_sip_i_message() découpe l'utilisateur de destination d'un message SIP MESSAGE entrant au niveau du +, en considérant la partie gauche comme un sélecteur de protocole de chat. SIP est un protocole de signalisation utilisé par les systèmes de communication pour établir les appels.
Le module mod_dptools enregistre une interface de chat api qui transmet son adresse à switch_api_execute(). Un correspondant capable de faire accepter un message MESSAGE peut donc sélectionner une commande API de FreeSWITCH. Les commandes s'exécutent avec les privilèges du processus FreeSWITCH, ce qui permet l'exécution de commandes du système d'exploitation, la divulgation d'identifiants et de configuration, et un contrôle complet des appels. Lorsque mod_lua est chargé, comme dans la configuration par défaut, le code Lua inline peut aussi accéder à la bibliothèque standard complète.
Le chat entrant est activé, sauf si un profil définit enable-chat=false ; les profils internal et external par défaut le laissent activé. Durcir la liste de contrôle d'accès entrante ne supprime pas l'exposition, car cette liste ne couvre pas le trafic MESSAGE.
Lorsque l'authentification MESSAGE est appliquée, un seul compte ordinaire disposant de la permission d'enregistrement suffit. Certaines configurations par défaut permettent aussi d'accéder sans compte détenu par l'attaquant : conf/vanilla/directory/default/default.xml définit un utilisateur default sans password ni a1-hash, qui s'authentifie, sauf si allow-empty-password vaut false pour cet utilisateur.
Le correctif introduit un paramètre enable-chat-api-proto par profil, désactivé sauf activation explicite. Les tentatives bloquées de sélectionner api reçoivent une réponse 403 et génèrent un journal contenant la source et la commande demandée. La vérification est insensible à la casse ; les messages sans sélecteur ou utilisant d'autres protocoles de chat conservent leur routage. Le paramètre est livré commenté dans les profils vanilla et dans l'exemple mod_sofia. L'avis crédite Örn Arnarson et Gunnlaugur.
Ce que doivent faire les administrateurs
Les administrateurs GPUStack doivent passer à la version 2.2.0 ou ultérieure, qui supprime l'accès administrateur automatique via la boucle locale et renforce la gestion des adresses clientes. Les contournements proposés par les mainteneurs consistent à définir force_auth_localhost=true, à empêcher les proxys de présenter des requêtes externes comme provenant de la boucle locale, à supprimer en périphérie les en-têtes X-GPUStack-Real-IP fournis par le client, et à restreindre l'accès à l'API par un VPN ou une authentification en périphérie.
Les administrateurs FreeSWITCH doivent appliquer le correctif de l'éditeur ou définir enable-chat=false sur chaque profil qui n'a pas besoin du chat SIP entrant. Ce contournement désactive toute remise de messages de chat MESSAGE entrants sur ces profils.
L'authentification seule ne ferme pas le chemin de commande de FreeSWITCH. L'authentification MESSAGE est activée par défaut depuis la version 1.10.7. Combinée à la suppression de tous les utilisateurs de l'annuaire qui ne possèdent aucun des deux champs de mot de passe, y compris les utilisateurs d'exemple default et Skinny fournis par défaut, elle ne fait que réduire l'exposition à l'exécution de commandes par des utilisateurs authentifiés. De même, disable_system_api_commands=true supprime l'API system, mais laisse accessibles d'autres API, dont le chargement de modules et l'initiation d'appels.
Pour les agences civiles du pouvoir exécutif fédéral américain, la directive opérationnelle contraignante 26-04 de la CISA impose de hiérarchiser rapidement les failles KEV affectant des actifs exposés publiquement lorsque leur exploitation confère un contrôle total. Elle fixe également des attentes concernant la vérification d'une éventuelle compromission antérieure au correctif. The Hacker News fait état d'une date limite de remédiation au 12 novembre pour ces ajouts ; cette date concerne les agences civiles fédérales. La CISA encourage les autres organisations à prioriser la remédiation des failles KEV dans le cadre d'une gestion des vulnérabilités fondée sur les risques.
