Red Heron exploite une vulnérabilité RCE critique de Gitea et compromet 13 organisations

Un acteur soupçonné d’être lié à la Chine, suivi sous le nom de Red Heron, a exploité une vulnérabilité critique de Gitea pour compromettre des plateformes de développement, dérober des dépôts, récupérer des identifiants et pénétrer dans des infrastructures connectées.

L’Acronis Threat Research Unit a identifié 13 compromissions organisationnelles confirmées au Canada, en Argentine, à Taïwan, aux États-Unis, au Qatar et au Sri Lanka. Les cibles appartenaient notamment aux secteurs de la défense, des élections, de l’énergie, de l’aérospatiale, des télécommunications, de l’administration, de la sécurité civile et de la recherche.

La campagne est allée bien au-delà du simple vol de code source. Dans un environnement taïwanais, Red Heron a obtenu un contrôle administratif de niveau root sur un cluster Proxmox à trois nœuds après avoir pénétré par l’intermédiaire d’un serveur Gitea vulnérable.

Red Heron a combiné balayage massif et ciblage stratégique

Red Heron a analysé 1 386 instances Gitea accessibles depuis Internet dans sept pays. L’acteur disposait également d’un jeu de données distinct recensant 477 systèmes à Taïwan, sans qu’il soit possible de déterminer si ces systèmes recoupaient les résultats du balayage plus large.

Les 13 compromissions confirmées se répartissaient comme suit :

• Quatre organisations à Taïwan
• Quatre aux États-Unis
• Deux au Canada
• Une en Argentine
• Une au Qatar
• Une au Sri Lanka

Le septième pays couvert par l’opération de balayage n’a pas été identifié.

Si certaines activités ressemblaient à une exploitation opportuniste à l’échelle d’Internet, la sélection et l’étiquetage des cibles témoignaient d’un effort plus délibéré de collecte de renseignements. Les secteurs touchés comprenaient des organisations susceptibles de détenir des technologies sensibles, des données d’infrastructure, des informations gouvernementales ou des accès privilégiés à d’autres réseaux.

La TRU estime avec un niveau de confiance modéré que l’acteur opère dans un contexte lié à la Chine. Cette évaluation ne constitue pas une attribution définitive au gouvernement chinois. Elle repose sur l’utilisation par Red Heron de libellés en chinois simplifié, sur la classification systématique de Taïwan comme faisant partie de la Chine et sur un ciblage correspondant aux priorités supposées des services de renseignement chinois.

Des activités connexes ont également visé un cabinet de conseil en formation à l’étranger basé en Inde et un fournisseur de services informatiques gérés aux États-Unis. Ces organisations ont été ciblées par l’intermédiaire d’infrastructures associées, mais elles ne sont pas présentées comme des compromissions confirmées supplémentaires au-delà du total de 13 pays.

CVE-2026-60004 permet l’exécution de code à distance sans authentification

Le vecteur d’accès initial était CVE-2026-60004, une vulnérabilité d’exécution de code à distance affectant les versions de Gitea antérieures à la version 1.27.1.

La faille se trouve dans l’API diffpatch de Gitea et permet à un attaquant d’installer un hook Git. Comme les hooks Git peuvent exécuter des commandes en réponse aux opérations effectuées sur un dépôt, l’exploitation de ce mécanisme offre à l’attaquant un moyen d’exécuter du code sur le serveur sous-jacent.

CVE-2026-60004 affiche un score CVSS v3 de 9,8 et est classée CWE-94, contrôle incorrect de la génération de code. Son vecteur est le suivant :

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

La vulnérabilité est exploitable à distance, présente une faible complexité d’attaque et ne nécessite ni compte existant ni interaction de la part d’un utilisateur. Une exploitation réussie peut avoir un impact élevé sur la confidentialité, l’intégrité et la disponibilité.

La vulnérabilité a été divulguée en juillet 2026. D’après les informations publiées sur la campagne, Red Heron a commencé à transformer le code d’exploitation accessible au public en un framework Python automatisé nommé exp_enhanced.py le 29 juillet 2026.

Ce framework automatisait plusieurs étapes qui auraient autrement nécessité des actions distinctes de la part de l’opérateur : création de comptes, exploitation de serveurs vulnérables, vol de dépôts et suppression de certaines traces. Il réduisait ainsi le délai entre la découverte d’une instance exposée et la collecte de ses données.

L’accès aux dépôts a servi de passerelle vers les réseaux internes

Une plateforme de développement autohébergée peut contenir bien davantage que le code source d’une application. Les dépôts incluent souvent des fichiers de déploiement, des adresses de serveurs, des jetons d’API, des éléments SSH, des identifiants d’intégration et des secrets de configuration. Même lorsque certains secrets ne sont plus valides, ils peuvent révéler les conventions de nommage et la structure du réseau.

Red Heron a utilisé les systèmes Gitea compromis comme points de collecte et, lorsque cela était possible, comme passerelles vers les environnements des victimes. Les activités observées ont progressé du vol de dépôts à la récupération d’identifiants, en passant par la persistance, la reconnaissance interne et les déplacements latéraux.

Au sein d’une entreprise taïwanaise d’automatisation industrielle, l’acteur a exfiltré des centaines de dépôts. Les données volées concernaient notamment un produit SCADA/HMI, des intégrations de plateformes IoT, un analyseur de trafic réseau, des configurations de serveurs, des logiciels de surveillance et de supervision, ainsi que des applications métier internes.

L’intrusion s’est ensuite étendue à un accès root sur les trois nœuds Proxmox. Le contrôle root des hôtes de virtualisation pouvait donner à l’attaquant une visibilité étendue et de vastes privilèges administratifs sur les charges de travail exécutées sur le cluster, même si l’ampleur exacte des conséquences dans ce cas n’a pas été communiquée.

Une entreprise canadienne spécialisée dans les énergies renouvelables a fait l’objet d’une cartographie approfondie de son infrastructure et d’un vol de dépôts. Les données exposées comprenaient des secrets de configuration, des jetons internes, des clés d’hôte SSH et des applications propriétaires.

Dans une entreprise argentine de trading quantitatif, Red Heron a procédé à une énumération poussée de l’infrastructure de l’organisation. Une victime basée au Qatar a perdu des dépôts liés à une plateforme de gestion de l’apprentissage, à un chatbot d’IA, à des outils d’automatisation des workflows et à des extensions WordPress.

Ces incidents montrent pourquoi corriger uniquement le serveur Gitea peut ne pas suffire à mettre fin à une intrusion. Les identifiants et les clés obtenus avant la remédiation peuvent rester exploitables après celle-ci.

JITTERLY et SIXZUT ont assuré un accès Linux persistant

L’infrastructure attribuée à Red Heron hébergeait un implant Linux écrit en C++ et baptisé JITTERLY. Ce malware prend en charge plus de 30 commandes post-exploitation, notamment l’exécution de commandes shell, le transfert de fichiers, l’arrêt de processus, le tunneling réseau, l’accès à un terminal interactif et le pivotement au sein du réseau interne.

En juillet 2026, un chercheur utilisant le pseudonyme « dmpdump » a documenté JITTERLY et relevé des similitudes avec l’agent AdaptixC2. Les informations disponibles ne permettent pas de déterminer si Red Heron a développé cet implant ou repris du code existant.

Le même environnement de staging hébergeait SIXZUT, un rootkit Linux jusque-là non documenté, fondé sur LD_PRELOAD. Cette technique force le chargement d’une bibliothèque partagée malveillante avant les bibliothèques légitimes, ce qui lui permet d’intercepter les appels effectués par les programmes du système.

