EN
en direct
Sécurité Critique

Red Heron transforme la faille Gitea en campagne d’espionnage industriel et déploie un rootkit Linux inédit

Un acteur sinophone traqué sous le nom de Red Heron a exploité CVE-2026-60004, la faille Gitea, pour scanner 1 386 instances dans sept pays et dérober le code source d’industriels. Patchez vos forges auto-hébergées, restreignez l’inscription et traitez toute instance exposée comme déjà compromise.

Un mur de classeurs métalliques sombres et identiques, un seul tiroir entrouvert laissant dépasser des dossiers faiblement éclairés d’ambre.

15 septembre 2026. L’unité de recherche sur les menaces d’Acronis publie le détail d’une campagne qu’elle attribue, avec une confiance modérée, à un acteur sinophone nommé Red Heron. CVE-2026-60004. La faille Gitea corrigée fin juillet et déjà exploitée à grande échelle devient la porte d’entrée d’une opération d’espionnage ciblé. 1 386 instances scannées, 11 victimes confirmées dans 5 pays. Pourquoi c’est important : un exploit public, quelques jours suffisent à le transformer en campagne structurée de vol de code source industriel — et la forge auto-hébergée en est le point d’entrée.

D’un cryptomineur opportuniste à un acteur d’État

La faille CVE-2026-60004 n’est pas nouvelle pour ce blog : nous l’avons couverte en août, au moment où un scanner automatisé en profitait pour déposer un cryptomineur en 11 secondes sur des instances mal configurées. La faille touche le point de terminaison diffpatch de Gitea : un attaquant disposant d’un accès en écriture à un dépôt peut y installer puis exécuter un hook Git contrôlé, et donc des commandes shell arbitraires comme utilisateur système de la forge. Avec l’inscription ouverte, la faille devient pré-authentification.

Ce que montre Red Heron, c’est le passage à l’échelle industrielle. L’acteur a construit un cadre d’exploitation automatisé qui enregistre des comptes, compromet les serveurs Gitea vulnérables, vole les dépôts puis efface les traces choisies. La campagne a scanné 1 386 instances dans 7 pays et tenait une base séparée de 477 systèmes taïwanais. Les cibles étaient classées par secteurs : défense, élections, énergie, aérospatial, télécoms, gouvernement et recherche. L’outillage — un proof of concept de GitHub forkéd, le framework de commande et contrôle Adaptix, et le scanner FOFA — est entièrement public et open source.

Le rootkit SIXZUT, l’élément nouveau

L’élément le plus notable de la campagne n’est pas la faille elle-même, mais l’implant découvert derrière. Acronis a mis au jour JITTERLY, un implant qui supporte plus de 30 commandes post-exploitation — exécution de shell, transfert de fichiers, tunneling réseau et pivot interne — et, surtout, SIXZUT, un rootkit Linux jusqu’ici non documenté, embarqué dans JITTERLY.

SIXZUT fait trois choses qui le rendent dangereux pour la défense : il masque les fichiers, les processus et les connexions réseau de l’implant, il protège l’implant contre la terminaison, et il le relance s’il est arrêté. C’est la différence entre une compromission que l’on nettoie en redémarrant et une compromission qui survit au redémarrage. Pour une équipe qui penserait s’en sortir en isolant puis réinstallant la machine, un rootkit de ce type change le calcul : il faut reflasher et traiter la machine comme irrécupérable.

La forge comme coffre-fort du code source

Le bilan des victimes raconte pourquoi une forge auto-hébergée est une cible de choix. La victime la plus gravement compromise est une entreprise canadienne d’énergie renouvelable : 22 sessions d’exploitation distinctes, et non un simple vol de dépôts. Red Heron y a cartographié toute l’infrastructure, identifié le compte d’un employé légitime et exfiltré l’intégralité de la pile applicative — RH, CRM, service d’authentification, intranet, rapports internes et API métier. Les secrets de configuration, dont des jetons JWT, des jetons internes et des clés d’hôte SSH, ont été extraits du fichier de configuration de Gitea ; une clé de déploiement liée à l’environnement de préproduction HCM a aussi été exposée.

L’autre victime emblématique est une entreprise taïwanaise d’automatisation industrielle, à qui Red Heron a dérobé des centaines de dépôts : un produit de surveillance et de supervision, un outil SCADA/HMI utilisé en environnement de contrôle industriel, des intégrations IoT, un sniffer réseau, des configurations de serveurs et des applications métier internes. Sur ce seul hôte, Acronis a compté plus de 130 répertoires poc-* résiduels — autant d’exécutions de la chaîne d’exploitation, dont le nettoyage a échoué. Une cible au Qatar a également vu partir une plateforme de gestion de l’apprentissage, un chatbot d’IA et des outils d’automatisation.

L’attribution, et ce qu’elle change

