Alpine Linux a réinstallé son serveur GitLab après avoir frôlé la catastrophe, ce que vous devriez vérifier au plus vite Un pirate a failli exploiter une faille présentant un niveau de gravité maximal. Voici ce qu'il faut savoir. Les points clés à retenir sur l'affaire Alpine Linux Ce qui est arrivé à Alpine Linux peut arriver, et est déjà arrivé, à d’autres groupes et entreprises. Se contenter d’appliquer un correctif à un seul composant ne suffit pas pour garantir une véritable sécurité. À l’heure où les attaques basées sur l’IA sont constantes, la sécurisation de vos outils de développement n’a jamais été aussi urgente. Les 20 et 21 octobre, un pirate a tenté d’exploiter la grave faille GitLab CVE-2026-97229 sur l’instance GitLab d’Alpine Linux. Alpine a admis dans son communiqué sur l’incident que l’attaque « avait failli réussir ». Cela dit, les responsables n’ont trouvé aucune preuve qu’elle ait abouti. Ils ont toutefois précisé : « Nous ne pouvons pas l’exclure, nous avons donc considéré l’instance comme compromise. » J’apprécie qu’une équipe fasse de la sécurité sa priorité absolue. C’est rare de nos jours. Comment un serveur corrigé est resté vulnérable CVE-2026-97229 est noté 10,0 selon le Common Vulnerability Scoring System (CVSS), ce qui correspond au pire niveau possible pour une faille de sécurité, et ce pour une faille qui a déjà été corrigée. Que s’est-il donc passé ? Tout d’abord, il faut comprendre en quoi consistait ce bug. Il s’agit d’une vulnérabilité potentiellement fatale permettant l’exécution de code à distance dans GitLab Community Edition (CE) et Enterprise Edition (EE). Dans certaines conditions, un attaquant non authentifié peut exécuter du code arbitraire sur un serveur GitLab en fournissant une expression régulière spécialement conçue dans un fichier de configuration de pipeline d’intégration continue et de livraison continue (CI/CD). Comme l’a expliqué Alpine, ce bug s’inscrit dans le prolongement d’un autre bug présent dans Onigmo, le moteur d’expressions régulières du langage Ruby. GitLab l’a corrigé le 12 octobre dans les versions 19.4.2, 19.3.5 et 19.2.8. Les grands moyens pour les gros problèmes La correction apportée par GitLab consiste en un ensemble de correctifs pour Ruby que GitLab intègre dans ses propres paquets et images de conteneurs. Le 23 octobre, Upstream Ruby a publié le correctif. Jusque-là, tout allait bien. Ce qui s’est passé ensuite, c’est que le 13 octobre, Alpine a par erreur effectué une mise à jour vers GitLab 19.3.4 au lieu de 19.3.5. Par la suite, le 22 octobre, il est passé à la version 19.3.6, qui ne corrigeait pas le bogue. L’image d’Alpine utilisait une version standard de Ruby, qui ne disposait pas du correctif. Entre-temps, un compte nouvellement créé a envoyé des configurations CI spécialement conçues qui ont provoqué huit plantages des workers GitLab. Lors de quatre de ces plantages, l’attaquant a réussi à mener l’exploitation jusqu’à un certain point avant d’échouer à l’étape suivante. L’attaquant a également téléchargé l’image du conteneur GitLab d’Alpine, ce qui suggère qu’il a adapté l’exploitation à cette version précise. Une fois qu’Alpine a compris ce qui se passait et constaté que son serveur était toujours vulnérable le 26 octobre, l’entreprise l’a fermé le 27 octobre. Elle l’a ensuite rouvert le 29 octobre avec la version GitLab 19.3.7 correctement corrigée, équipée de Ruby 3.3.13. Pourquoi Alpine a-t-il préféré reconstruire plutôt que nettoyer ? Tout allait donc bien ? N’est-ce pas ? Peut-être. Alpine n’en était pas si sûr. Ses programmeurs ont estimé qu’une exploitation réussie ne laisserait aucune trace de plantage ni aucune trace dans les journaux Web. Certains journaux datant du jour de l’attaque avaient disparu, et ni Alpine ni son hébergeur n’enregistraient les connexions sortantes. Par conséquent, Alpine a déclaré : « Comme nous ne pouvons pas exclure l’exécution de code et que les preuves dont nous aurions besoin pour le confirmer n’existent plus, nous avons choisi la solution la plus difficile et avons reconstruit l’instance GitLab à partir de zéro. » Cela me semble logique. À la suite de cet incident, les utilisateurs d’Alpine GitLab doivent définir de nouveaux mots de passe, réactiver l’authentification à deux facteurs, créer de nouveaux jetons d’accès et accepter de nouvelles clés hôtes SSH. Les responsables de projets doivent saisir à nouveau les valeurs des variables CI/CD et partir du principe que les anciennes ont pu être compromises. Cette faille est activement exploitée. La CISA a ajouté le CVE-2026-97229 à son catalogue des vulnérabilités connues pour être exploitées le 30 octobre. De plus, la Shadowserver Foundation, un groupe de sécurité à but non lucratif, a découvert plus de 1 000 serveurs GitLab non corrigés au cours du week-end. GitLab a connu une série de failles de gravité maximale. En septembre, CVE-2026-85706, un dépôt, présentait une faille dans son interface de programmation d’application (API) pouvant être exploitée pour voler des identifiants et d’autres informations confidentielles. Puis, le mois dernier, CVE-2026-110264 (un autre bug du compilateur d’expressions régulières permettant l’exécution de code arbitraire) a été découvert. Shadowserver a recensé plus de 11 300 instances vulnérables, sur environ 39 000 instances GitLab. Mais GitLab n’est pas le seul à être pris pour cible. Par exemple, la société de sécurité cloud RadWare a signalé au moins 83 attaques contre 61 dépôts GitHub publics. Celles-ci ont touché plusieurs projets open source populaires. La faille de GitLab découverte en septembre a été exploitée environ un jour après sa correction Tous ces incidents se sont déroulés très rapidement. À peine les vulnérabilités avaient-elles été corrigées qu’elles faisaient déjà l’objet d’attaques. La faille de GitLab découverte en septembre a été exploitée environ un jour après sa correction, et l’attaquant d’Alpine est intervenu huit jours après l’attaque contre GitLab. La plupart de ces attaques visaient à obtenir les identifiants des programmeurs, tels que les variables CI/CD, les jetons de runner, les clés SSH et les données des assistants IA. Les pirates s’en prennent notamment aux environnements CI/CD et aux ordinateurs portables des développeurs. Pour l’avenir, Alpine a déclaré qu’elle appliquerait les mises à jour de sécurité critiques de GitLab dans un délai d’un jour, vérifierait chaque version pour s’assurer qu’elle contient les correctifs Ruby ou d’autres composants que sa propre version doit intégrer, enregistrerait les connexions sortantes et conserverait les journaux pendant plus de 14 jours. Elle utilisera également des balises de version signées, afin que les versions puissent être vérifiées indépendamment de GitLab. Empêchez vos serveurs Git de devenir la prochaine cible « Maintenir vos logiciels à jour » est toujours une bonne idée, mais vous devez désormais appliquer les correctifs dès que possible. Les attaquants utilisant l’IA ne vont pas attendre la fin du week-end pour s’introduire dans votre système. Mais cela ne suffit pas, comme l’a montré l’expérience d’Alpine. Vous devez vérifier que le correctif est bien appliqué au code s’exécutant sur votre serveur, en particulier si vous développez vos propres systèmes CI/CD et conteneurs. Vous devez également vous assurer que l’ensemble de votre pile logicielle, de haut en bas, est à jour, et pas seulement que vous utilisez la dernière version de l’application. GitLab avertit explicitement les administrateurs utilisant des images personnalisées ou leur propre environnement d’exécution Ruby que la mise à jour de GitLab seule ne suffit pas. Tout — et je dis bien tout — doit être mis à jour. Se contenter de supposer que la dernière version de GitLab ou de GitHub suffit pour que le travail soit fait, c’est courir à la catastrophe. Au-delà de l’application des correctifs, les administrateurs doivent s’attacher à limiter l’accès d’un compte, d’un workflow ou d’un serveur compromis. Vous savez, ou devriez savoir, ce que cela signifie. Par exemple, vous devez exiger une authentification à deux facteurs ou des clés d’accès. La gestion des correctifs et la sécurité des comptes sont deux tâches distinctes, et vous avez besoin des deux. Ne pas fournir à vos pipelines CI/CD toutes les données d’authentification Aussi tentant que cela puisse être de fournir à vos pipelines CI/CD toutes les données d’authentification dont ils ont besoin pour fonctionner, c’est une erreur. Ne donnez pas à vos pipelines les clés de votre royaume. GitHub recommande de n’accorder aux jetons de workflow que les autorisations dont ils ont besoin, de définir par défaut le jeton GITHUB_TOKEN en lecture seule et d’exiger une validation avant que les tâches puissent accéder aux secrets de l’environnement. Cela signifie également que vous devez nettoyer vos systèmes en supprimant les identifiants inutilisés et, dans la mesure du possible, en remplaçant les clés cloud à longue durée de vie par des identifiants à courte durée de vie obtenus via OpenID Connect. Tout cela est bien beau, mais ce n’est pas suffisant. Vous devez renouveler en permanence les secrets, et pas seulement les mots de passe. Si un attaquant parvient à accéder à un serveur Git ou à un environnement CI, le simple fait de modifier les identifiants de connexion peut laisser des jetons API, des certificats et des clés de déploiement volés utilisables. Les recommandations de GitLab en cas d’incident préconisent de renouveler les secrets stockés après toute compromission pertinente. Tenez un inventaire afin de pouvoir les identifier, les révoquer et les remplacer sans avoir à deviner quels projets dépendent de quelles informations d’identification. Le travail n’est pas terminé une fois que vous avez sécurisé votre pipeline de développement Vous devez également séparer les builds non fiables de l’infrastructure de confiance. GitLab met en garde contre le fait que des tâches d’intégration continue malveillantes peuvent compromettre les hôtes des runners et voler des identifiants. Utilisez des runners isolés et jetables pour les charges de travail à risque, évitez les conteneurs privilégiés et ne stockez pas les identifiants de déploiement ni les clés SSH sur des machines de build partagées. GitHub avertit également qu’un code de workflow non fiable peut compromettre des instances Git. Le travail n’est pas terminé une fois que vous avez sécurisé votre pipeline de développement. Vous devez également sécuriser vos versions publiées. Les versions immuables de GitHub empêchent le remplacement des binaires et des archives publiés et verrouillent la balise Git associée à un commit spécifique. Enfin, toute mesure préventive doit s’accompagner d’un plan de reprise. Alpine n’a pas pu exclure la possibilité d’une exploitation réussie, car les preuves dont elle avait besoin n’étaient plus disponibles. Sa réponse a notamment consisté à allonger la durée de conservation des journaux, à mettre en place la journalisation des connexions sortantes et à utiliser des balises de version vérifiables de manière indépendante. Fort de ces informations, vous pouvez déterminer ce qui s’est passé et décider s’il suffit d’appliquer un correctif pour passer à autre chose ou s’il faut procéder à une refonte complète. ZDNET Morning 06/11/2026 : Restructuration chez Meta France, Prolifération des datacenters en Île-de-France, Shein investit 500M€ en Pologne,... Galaxy Book6 Series : 10 raisons de choisir la performance Le guide de la migration écoresponsable vers Windows 11 IA locale : la nouvelle ère de l’Intelligence artificielle ? OpenAI lance GPT-6 Cyber, une IA qui traque les failles avant les attaquants GPT-6 Cyber est un modèle qui repère des failles logicielles, vérifie qu’elles sont exploitables et propose des correctifs. Réservé à certains clients du programme Daybreak Red, il a trouvé 81 failles inédites dans Firefox. Linux Mint 27 sortira le mois prochain, et je l'apprécie déjà : nouvelles fonctionnalités et autres améliorations à venir Tout commence par un numéro de version inattendu : Linux Mint 27 au lieu de 24. Mais cette nouvelle version apporte bien plus de changements que cela. PAR STEVEN VAUGHAN-NICHOLS | 05 NOVEMBRE 2026 Cyberattaque Crédit Mutuel Arkéa : 100 millions d'euros exfiltrés vers la sphère crypto Le groupe bancaire annonce la maîtrise d'une attaque informatique ayant forcé la suspension temporaire de ses transactions. Si les avoirs des clients sont préservés, l'ampleur de la fraude interroge l'efficacité des systèmes de détection de l'établissement. ZDNET Morning 05/11/2026 : L'EFS déjoue une attaque, OpenAI déploie Image 2.6, Les robots humanoïdes de Xiaomi en test,... Le ZDNET Morning le brief de l'actu tech pour les pros tous les matins à 9h00. Transformation numérique, IA, matériel, logiciels,... ne passez pas à côté de ce qui fait la Une du secteur. Linux pratique : essayez Spotifast, une alternative à Spotify Si vous en avez assez du programme officiel Spotify, il existe d'autres solutions. Voici en quoi ce logiciel gratuit est plus performant. Informatique pratique : mettez en place votre propre réseau sécurisé d’accès distant gratuit sur vos ordinateurs personnels Vous avez besoin d'accéder de manière simple et fiable à plusieurs machines de votre domicile ou de votre petite entreprise ? Avant de dépenser une fortune dans un VPN ou un autre service, essayez Tailscale. Le Grand Test RTX Spark de Lenovo : j'ai soumis cette machine à un test de programmation IA complètement dingue, et elle l'a réussi Oubliez les tests de performances habituels sur les ordinateurs portables : j'ai testé le Lenovo RTX Spark à 3720 € en le soumettant à de véritables tâches de programmation d'IA en local et à une charge de travail intense mettant à rude épreuve l'autonomie de la batterie. Le Framework 12 est le PC idéal pour les passionnés de bricolage, et un vrai bonheur pour les utilisateurs de Linux Je l'avoue : j'ai toujours été sceptique à l'égard des ordinateurs portables sous Linux, mais Framework m'a prouvé qu'on pouvait y arriver. Linux pratique : essayez cette distribution si votre ordinateur est peu puissant (genre 3 Go) Essora Linux est rapide et minimaliste, conçue pour une utilisation pratique sur du matériel modeste. Lors du test elle a tourné sur un PC équipé de seulement 3 Go de RAM ! Comment utiliser deux PC sur un seul écran, quelle que soit la marque de vos appareils C'est l'heure du « dual » : mettre en place une configuration avec un seul écran et deux ordinateurs est plus simple que vous ne le pensez. Retour d’expérience : j’ai essayé de faire exploser un traqueur de portefeuille afin de tester sa sécurité Ces tags de localisation renferment une batterie au lithium à l'intérieur d'une fine couche de plastique qui se déforme à chaque fois que l'on s'assoit dessus. Est-ce que j’ai réussi à en faire prendre feu l’un d’eux? PAR ADRIAN KINGSLEY-HUGHES | 26 OCTOBRE 2026 HDMI, DisplayPort, Thunderbolt : quelle connexion choisir pour vos écrans ? Les PC et les ordinateurs portables disposent de trois grands types de connexion pour les écrans. Lequel est le meilleur ?