SIXZUT modifie 15 fonctions Linux afin de dissimuler des fichiers, des processus et des connexions réseau. Il est également conçu pour résister à sa suppression en se relançant après son arrêt. Ces capacités peuvent masquer le trafic de commande et de contrôle ainsi que les processus malveillants lors des contrôles administratifs courants.

Une infrastructure commune a relié la campagne contre Gitea à des attaques visant 18 sites Joomla dans 10 pays. Un script Python nommé exp.py a été utilisé pour les activités visant Joomla, avant que l’opérateur n’intègre le code d’exploitation public de CVE-2026-60004 à ses outils Gitea. Cela révèle une opération d’exploitation web plus vaste, qui ne se limitait pas à un seul produit logiciel.

CISA a ajouté la faille au catalogue KEV avec un délai de trois jours

CISA a ajouté CVE-2026-60004 à son catalogue Known Exploited Vulnerabilities le 25 août 2026. Les agences fédérales américaines devaient appliquer les mesures correctives avant le 28 août 2026.

Ce délai très court reflétait une exploitation confirmée et non un risque théorique. Selon l’action enregistrée, les agences doivent appliquer les mesures d’atténuation fournies par l’éditeur tout en respectant la directive BOD 26-04, « Prioritizing Security Updates Based on Risk », ainsi que les exigences de CISA en matière de triage forensique.

Les recommandations applicables de la BOD 26-04 couvrent également les services cloud. Si aucune mesure d’atténuation efficace n’est disponible, CISA demande aux agences de cesser d’utiliser le produit concerné. Les organisations restent responsables de l’évaluation de l’exposition de chaque actif sur Internet et du respect des exigences de correctifs applicables.

Toutes les versions de Gitea antérieures à la version 1.27.1 sont vulnérables. Les opérateurs doivent effectuer une mise à niveau vers la version 1.27.1 ou une version ultérieure, conformément aux instructions de Gitea et à leurs propres procédures de gestion des changements.

L’application des correctifs doit s’accompagner d’une recherche de compromission

Les organisations doivent d’abord recenser tous les déploiements Gitea, y compris les serveurs de test oubliés et les instances exposées par l’intermédiaire de reverse proxies. Tout système vulnérable accessible depuis Internet doit être traité en priorité.

Les équipes de défense doivent ensuite vérifier si une exploitation a eu lieu avant la mise à niveau. Les éléments suivants méritent notamment d’être examinés :

• Création inattendue de comptes Gitea
• Création ou modification de hooks Git
• Activité inhabituelle sur l’API diffpatch
• Accès massif à des dépôts ou transferts sortants
• Création récente de clés SSH ou modification de fichiers de clés autorisées
• Exposition ou utilisation de secrets de configuration et de jetons internes
• Opérations administratives Proxmox inattendues
• Processus Linux, tunnels ou connexions sortantes suspects
• Configuration LD_PRELOAD et bibliothèques partagées non reconnues
• Fichiers ou commandes associés à exp_enhanced.py, exp.py, JITTERLY ou SIXZUT

Les secrets stockés dans les dépôts concernés doivent être considérés comme potentiellement exposés. Les jetons d’API, mots de passe, clés SSH, éléments de signature et identifiants de service concernés doivent être renouvelés, et les journaux d’authentification doivent être examinés afin de détecter toute utilisation ultérieure.

Les systèmes présentant des signes de la présence de SIXZUT peuvent ne pas fournir d’informations fiables sur les processus ou le réseau, car le rootkit peut manipuler la visibilité depuis l’espace utilisateur. Dans ce cas, les équipes d’intervention doivent utiliser des outils forensiques réputés fiables et recueillir les éléments de preuve avant de reconstruire les hôtes concernés.

Le risque principal ne se limite pas à l’application Gitea. Dès lors qu’un serveur de développement expose du code source, des identifiants et des configurations d’infrastructure, la compromission peut s’étendre aux systèmes qui compilent, déploient, hébergent ou administrent les logiciels d’une organisation.