Le GitHub Action `tj-actions/changed-files` a été compromis — 23 000 dépôts l’utilisent

• Un GitHub Action populaire utilisé pour suivre les changements sur chaque branche a été compromis, avec une tentative d’exfiltration de secrets CI/CD via un commit malveillant
• 23 000 dépôts sont concernés, GitHub a supprimé cette action et elle n’est plus utilisable
• Il faut la remplacer par une action alternative et vérifier les logs publics des workflows, car des secrets ont pu être exposés ; une rotation des clés est indispensable après vérification
• Harden-Runner de StepSecurity a détecté le problème, et une action alternative renforcée côté sécurité, step-security/changed-files, est distribuée gratuitement

Résumé de l’incident

• tj-actions/changed-files est utilisé dans plus de 23 000 dépôts et a été compromis
  • Les attaquants ont modifié le code de l’action et redirigé les tags de version vers un commit malveillant
  • Cela a entraîné l’affichage de secrets CI/CD dans les logs de build GitHub Actions
• Des secrets ont pu être exposés dans des logs de workflows publics
• Le problème a été découvert après que Harden-Runner a détecté un endpoint inattendu
• Un script Python malveillant forçait le dump des secrets depuis le processus Runner Worker
• Tous les tags pointaient vers le même hash de commit malveillant (0e58ed8671d6b60d0890c21b07f8835ace038e67)

Mesures prises par GitHub

• GitHub a supprimé l’action tj-actions/changed-files et en a stoppé l’utilisation
• Le CVE officiel est CVE-2025-30066

Comment remédier au problème

• 1. Utiliser l’action alternative sécurisée fournie par StepSecurity

  • Remplacer l’action tj-actions/changed-files par step-security/changed-files@v45

• 2. Supprimer toutes les références à tj-actions/changed-files

  • Rechercher puis supprimer les références à tj-actions/changed-files dans la base de code :

    git grep -l "tj-actions/changed-files"  
    

• 3. Auditer les logs d’exécution des workflows GitHub Actions

  • Vérifier dans les logs récents si des secrets ont fuité
  • Si des secrets exposés sont trouvés, il faut immédiatement les faire pivoter (les réinitialiser)

• 4. Configurer une liste blanche GitHub Actions

• Configurer une liste blanche pour n’autoriser que les GitHub Actions de confiance :
  • Réglage disponible dans GitHub :
    • Settings → Actions → Allow select actions

• 5. Configurer StepSecurity Harden-Runner

  • Harden-Runner permet de configurer la surveillance du trafic réseau et de l’exécution des workflows

Étapes suivantes

• Problème signalé à GitHub → issue GitHub : #2463
• Le dépôt tj-actions/changed-files a été supprimé
• Référencé officiellement sous CVE-2025-30066
• StepSecurity Harden-Runner peut détecter et prévenir des problèmes de sécurité similaires
• La configuration de Harden-Runner est recommandée pour renforcer la posture de sécurité et mettre en place une supervision en temps réel

[dl57934]

Ça ne marchait pas hier soir, mais maintenant ça remarche.

[GN⁺]

Avis Hacker News

• L’auteur et mainteneur de Renovate décrit le scénario de l’attaque

  • L’attaquant disposait d’un accès en écriture au dépôt tj-actions/changed-files
  • L’attaquant a usurpé des commits Renovate pour masquer le commit récent
  • Cette usurpation ne visait pas à tromper la PR, mais simplement à semer la confusion
  • Le commit était marqué comme non vérifié, et la plupart des gens n’imposent pas uniquement les commits signés
  • Le véritable Renovate Bot propose des PR pour mettre à jour les dépendances
  • Certaines personnes avaient activé l’auto-merge, mais ce n’est pas la configuration par défaut
  • Cet incident rappelle que beaucoup de gens pensent à tort que les tags git sont immuables

• La confiance envers les dépendances et extensions tierces diminue depuis quelques années

  • Si un package npm a trop de dépendances, il n’est pas installé
  • Les extensions vscode ou chrome ne sont pas installées
  • Il arrive souvent que du code malveillant soit ajouté ou que la licence change
  • Quand on regarde l’arbre de dépendances d’eslint, on peut se demander si tout est réellement digne de confiance

• Le dépôt est revenu en ligne et le développeur a fourni une explication

  • L’attaque provenait du token PAT du compte @tj-actions-bot
  • La sécurité du compte a été renforcée et GitHub a révoqué le PAT compromis

• Une enquête sur github_events dans Clickhouse a permis d’identifier les comptes utilisés pour l’attaque

  • Les comptes "2ft2dKo28UazTZ" et "mmvojwip" sont suspects

• Il est choquant que la manière d’exécuter le CI/CD consiste à répertorier des dépôts arbitraires sur GitHub

  • Le problème devient plus grave avec l’augmentation des LLMs
  • Les tâches importantes devraient être exécutées manuellement

• Le cofondateur de StepSecurity explique comment l’incident de sécurité a été détecté

  • Harden-Runner a détecté l’anomalie en surveillant les appels réseau des workflows GitHub Actions

• Le problème vient du fait que l’usage par défaut de GitHub Actions repose sur des tags git non immuables

  • L’algorithme de hachage SHA-1 peut produire des collisions, d’où la nécessité d’un support SHA-256

• Des GitHub Actions immuables devraient être introduites

  • Forker les Actions ou utiliser des hashes de commit

• Le projet maven-lockfile décrit une PR fusionnée automatiquement

  • Le vrai Renovate Bot a fusionné automatiquement le commit du faux Renovate Bot

• GitHub Actions devrait utiliser un lockfile pour les dépendances

  • La notation Semver est une bonne solution pour résoudre ce problème