Trois voies d’exécution révèlent des failles de confiance dans Zammad, MagicINFO et Unsloth Studio

De récentes découvertes en matière de sécurité montrent comment des opérations en apparence courantes peuvent ouvrir la voie à de graves compromissions. Les cas examinés concernent des sessions sur une plateforme d’assistance, l’écriture arbitraire de fichiers sur un serveur d’affichage dynamique et l’inspection de métadonnées dans un outil de développement d’IA.

Des acteurs malveillants auraient exploité deux vulnérabilités de Zammad pour s’introduire dans les systèmes du Dutch Institute for Vulnerability Disclosure (DIVD), obtenir les privilèges root et exfiltrer des données. Le DIVD attribue la rapidité de l’intrusion et le mode de prise de décision observé à un agent apparemment assisté par l’IA.

Dans un autre incident, Huntress a attribué une compromission à l’exploitation d’une faille du serveur Samsung MagicINFO 9, déjà répertoriée dans le catalogue des vulnérabilités exploitées connues de la CISA. L’attaquant a installé AnyDesk, affaibli les protections des terminaux, créé un compte administrateur et compilé un mineur de cryptomonnaie sur le système victime.

Un troisième problème touchait Unsloth Studio. La simple sélection d’un modèle Hugging Face pouvait entraîner l’exécution de code Python contrôlé par le dépôt lors de son inspection, avant même le chargement des poids ou le démarrage de l’inférence.

Deux failles de Zammad ont permis de passer de sessions détournées à un accès root

Selon The Hacker News, des acteurs malveillants ont compromis le DIVD en combinant CVE-2026-102489 et CVE-2026-102490.

La première vulnérabilité concerne les versions de Zammad allant de 6.3.0 à 6.5.4. Elle permet le détournement de sessions, qui peut déboucher sur l’exécution de code à distance sous le compte local zammad.

Cette vulnérabilité est également présente dans les versions 7.0.0 à 7.1.3. Toutefois, la description du NVD précise que des conditions environnementales empêchent son exploitation sur toute cette plage de versions.

La seconde faille permet de compléter la chaîne d’élévation de privilèges. CVE-2026-102490 concerne toutes les versions de Zammad, y compris la dernière version alpha, et permet à un utilisateur local zammad d’obtenir les privilèges root.

Le DIVD a indiqué que les attaquants avaient combiné les deux vulnérabilités pour détourner des sessions, exécuter du code et obtenir un accès de niveau root. Après avoir compromis le système Zammad, ils ont accédé à d’autres services, où ils ont consulté et exfiltré des données. Parmi les informations concernées figuraient des données sur les utilisateurs bénévoles, notamment des adresses e-mail du DIVD et, éventuellement, d’autres coordonnées.

Cette séquence est importante pour délimiter le périmètre de l’incident. La compromission ne s’est pas arrêtée au serveur applicatif initial : une enquête limitée aux journaux Zammad ou aux modifications du système de fichiers pourrait donc passer à côté des accès ultérieurs aux services connectés.

Le DIVD a décrit l’opération comme automatisée et apparemment assistée par l’IA. D’après son récit, l’agent choisissait une nouvelle action à chaque étape et agissait rapidement, mais son comportement était aussi erratique. Le DIVD a signalé que l’attaquant avait perturbé sa propre opération de type « man-in-the-middle » en y introduisant du password spraying.

Cette description correspond à l’évaluation du DIVD au vu des comportements observés. Elle ne permet pas de tirer des conclusions sur le modèle, l’opérateur ou le cadre d’automatisation utilisés, aucun de ces éléments n’étant établi par le récit cité.

MagicINFO : le path traversal a ouvert la voie à un accès distant et au cryptominage

Huntress a signalé une autre compromission, qui a débuté par l’exploitation de CVE-2025-4632, une vulnérabilité de path traversal dans Samsung Electronics MagicINFO 9 Server.

La faille concerne les versions antérieures à 21.1052.0. Le tableau des produits concernés du NVD indique une plage allant de la version 0 à toute version inférieure à 21.1052, tandis que la configuration associée définit comme vulnérables toutes les versions antérieures à 21.1052.0.

La faiblesse sous-jacente est CWE-22 : restriction inadéquate d’un chemin d’accès à un répertoire autorisé. Un attaquant peut exploiter cette vulnérabilité pour écrire un fichier arbitraire avec les privilèges système.

CVE-2025-4632 affiche un score CVSS 3.1 de 9.8, niveau critique, attribué aussi bien par le NVD que par Samsung TV & Appliance. Son vecteur est le suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Ces métriques décrivent une attaque accessible par le réseau, de faible complexité, qui ne nécessite ni privilèges préalables ni interaction de l’utilisateur. Une exploitation réussie peut avoir un impact élevé sur la confidentialité, l’intégrité et la disponibilité.

Dans l’incident décrit par Huntress, l’attaquant a effectué trois tentatives avant de déployer une instance malveillante d’AnyDesk. L’opérateur a ensuite créé un nouveau compte administrateur local, désactivé les protections de Defender et compilé un logiciel de minage de cryptomonnaie directement sur le terminal compromis.

La compilation locale est un élément important sur le plan opérationnel. Une détection centrée uniquement sur les binaires de minage connus risque de passer à côté de signes précurseurs, comme des téléchargements répétés de logiciels de gestion à distance, une activité de compilation inhabituelle, la création non autorisée d’un compte administrateur ou des modifications des paramètres de Defender.

La notice du NVD consacrée à CVE-2025-4632 a été publiée le 13 mai 2025 et mise à jour pour la dernière fois le 17 juin 2026. Elle renvoie à la section des mises à jour de sécurité de Samsung, SVP-MAY-2025.

La CISA a ajouté la vulnérabilité à son catalogue des vulnérabilités exploitées connues le 22 mai 2025. Les agences fédérales américaines devaient y remédier avant le 12 juin 2025.

La consigne de la CISA est explicite : appliquer les mesures d’atténuation conformément aux instructions du fournisseur, suivre les recommandations applicables de la BOD 22-01 pour les services cloud ou cesser d’utiliser le produit si aucune mesure d’atténuation n’est disponible. Son inscription au catalogue KEV, conjuguée aux conclusions de Huntress sur l’incident, confirme que les défenseurs sont confrontés à une surface d’attaque effectivement exploitée, et non à une faille purement théorique.

Unsloth Studio exécutait du code lors de l’inspection des métadonnées d’un modèle

Pillar Security a mis au jour une autre défaillance de la frontière de confiance dans Unsloth Studio, qui fait partie d’une bibliothèque open source utilisée pour affiner et quantifier de grands modèles de langage.

Le problème se situait dans le processus de sélection des modèles. Le choix d’un modèle dans l’interface pouvait amener le composant backend à télécharger et à exécuter du code Python présent dans le dépôt Hugging Face de ce modèle.

Aucune inférence n’était nécessaire. Le composant backend n’avait pas non plus besoin de charger les poids du modèle.

La simple lecture du fichier config.json dans le cadre d’une vérification des métadonnées suffisait à déclencher l’exécution. L’inspection d’un modèle pouvait donc entraîner l’exécution de code, alors que les utilisateurs pouvaient raisonnablement considérer cette opération comme une simple consultation des métadonnées du dépôt.

Le code injecté s’exécutait avec les privilèges du compte qui utilisait Unsloth Studio. Selon les permissions de ce compte et son environnement, un attaquant pouvait accéder à des données d’entraînement propriétaires, à des artefacts de modèles, à des jetons Hugging Face, à des clés SSH ou à des identifiants cloud.

Pillar a également relevé d’autres conséquences possibles, comme la modification de modèles ou de résultats d’entraînement, ainsi que l’utilisation d’identifiants accessibles pour pénétrer dans d’autres systèmes. L’impact dépend des ressources auxquelles le processus concerné peut accéder.

Le problème a été corrigé dans Unsloth version 2026.6.9, publiée le 18 juin 2026. Aucun identifiant CVE ni niveau de gravité n’est établi dans les informations citées.