L’attribution à Red Heron repose sur un faisceau d’indices, pas sur une certitude : artefacts en chinois simplifié, méthodologie de ciblage, victimologie et savoir-faire observé. Les bases de reconnaissance, les classifications de cibles et les métadonnées de scan FOFA récupérées sur le serveur de préparation étaient entièrement rédigées en chinois simplifié. Un détail retient l’attention : Taïwan y était systématiquement codée comme pays « CN » et région « TW », traitée comme une région de la Chine plutôt que comme un pays distinct. Une liste de 477 instances taïwanaises portait le champ source: Given authorized website, suggérant qu’elle avait été fournie de l’extérieur, et un script exec[dot]sh transférant les données volées depuis le serveur de préparation laisse penser à une opération menée en équipe plutôt qu’en solitaire.

Le profil des cibles — élections, défense, énergie, aérospatial — signale une priorité de collecte délibérée derrière un balayage plus opportuniste. C’est la signature d’une opération de renseignement, pas d’un rançonneur ni d’un mineur.

Ce que l’opérateur doit faire

La leçon dépasse Gitea. Une forge auto-hébergée — Gitea, Forgejo, GitLab — concentre le code source, les secrets, les identifiants de déploiement et, souvent, un accès aux environnements connectés. Une compromission initiale de la forge se transforme vite en brèche d’infrastructure complète, comme le montre la victime canadienne.

Trois actions priment. Patcher immédiatement : la version corrigée de Gitea existe depuis fin juillet, et toute instance encore vulnérable est une cible déclarée. Restreindre l’inscription : c’est l’inscription ouverte qui transforme une faille post-authentification en accès non authentifié — désactivez-la ou imposez confirmation d’e-mail et approbation manuelle. Traiter comme compromise : avec un rootkit capable de masquer processus et connexions, l’hypothèse de travail doit être que l’instance exposée est déjà percée, ce qui implique rotation des secrets, inspection des journaux et reconstruction des hôtes suspects.

Détecter un rootkit qui masque ses traces

SIXZUT ne se détecte pas avec les outils de l’hôte, par définition : un rootkit qui masque les fichiers, les processus et les connexions trompe aussi les commandes locales comme ps, ls ou ss. La vérification doit donc passer par l’extérieur. Trois angles donnent les meilleurs résultats. D’abord, comparer l’hôte vu de l’extérieur : interroger la machine depuis un autre système — scan réseau, ou agent de supervision déployé avant l’incident — pour repérer des processus ou des sockets ouverts invisibles localement. Ensuite, analyser le trafic réseau au niveau de la passerelle ou d’un miroir de port, où les connexions de l’implant vers son C2 apparaissent même si l’hôte les cache. Enfin, la mémoire et l’intégrité : un dump mémoire ou une vérification d’intégrité des binaires système, comparés à une référence propre, peuvent révéler les hooks et les binaires altérés.

Le plus simple reste toutefois de ne pas avoir à détecter : face à une instance Gitea exposée et vulnérable, le coût d’une reconstruction propre est souvent inférieur à celui d’une analyse forensique incertaine. La rotation des secrets — jetons JWT, clés SSH, clés de déploiement — reste obligatoire dans tous les cas, car ces éléments ont pu être exfiltrés avant même l’installation du rootkit.

Verdict

Red Heron est la démonstration la plus claire, en 2026, qu’un exploit public devient une campagne d’État en quelques jours quand la cible est une forge auto-hébergée mal tenue.

Si vous exploitez une forge exposée sur Internet, la mise à jour n’est pas optionnelle : elle est en retard d’un mois et l’adversaire scanne activement. Si vous avez laissé l’inscription ouverte, fermez-la avant toute autre action — c’est elle qui fait toute la différence entre un vol de dépôts et un simple scan. Si vous gérez des dépôts industriels ou sensibles, traitez la forge comme une cible prioritaire et prévoyez un plan de rotation des secrets qui ne dépend pas d’une machine déjà compromise.

Références

cve

Vulnérabilités liées

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Cisco Secure Email Gateway corrige CVE-2026-76461, un zero-day exploité pour exécuter des commandes en root

Un zero-day CVE-2026-76461 (CVSS 9.8) dans l’analyse des e-mails d’AsyncOS est exploité depuis septembre 2026 pour transformer une injection SQL en exécution de commandes root. Cisco ne propose aucun contournement et la CISA exige une correction avant le 17 septembre 2026 : mettez à jour vos appliances Secure Email Gateway sans attendre.

Chrome 153 corrige CVE-2026-87491, le septième zero-day V8 exploité de 2026

Le 8 septembre 2026, Google publie Chrome 153, qui corrige 230 vulnérabilités dont CVE-2026-87491, une écriture hors limites dans le moteur V8 déjà exploitée dans la nature. Mettez à jour vers 153.0.8010.36 ou supérieur avant l’échéance CISA du 23 septembre et vérifiez tous les navigateurs Chromium de votre parc, Edge, Brave et Opera compris.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer