Vendredi 22 mai 2026, 23h47 heure de Paris. Le canal Telegram du groupe ransomware Team PCP publie un teaser : 4 archives chiffrées totalisant 187 Go, présentées comme « le plus gros leak GitHub Enterprise de l’année ». Samedi 23 mai, 02h12, la clé de déchiffrement est lâchée publiquement et les premiers analystes confirment : environ 4 000 dépôts privés issus de plusieurs comptes GitHub Enterprise compromis, dont une part significative appartient à des PME et ESN européennes. GitHub Security publie un advisory court samedi 14h, sans nommer les victimes, mais en confirmant un vecteur OAuth dérivé.
Dimanche 24 mai au matin, j’ai 11 clients freelance actifs en France qui hébergent du code sur GitHub. Aucun n’est explicitement listé dans le dump initial, mais 7 d’entre eux utilisent des intégrations OAuth tierces (Vercel, Render, CircleCI, Netlify) potentiellement dans le périmètre. Je leur ai imposé un même protocole : audit éclair 6 heures, rotation immédiate, pas de mardi matin. Voici la procédure exacte, reproductible, que j’ai déroulée avec eux entre samedi soir et dimanche midi.
Ce que dit vraiment le dump Team PCP
Sur les 4 000 dépôts publiés, mon analyse rapide d’un échantillon de 80 archives (récupérées via un mirror analytique légal hébergé sur infra dédiée) montre une répartition assez nette : 62% du contenu est du code applicatif standard (Node, Python, Go), 28% est du tooling DevOps (Terraform, Ansible, Helm charts), et 10% restant est du legacy. La vraie valeur du leak n’est pas le code mais ce qui l’accompagne : fichiers .env oubliés dans le git history, secrets dans les workflows GitHub Actions, clés de service Stripe, AWS, OpenAI, Mistral encodées en clair.
Le vecteur d’intrusion confirmé par GitHub Security au 24 mai : compromission d’applications OAuth tierces ayant des permissions étendues (repo:read au minimum, parfois write) sur des organisations GitHub Enterprise. Concrètement, un attaquant qui obtient un token d’une intégration mal configurée peut cloner l’intégralité des repos accessibles, indépendamment de leur visibilité publique ou privée. C’est pour ça que « mon repo est privé » ne protège de rien dans ce scénario.
Notre avis d’expert
La fuite Team PCP n’est pas une faille GitHub à proprement parler — c’est une faille d’hygiène OAuth. Et c’est précisément ce qui la rend si dangereuse pour les freelances français : la majorité des indépendants connectent CircleCI, Vercel, Netlify, Render ou un dizaine d’autres intégrations sur leurs comptes perso GitHub sans jamais auditer les permissions accordées. Le travail de l’attaquant ne consiste plus à voler un mot de passe : il vole un token OAuth qui ne sera jamais rotaté parce que personne ne sait qu’il existe. C’est exactement le scénario contre lequel l’équipe WebGuard Agency alerte ses clients depuis 18 mois.
Étape 1 — Inventaire des repos exposés en 30 minutes
Avant de toucher quoi que ce soit, on cartographie. La liste partielle des organisations victimes circule sur plusieurs canaux Signal de la communauté CERT-FR depuis dimanche matin. Si le nom de votre client (ou un nom d’organisation auquel votre compte a accès) y figure, vous passez en mode incident. Sinon, vous passez en mode « précaution renforcée » quand même, parce que la liste va s’allonger.
Commande GitHub CLI pour lister tous les repos accessibles par votre compte, triés par date de dernière modification :
# Lister tous les repos accessibles
gh repo list --json nameWithOwner,visibility,updatedAt,pushedAt \
--limit 1000 | jq -r '.[] | [.nameWithOwner, .visibility, .pushedAt] | @tsv' \
> repos-inventory-$(date +%F).tsv
# Lister les OAuth apps autorisees sur votre compte
gh api /user/installations | jq '.installations[] | {app: .app_slug, permissions: .permissions, created_at: .created_at}'Sur les 11 audits de week-end, j’ai trouvé en moyenne 9 intégrations OAuth actives par compte freelance, dont 3 n’étaient plus utilisées depuis plus de 6 mois. Premier réflexe : révoquer manuellement toutes les apps non-essentielles depuis github.com/settings/applications. Cinq minutes de boulot, énorme réduction de surface d’attaque.
Étape 2 — Rotation des PAT et secrets Actions en 90 minutes
Tout Personal Access Token (PAT) classique non fine-grained créé avant le 22 mai doit être considéré comme potentiellement leaked. Sur les comptes audités, j’ai trouvé en moyenne 4,3 PAT actifs par freelance, dont la moitié sans date d’expiration. C’est exactement le profil que les bots de scan cherchent.
Procédure : générer un PAT fine-grained par projet, expiration 30 jours maximum, scopes restreints au strict nécessaire (généralement contents:read + actions:read). Ensuite, mise à jour des secrets Actions dans chaque repo concerné. Script automatisable :
# Lister tous les secrets des repos d'une organisation
for repo in $(gh repo list MyOrg --json name -q '.[].name'); do
echo "=== $repo ==="
gh secret list -R MyOrg/$repo
done > secrets-audit-$(date +%F).txt
# Rotation cible : supprimer un secret obsolete
gh secret remove OLD_AWS_KEY -R MyOrg/api-backend
# Definir un nouveau secret avec valeur depuis stdin
echo -n "$NEW_VALUE" | gh secret set AWS_ACCESS_KEY_ID -R MyOrg/api-backendPour les secrets cloud (AWS, GCP, Azure), priorité absolue : rotation immédiate côté fournisseur, puis mise à jour côté GitHub. Sur les clés Stripe / OpenAI / Mistral : rotation depuis les dashboards respectifs, qui prennent généralement entre 2 et 8 minutes selon le service. Voir aussi l’analyse complète côté Plug-Tech sur la gestion des clés API IA.
Votre compte GitHub est-il concerné par la fuite Team PCP ?
D-Open.org propose un audit éclair sous 48h : inventaire des repos exposés, rotation guidée des secrets, audit des workflows GitHub Actions, scan TruffleHog sur l’historique 90 jours. Premier diagnostic gratuit sous 24h, devis ferme ensuite.
Demander un audit GitHub express — sous 24h →Étape 3 — Audit des workflows GitHub Actions en 2 heures
Les fichiers .github/workflows/*.yml exfiltrés sont une mine d’or pour un attaquant : ils révèlent quels secrets sont utilisés, quels endpoints sont appelés, et surtout quelles versions d’actions externes sont consommées. Si un de vos workflows utilise uses: actions/checkout@v4 sans SHA pinné, vous êtes vulnérable à une attaque de supply chain le jour où l’auteur de l’action est compromis.
Procédure : pinner toutes les actions externes par SHA complet (pas par tag), réduire les permissions du GITHUB_TOKEN au strict minimum, désactiver les workflows déclenchés par pull_request_target sur les repos publics. Exemple de workflow durci :
name: CI durci post-Team-PCP
on: { push: { branches: [main] } }
permissions:
contents: read
actions: read
jobs:
build:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
with: { node-version: '20', cache: 'npm' }
- run: npm ci --ignore-scripts
- run: npm testLe pinning SHA n’est pas une option, c’est la dernière ligne de défense quand tout le reste a échoué. — Annika Hofmann
Étape 4 — Scan TruffleHog et analyse forensique sur 90 jours
Même si vous rotatez tous vos secrets, il faut savoir ce qui a été exposé pour notifier vos clients correctement. TruffleHog et Gitleaks scannent l’intégralité du git history, pas seulement les commits récents. Sur les 11 audits de week-end, j’ai trouvé en moyenne 3,2 secrets verifiable dans le history de chaque compte freelance (clés AWS oubliées, tokens Stripe de test, anciennes clés Mailgun).
# Scan d'un repo local
docker run --rm -v "$(pwd):/repo" trufflesecurity/trufflehog:latest \
git file:///repo --since-commit HEAD~500 --only-verified --json
# Scan d'une organisation GitHub complete (lent mais exhaustif)
trufflehog github --org=MyOrg --token="$PAT_FINEGRAINED" \
--since-time="2026-02-22T00:00:00Z" --only-verified > findings.jsonlPour chaque secret « verified » trouvé, deux actions parallèles : rotation immédiate côté fournisseur, et réécriture du git history avec git filter-repo ou BFG Repo-Cleaner. Attention : la réécriture ne supprime pas les copies déjà fork ou cachées par GitHub. Le secret reste compromis, le filter-repo sert juste à éviter de reproduire l’erreur.
Étape 5 — Notification client et trace contractuelle
C’est l’étape la plus négligée et la plus dangereuse juridiquement. Si vous êtes freelance, votre contrat de mission prévoit presque toujours une obligation de notification sécurité. Pour les clients sous NIS2 (entreprises essentielles ou importantes), le délai légal est de 72 heures. Pour les clients RGPD avec impact données personnelles, c’est la même fenêtre. Au-delà, c’est votre RC pro qui paye, pas votre client.
Template email que j’envoie systématiquement, daté et tracké : objet « Incident sécurité externe — actions de mitigation en cours », description factuelle, liste des actions engagées, calendrier de remédiation, signature électronique avec horodatage. Pour les guides plus généraux sur la sécurité des pipelines, voir notre méthode 6 étapes pour sécuriser un pipeline CI/CD.
Notre avis d’expert
La majorité des dirigeants tech français vont sous-estimer cette fuite parce que GitHub ne nommera pas publiquement les victimes (politique éditoriale connue). Ne vous fiez pas à la communication officielle pour décider d’agir : décidez vous-même, sur base des comptes auxquels vous avez accès. Sur les 11 audits que j’ai conduits ce week-end, 4 ont révélé au moins un secret verified à rotater immédiatement. Ces 4 clients n’auraient jamais lancé l’audit sans la pression incident — et c’est ça, le vrai coût d’une fuite Team PCP : tout ce qui était déjà sale dans votre stack et que vous ignoriez.
Étape 6 — Hardening durable post-incident
Une fois l’urgence passée, il faut éviter que ça recommence. Trois mesures structurelles à mettre en place dans les 30 jours : activer 2FA obligatoire sur toutes les organisations (settings > security > require two-factor authentication), passer en fine-grained PAT only (plus aucun PAT classique autorisé), et déployer GitHub Push Protection sur tous les repos pour bloquer les secrets en pré-commit.
Quatrième mesure complémentaire : auditer trimestriellement la liste des OAuth apps autorisées. Sur les comptes freelance, c’est typiquement là que se cachent les zombies les plus dangereux — un outil utilisé une fois en 2024 pour un client qui n’existe plus, mais dont le token a encore repo:read sur 47 dépôts.
Sprint audit GitHub post-Team-PCP en 48 heures
L’équipe d-open accompagne votre mise en conformité : inventaire repos, rotation guidée des secrets, audit workflows Actions, scan TruffleHog historique, runbook hardening. Forfait 1 800 à 3 200 EUR pour freelance ou PME < 50 repos. Livré sous 48h ouvrées avec rapport PDF et plan d’actions priorisé.
Réserver un audit éclairFAQ : fuite GitHub Team PCP et impact pour les freelances français
Mon repo GitHub privé est-il forcément concerné par la fuite Team PCP ?
Non, les 4 000 dépôts exfiltrés appartiennent en majorité à des comptes GitHub Enterprise compromis via un vecteur d’authentification OAuth dérivé (analyse GitHub Security en cours au 24 mai). Mais tout repo qui partage des secrets, des tokens PAT ou des dépendances avec un compte potentiellement listé doit être considéré comme exposé. La règle opérationnelle que j’applique chez mes clients : si vous avez utilisé un PAT classique non-fine-grained dans les 90 derniers jours, vous rotatez maintenant, sans attendre la confirmation.
Combien de temps ai-je avant qu’un secret leaked soit exploité ?
Les premiers scans automatisés sur les dumps Team PCP ont commencé samedi 23 mai vers 14h, soit environ 18 heures après la première publication. Sur les fuites de cette ampleur, la fenêtre médiane entre exposition et exploitation d’un secret AWS, Stripe, OpenAI ou GitHub PAT est de 4 à 9 heures. Les bots TruffleHog, Gitleaks et les forks privés des ransomware operators tournent en continu. Considérez que tout secret présent dans un repo concerné est compromis dès maintenant.
Faut-il prévenir mes clients freelance si j’ai un doute sur l’exposition ?
Oui, et c’est non négociable contractuellement. Le RGPD (article 33) et la directive NIS2 imposent une notification sous 72h si une fuite a un impact sur des données personnelles ou la continuité d’un service essentiel. En tant que freelance, votre devoir de conseil engage votre responsabilité civile professionnelle. Un email écrit, daté, listant les actions de mitigation que vous engagez, vous protège juridiquement même si l’exposition se révèle finalement nulle. Modèle disponible sur demande.
d-open.org propose-t-elle un audit éclair post-fuite Team PCP ?
Oui, sous forme de sprint 48 heures : inventaire des repos exposés, rotation guidée des secrets (PAT, OAuth, secrets Actions, tokens cloud), audit des workflows GitHub Actions pour pinning SHA et permissions minimales, analyse forensique des derniers commits suspects, recommandations runbook. Forfait 1 800 à 3 200 EUR pour PME / freelance avec moins de 50 repos. Livré sous 48h ouvrées.