Les organisations utilisant Unsloth Studio devraient vérifier que leurs déploiements ont été mis à jour vers la version corrigée. Elles devraient également limiter les identifiants et les données sensibles auxquels le processus Studio peut accéder, puisque le code fourni par un dépôt s’exécute dans le contexte de sécurité de cet utilisateur.

Les défenseurs doivent enquêter sur toute la chaîne d’exécution

Chacun de ces cas met en évidence une séquence distincte de comportements observables.

Pour Zammad, les défenseurs devraient examiner les anomalies de session, mais aussi l’exécution de code sous le compte zammad, l’élévation de privilèges vers root et les accès ultérieurs à d’autres services. Le DIVD ayant signalé une exfiltration de données, les vérifications ne devraient pas se limiter aux traces de l’exécution initiale du code.

Les administrateurs de MagicINFO devraient d’abord repérer les déploiements antérieurs à 21.1052.0 et suivre les recommandations de Samsung. Les systèmes exposés alors qu’ils étaient vulnérables doivent faire l’objet d’une enquête portant sur la création de fichiers inattendus, l’installation d’AnyDesk, les téléchargements répétés d’outils de gestion à distance, la création de nouveaux comptes administrateur locaux, les modifications de la configuration de Defender et les processus de compilation inexpliqués.

Le mineur peut n’être que la dernière étape de l’attaque, et non le meilleur point de détection.

Unsloth Studio nécessite un autre modèle de contrôle. Les dépôts de modèles doivent être considérés comme des sources d’entrées potentiellement exécutables, et non comme de simples ensembles de poids et de fichiers de configuration. Limiter l’accès du processus Studio aux secrets, aux ressources d’entraînement, aux clés SSH et aux identifiants cloud permet de réduire l’impact de l’exécution de code contrôlé par un dépôt.

D’autres travaux de recherche mettent en évidence le même problème de frontière de confiance

Plusieurs évolutions connexes montrent comment une donnée peut devenir une instruction lorsque le logiciel lui accorde une autorité qu’elle ne devrait pas avoir.

Chainalysis a décrit EtherHiding, une forme de Blockchain Dead Drop qui stocke des instructions malveillantes sur des blockchains publiques. Une telle infrastructure est plus difficile à saisir ou à supprimer qu’un serveur classique contrôlé par un attaquant. Chainalysis a indiqué que des acteurs étatiques nord-coréens et iraniens développaient des techniques distinctes et fait état d’une hausse de 440 % de l’activité BDD depuis le lancement de modèles d’IA open source chinois à grande capacité, dépourvus de restrictions sur le code malveillant. Cette concomitance ne suffit pas à établir un lien de causalité.

YesWeHack a détaillé l’injection de clé de cache : une vulnérabilité qui survient lorsque des applications concatènent des valeurs contrôlées par un attaquant sans séparateurs clairs. Deux requêtes HTTP différentes peuvent alors générer la même clé de cache. Selon le point de terminaison et l’architecture de mise en cache, une collision peut permettre une tromperie du cache, la divulgation de réponses restreintes, un déni de service ou, dans des conditions plus spécifiques, du cross-site scripting stocké.

Tracebit a étudié l’injection indirecte de prompt comme mécanisme défensif au moyen de Context Bombs. Dans son test, des instructions conçues à cet effet étaient intégrées à un secret leurre dans AWS Secrets Manager. Des délimiteurs de conversation et un faux message utilisateur visaient à convaincre un agent chargé de l’exploration que son opérateur lui avait ordonné de s’arrêter.

Dans tous ces cas, le problème fondamental dépasse une seule catégorie de produits. Des sessions deviennent des points d’entrée pour l’exécution de code, des chemins de fichiers se transforment en mécanismes d’écriture privilégiés, des métadonnées deviennent du code Python et du contenu mis en cache ou récupéré se transforme en instruction opérationnelle. Les défenseurs doivent donc examiner non seulement ce que les systèmes traitent, mais aussi les pouvoirs qu’ils leur accordent pendant ce traitement.