7 faux PoC, 2 400 installations — j’ai arrêté de tester les exploits sur ma machine, voici les 4 règles qui l’ont remplacée

Il y a une routine que presque toutes les équipes que je connais pratiquent, et que je pratiquais moi-même il y a encore quelques mois. Une vulnérabilité critique sort sur un produit que nous exploitons. Quelqu’un trouve une démonstration d’exploitation sur GitHub. On la clone, on installe les dépendances, on la lance contre une instance de test pour savoir si on est réellement concernés. Trente minutes, réponse claire, on passe à la suite.

Le 18 août 2026, des chercheurs de YesWeHack et de Sekoia ont publié l’analyse d’une campagne qui transforme précisément cette routine en vecteur d’intrusion. Elle porte le nom de ChocoPoC, et elle mérite mieux qu’un haussement d’épaules, parce que le mécanisme qu’elle exploite n’est pas une négligence : c’est une pratique professionnelle normale.

Le mécanisme : le code est propre, la dépendance ne l’est pas

La chronologie publiée commence le 25 juin 2026. L’équipe de YesWeHack reçoit un signalement concernant deux démonstrations d’exploitation associées à une vulnérabilité critique de Joomla, dans la foulée de la publication d’un gabarit de détection dédié.

Un des dépôts attire l’attention pour une raison qui n’a rien à voir avec le code de l’exploit : son fichier de dépendances requiert un paquet Python inconnu nommé frint. Ce paquet en installe à son tour un second, skytext, publié récemment sur l’index public. Le second se présente comme une bibliothèque de colorisation de terminal — un genre d’utilitaire tellement banal que personne ne le regarde deux fois.

Son contenu l’est beaucoup moins. skytext distribue des extensions compilées pour Linux et pour Windows, avec du code obfusqué, de l’exploration du bloc d’environnement de processus, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Autrement dit, un empaquetage de logiciel malveillant classique, dissimulé derrière un nom rassurant, à deux niveaux de profondeur d’une dépendance que vous n’avez jamais choisie.

Le point qui compte est celui-ci, et il est répété par les auteurs de l’analyse : le code visible reste crédible. On peut lire l’exploit, le trouver plausible, vérifier qu’il correspond à la description de la vulnérabilité, et se faire compromettre quand même. La revue de code manuelle, qui est le réflexe défensif de tout le monde, ne voit rien parce qu’elle ne regarde pas au bon endroit.

ChocoPoC illustre une évolution préoccupante : le code visible peut rester crédible pendant que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en surface d’attaque réelle.

Sept appâts, choisis pour maximiser l’urgence

Les sept dépôts malveillants recensés exploitaient des vulnérabilités affectant FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Regardez cette liste comme un ciblage marketing plutôt que comme un hasard. Ce sont des pare-feux, des passerelles d’accès distant, des bases de données et un composant applicatif très déployé. Quand une vulnérabilité critique touche l’un d’eux, des centaines d’équipes basculent simultanément en mode urgence, avec la même question et la même contrainte de temps. C’est exactement la fenêtre où le fichier de dépendances n’est pas lu.

L’analyse remonte par ailleurs l’activité à fin 2025, avec une première vague utilisant les paquets slogsec et logcrypt.cryptography. Ce n’est donc pas un coup isolé mais une opération entretenue sur au moins trois trimestres, avec renouvellement des paquets porteurs quand les précédents sont brûlés.

Pourquoi le navigateur, et pas le code source

La charge finale exfiltre les identifiants, les témoins de connexion et l’historique de navigation depuis Chrome, Brave, Edge et Firefox. La commande et le contrôle passent par une interface cartographique publique utilisée comme boîte aux lettres morte, avec un tunnel DNS chiffré pour dissimuler les échanges.

Beaucoup de développeurs s’étonnent que la campagne ne cherche pas d’abord le code source ou les clés privées. C’est un raisonnement de 2019. Sur le poste d’un ingénieur en 2026, le navigateur contient les sessions ouvertes vers la forge logicielle, la console d’hébergement, le gestionnaire de tickets et le fournisseur d’identité. Voler une session vaut mieux que voler un mot de passe pour une raison simple et décisive : elle contourne l’authentification à plusieurs facteurs.

