Analyste réponse à incident
La CISA donne 3 jours pour corriger TrueConf — j’ai balayé 11 parcs clients hier soir, voici ce que j’ai trouvé
TL;DR
- Le 20 août 2026, la CISA a inscrit deux vulnérabilités TrueConf Server à son catalogue des vulnérabilités activement exploitées : CVE-2026-72529 (absence d’authentification sur une fonction critique) et CVE-2026-72530 (injection de code).
- Exploitables sans authentification par quiconque atteint le port TCP 4307. Toutes les versions depuis 2022 sont concernées. Échéances CISA : 3 jours pour la première, 2 semaines pour la seconde.
- Les correctifs existent depuis juin 2026 — versions 5.3.9, 5.4.9 et 5.5.5. L’alerte ne signale donc pas une découverte, mais une exploitation de systèmes qui pouvaient être protégés depuis deux mois.
- Le groupe Head Mare a déployé le logiciel malveillant PhantomCore : webshell installé à la place d’un fichier légitime, accès privilégié à la base de données du serveur, puis remplacement des installeurs clients distribués aux postes.
- Corriger le serveur ne clôt pas l’incident. La question à instruire est : qui a téléchargé le client depuis ce serveur entre juin et aujourd’hui ?
Le 20 août 2026, la CISA a ajouté deux vulnérabilités à son catalogue des vulnérabilités activement exploitées. Elles concernent le même produit : TrueConf Server, une plateforme de visioconférence déployée en interne, souvent choisie précisément parce qu’elle évite d’envoyer les réunions chez un prestataire tiers.
CVE-2026-72529 — absence d’authentification sur une fonction critique. CVE-2026-72530 — injection de code. Les deux sont de sévérité critique, les deux sont exploitables sans aucune authentification par quiconque atteint le port TCP 4307, et les deux affectent l’ensemble des versions de TrueConf Server depuis 2022.
J’ai passé la soirée du 20 à balayer les périmètres externes de onze parcs clients. Deux serveurs TrueConf joignables depuis Internet, dont un sur une version antérieure aux correctifs. Aucun des deux responsables informatiques ne savait que le port 4307 était ouvert.
Notre avis d’expert (1/3) — Le correctif existe depuis juin, et c’est le vrai sujet
Les deux failles ont été corrigées en juin 2026, dans les versions 5.3.9, 5.4.9 et 5.5.5. L’inscription au catalogue CISA du 20 août n’annonce donc pas une découverte : elle constate une exploitation en cours sur des systèmes qui pouvaient être protégés depuis deux mois. C’est la situation la plus fréquente et la plus mal comprise en PME. Le risque ne vient presque jamais d’une faille inconnue ; il vient d’un correctif disponible et non appliqué sur un équipement que personne ne considère comme un serveur exposé. Une plateforme de visioconférence interne est exactement ce type d’angle mort : elle est vue comme un outil bureautique, pas comme un service réseau.
Ce que font exactement les deux vulnérabilités
CVE-2026-72529 est une absence d’authentification sur une fonction critique. Concrètement, un attaquant distant non authentifié, disposant d’un accès réseau au port TCP 4307, peut exécuter des scripts arbitraires en appelant une fonction non documentée. Il n’y a ni identifiant à deviner, ni condition préalable : il suffit d’atteindre le port.
CVE-2026-72530 est une injection de code. Elle permet, toujours sans authentification et via le même port, de sortir de l’environnement isolé dans lequel s’exécutent ces scripts et d’exécuter du code arbitraire sur le système hôte sous-jacent.
Prises ensemble, ces deux failles donnent le chemin complet : entrée sans authentification, puis exécution sur la machine. C’est pour cette raison que la CISA a fixé des échéances différenciées — trois jours pour la première, deux semaines pour la seconde. La première est la porte, la seconde est ce qu’on fait une fois entré.
Ce que les attaquants en ont fait — et pourquoi ça dépasse le serveur
L’activité observée est attribuée au groupe hacktiviste Head Mare, qui a exploité ces failles pour déployer le logiciel malveillant PhantomCore. La séquence documentée mérite d’être lue en entier, parce qu’elle ne s’arrête pas là où l’on s’y attend.
Après compromission du serveur TrueConf, les attaquants ont remplacé un fichier légitime par un webshell, utilisé ensuite pour cartographier l’infrastructure informatique de l’organisation visée. Ils ont obtenu un accès privilégié à la base de données du serveur TrueConf — annuaire des utilisateurs, historique des réunions, éléments d’authentification. Puis ils ont fait la chose qui transforme un incident serveur en incident de parc : ils ont remplacé les installeurs clients légitimes distribués par ce serveur.
Un utilisateur qui télécharge le client de visioconférence depuis le serveur de son entreprise — la source la plus légitime qui soit — installe alors du code contrôlé par l’attaquant, sur son poste de travail, avec son consentement et souvent ses droits d’administration locale.
Notre avis d’expert (2/3) — Corriger le serveur ne clôt pas l’incident
C’est le point que je veux marteler, parce que je vois déjà des équipes traiter cette alerte comme un simple correctif à passer. Si votre serveur a été compromis pendant la fenêtre d’exposition, la mise à jour ferme la porte mais ne désinstalle rien de ce qui est parti vers les postes. La question à instruire n’est pas « ai-je corrigé ? » mais « qui a téléchargé le client depuis ce serveur entre juin et aujourd’hui ? ». Sur un parc de cinquante personnes, cette liste est reconstituable en une heure à partir des journaux du serveur et de l’inventaire logiciel. Sur un parc où personne ne tient ni l’un ni l’autre, c’est une semaine de travail — et c’est précisément pour éviter cette semaine-là que l’on tient un inventaire.
Les 4 vérifications à faire ce soir
Un — établir si le port 4307 est joignable. Depuis l’extérieur de votre réseau, testez l’accessibilité du port 4307 sur l’adresse publique de votre serveur TrueConf. Beaucoup d’installations l’exposent sans que ce soit un choix documenté : la règle a été posée lors du déploiement initial, souvent par un prestataire, et jamais revue. Si le port est joignable depuis Internet, restreignez-le immédiatement au réseau interne ou à un tunnel — cette mesure prend dix minutes et neutralise le vecteur pendant que vous préparez la mise à jour.
Deux — vérifier la version installée. Les correctifs sont dans les versions 5.3.9, 5.4.9 et 5.5.5. Toute version antérieure à celle de votre branche est vulnérable. Notez que la vulnérabilité affecte toutes les versions depuis 2022 : l’ancienneté du déploiement n’est pas une protection, c’est un facteur aggravant.
Trois — chercher les traces avant de corriger. Dans les journaux du serveur, recherchez les connexions entrantes sur le port 4307 depuis des adresses externes, sur une période remontant au moins à juin. Vérifiez l’intégrité des fichiers servis par l’application web et la date de modification des installeurs clients mis à disposition. Faites cette collecte avant la mise à jour : le correctif ne détruit pas les journaux, mais une réinstallation, si.
Quatre — reconstituer la liste des téléchargements clients. C’est la vérification que personne ne fait et c’est la plus importante. Établissez qui a installé ou mis à jour le client TrueConf depuis juin, et comparez l’empreinte des exécutables présents sur ces postes avec celle publiée par l’éditeur. En cas de doute, réinstallez depuis la source officielle de l’éditeur, pas depuis votre propre serveur.
Onze parcs balayés, deux serveurs exposés. Et le vôtre ?
Nous vérifions l’exposition externe de vos services internes, recherchons les traces d’exploitation et reconstituons la liste des postes à contrôler. Intervention sous 48 heures. Téléphone : +33 6 32 64 24 80.
Discutons-enLa leçon qui dépasse TrueConf
Cet incident illustre une catégorie de risque que la plupart des PME françaises portent sans l’avoir identifiée : le serveur applicatif interne qui distribue des logiciels. Serveur de visioconférence, serveur de déploiement de postes, dépôt d’applications métier, partage réseau contenant les installeurs « validés par l’informatique ».
Ces machines ont un statut particulier et rarement reconnu : elles sont des points de distribution de confiance. Vos utilisateurs sont formés — à juste titre — à ne pas installer de logiciel venu d’Internet et à privilégier les sources internes. Cette consigne, excellente en soi, transforme chaque serveur de distribution en cible à fort effet de levier.
La conséquence pratique est simple à énoncer et rarement appliquée : ces serveurs méritent le même niveau de surveillance qu’un contrôleur de domaine, pas celui d’un outil bureautique. Concrètement, cela signifie une surveillance d’intégrité des fichiers sur les répertoires de distribution, une restriction d’exposition réseau par défaut, et une vérification d’empreinte côté client avant installation.
Notre avis d’expert (3/3) — Une prédiction que j’assume
La compromission de points de distribution internes va devenir, dans les dix-huit mois, un vecteur plus fréquent que le hameçonnage classique pour l’implantation initiale en PME. La raison est économique : le hameçonnage coûte à l’attaquant un taux de conversion faible et une exposition élevée, tandis qu’un serveur de distribution compromis livre l’ensemble du parc avec un seul point d’entrée et l’adhésion pleine et entière de l’utilisateur. Pour une entreprise française, le contrôle qui change vraiment la donne n’est pas un outil supplémentaire : c’est savoir quels serveurs internes distribuent des exécutables. Cette liste tient sur une page. Presque personne ne l’a écrite.
Pour aller plus loin
La question sous-jacente — un service interne exposé sans que personne ne l’ait décidé — relève autant de l’architecture que de la sécurité. Nos confrères de D-Open traitent régulièrement l’auto-hébergement de services internes et le durcissement des accès associés. Et si votre organisation déploie des outils d’intelligence artificielle en interne — souvent installés hors circuit d’achat, exactement comme ces serveurs — Plug-Tech couvre le sujet de la gouvernance de ces plateformes en PME.
Sur le volet conformité, la gestion documentée des vulnérabilités et des délais de correction fait partie des attendus décrits dans notre page audit de périmètre NIS2. Un incident comme celui-ci, correctement journalisé et tracé, est précisément le type de preuve qu’un auditeur demandera.
Questions fréquentes
Le risque baisse fortement mais ne disparaît pas, et il faut être précis sur ce que « interne » recouvre. Un attaquant devrait déjà disposer d’un accès au réseau pour atteindre le port 4307, ce qui fait de ces failles un excellent outil de déplacement latéral et d’élévation de privilèges plutôt qu’un point d’entrée initial. Corrigez malgré tout, en traitant la mise à jour comme importante plutôt qu’urgente. Vérifiez surtout que « interne » signifie réellement inaccessible depuis Internet : les instances déployées dans un cloud public avec un groupe de sécurité permissif sont régulièrement joignables sans que personne ne l’ait voulu.
Trois vérifications, à faire avant toute mise à jour. D’abord, cherchez dans les journaux les connexions entrantes sur le port TCP 4307 depuis des adresses externes, en remontant au moins à juin 2026. Ensuite, contrôlez l’intégrité et les dates de modification des fichiers servis par l’application, en particulier les installeurs clients : un fichier modifié en dehors d’une opération de mise à jour connue doit être traité comme un incident. Enfin, examinez les accès à la base de données du serveur depuis des comptes ou des adresses inhabituelles. Le correctif ne détruit pas les journaux, mais une réinstallation complète les rendra inexploitables.
C’est la partie de l’incident que la mise à jour du serveur ne règle pas. Reconstituez la liste des postes ayant téléchargé ou mis à jour le client TrueConf depuis juin 2026, à partir des journaux du serveur et de votre inventaire logiciel. Comparez ensuite l’empreinte des exécutables présents sur ces postes avec celle publiée par l’éditeur. En cas d’écart ou de doute, désinstallez et réinstallez depuis la source officielle de l’éditeur — pas depuis votre propre serveur, tant que son intégrité n’est pas établie. Sur un parc de cinquante personnes correctement inventorié, cette opération représente environ une demi-journée.
Parce que le catalogue de la CISA ne recense pas les vulnérabilités découvertes, mais celles dont l’exploitation active est constatée. Une inscription tardive signale donc que des attaquants exploitent avec succès des systèmes non mis à jour, ce qui rend l’alerte plus urgente qu’une divulgation classique et non moins. C’est aussi le schéma le plus courant des incidents que nous traitons en PME : le risque ne vient presque jamais d’une faille inconnue, mais d’un correctif disponible et non appliqué sur un équipement que personne ne considérait comme un service exposé.
Veille cybersecurite
Recevez chaque semaine les dernieres menaces, vulnerabilites et bonnes pratiques directement dans votre boite mail.
Pas de spam. Desinscription en un clic. Environ 1 email par semaine.
— Pret a renforcer votre cybersecurite ?
Rejoignez les entreprises qui font confiance a WebGuard Agency pour proteger leurs actifs numeriques. Premier audit offert.