Une clé SSH volée est révocable et son usage laisse une trace identifiable. Une session de navigateur volée permet d’agir en votre nom, depuis un navigateur qui ressemble au vôtre, sans redemander le second facteur. C’est un actif supérieur, et les opérateurs de cette campagne l’ont compris avant beaucoup d’équipes défensives.

Les 4 règles qui ont remplacé notre ancienne routine

Nous avons revu notre procédure de reproduction de vulnérabilités la semaine dernière. Quatre règles, aucune n’est technique au point de demander un projet.

1. Aucune reproduction sur une machine qui possède des identifiants

C’est la règle qui règle l’essentiel du problème et elle ne coûte rien. Machine virtuelle jetable ou conteneur, sans montage du répertoire personnel, sans profil de navigateur, sans agent de clés, sans jeton d’accès à la forge, sans variable d’environnement de production. Détruite après usage.

La contrainte réelle n’est pas technique, elle est ergonomique : si créer cet environnement demande plus de deux minutes, personne ne le fera sous pression. Investissez une demi-journée à en faire une image prête à démarrer, et le respect de la règle devient automatique.

2. Lire le fichier de dépendances avant tout le reste

Inversion de l’ordre de lecture habituel. Avant d’ouvrir le code de l’exploit, ouvrez requirements.txt, pyproject.toml ou l’équivalent, et posez une question par ligne : est-ce que je connais ce paquet ?

Un exploit légitime pour une vulnérabilité réseau a besoin d’une bibliothèque de requêtes HTTP et parfois d’un analyseur syntaxique. Il n’a besoin ni d’un utilitaire de colorisation de terminal, ni d’un paquet dont vous n’avez jamais entendu parler. Cette anomalie était visible dans le cas décrit, à condition de regarder au bon endroit.

3. Vérifier l’ancienneté et l’adoption du paquet sur l’index public

Deux chiffres, trente secondes : la date de première publication et le nombre de versions. Un paquet créé il y a trois semaines, avec deux versions, requis par un exploit publié il y a trois jours, est une anomalie suffisante pour s’arrêter — même sans preuve de malveillance.

Cette heuristique produit des faux positifs, et c’est acceptable : le coût d’un faux positif est de trois minutes de vérification, le coût d’un faux négatif est la compromission de votre chaîne de production. Le même raisonnement s’applique à l’ensemble de vos dépendances, sujet que nous avons détaillé dans notre méthode auditer ses dépendances Python en 7 étapes.

4. Installer depuis un miroir interne, jamais depuis l’index public en direct

La règle la plus structurante et la seule qui demande un vrai chantier. Un miroir interne avec liste d’autorisation coupe le vecteur à la racine : un paquet inconnu n’est pas résolu, l’installation échoue franchement, un humain décide.

Comptez trois à cinq jours-homme de mise en place pour une équipe de taille moyenne, et une charge d’exploitation faible ensuite. C’est le seul des quatre points qui protège aussi contre les campagnes que personne n’a encore documentées.

Ce que cette campagne dit du reste de votre chaîne

Le réflexe après ce genre de publication est de chercher les indicateurs de compromission et de vérifier qu’on n’a pas installé les paquets cités. C’est nécessaire et très insuffisant. Les noms changeront la semaine prochaine ; le mécanisme, lui, restera valide tant que l’urgence l’emportera sur la lecture.

La question à se poser n’est pas « ai-je installé skytext ». Elle est : combien de paquets ont été installés sur mes postes de développement au cours des six derniers mois sans qu’aucun humain n’ait lu leur nom ? Sur les équipes que nous auditons, la réponse se compte en centaines, et la proportion de dépendances transitives dépasse systématiquement 90 %.

Le volet gouvernance de ce sujet — journalisation des accès, cloisonnement des postes, révocation de sessions — relève de la cybersécurité d’entreprise, que nos confrères de WebGuard Agency traitent en détail. Et si votre chaîne d’installation alimente désormais des agents d’intelligence artificielle qui installent eux-mêmes des dépendances, le sujet se déplace encore : les équipes de Plug-Tech documentent régulièrement ce périmètre.

Pour la mise en place concrète d’un environnement cloisonné, notre guide configurer un environnement Python Docker sécurisé en 7 étapes détaille les arbitrages entre machine virtuelle et conteneur, et créer une plateforme freelance montre à quoi ressemble la même discipline appliquée à un produit complet.

Questions fréquentes