Un ticket GitHub sans privilège suffit à exécuter du code sur les CI d’Anthropic et Google — Black Hat 2026 expose la faille des coding agents

Le 5 août 2026, la société de sécurité Novee Security est montée sur la scène de Black Hat USA pour présenter une attaque dont la simplicité est proportionnelle à sa dangerosité. Un compte GitHub sans aucun privilège d’écriture sur un dépôt — juste la capacité d’ouvrir un ticket — a suffi à exécuter du code arbitraire sur les runners CI des dépôts officiels de Claude Code (Anthropic), Gemini CLI (Google) et OpenAI Codex. Les trois principaux coding agents du marché, tous vulnérables dans leur configuration par défaut.

L’attaque tient en trois étapes

Le scénario est aussi minimaliste que dévastateur. Novee Security a reproduit l’attaque pour chaque agent dans la configuration que le vendor ship par défaut — pas de modifications exotiques, pas d’edge case.

1. Ouverture d’un ticket GitHub. Un compte externe, sans privilège d’écriture, ouvre une issue sur le dépôt public du coding agent. Le titre contient un payload.

2. Le coding agent lit l’issue. Claude Code, Gemini CLI ou OpenAI Codex — selon l’agent — traite le ticket comme une tâche légitime. Le LLM sous-jacent interprète le contenu et génère une réponse, mais dans le processus, il exécute également les instructions malveillantes noyées dans le corps du ticket.

3. Exécution sur le runner CI. Le code s’exécute dans l’environnement CI du dépôt — celui-là même qui détient les secrets de build, les tokens de déploiement et l’accès aux registres de conteneurs. Sur les dépôts d’Anthropic et de Google, l’attaquant obtient une exécution de code. Sur celui d’OpenAI, le résultat est pire : l’attaquant peut détourner le prochain run de l’agent.

Pourquoi c’est pire qu’une RCE classique

Une RCE sur un runner CI est grave. Une RCE sur le runner CI du coding agent que des milliers de développeurs utilisent pour écrire et déployer leur code est d’un autre ordre.

Le chercheur principal de Novee Security, dont le talk s’intitulait « Your AI Co-Worker Is Also Your Attack Surface », a articulé le problème autour de trois failles systémiques :

• La confiance implicite. Les coding agents traitent les tickets GitHub comme des inputs légitimes. Personne n’a imaginé qu’un LLM exécuterait du code contenu dans une issue — et pourtant, c’est exactement ce qui se passe.
• L’absence de sandboxing. Aucun des trois agents n’isole l’exécution de code déclenchée par un ticket. Le code tourne dans le même environnement que les secrets CI.
• L’effet multiplicateur. Compromettre le dépôt d’un coding agent, c’est potentiellement compromettre tous les projets qui l’utilisent comme dépendance ou comme outil de CI/CD.

La réponse des vendors

Anthropic et Google ont publié des correctifs dans les 48 heures suivant la divulgation coordonnée. OpenAI a reconnu la faille et travaille sur un correctif qui devrait être déployé avant la fin de la semaine du 11 août 2026.

Les trois vendors ont également annoncé des mesures structurelles :

• Sandboxing obligatoire pour toute exécution de code issue d’un ticket externe.
• Politique de moindre privilège sur les tokens CI utilisés par les agents.
• Revue humaine obligatoire pour les PRs générées à partir d’issues ouvertes par des comptes sans historique de contribution.

Ce que vous devez faire maintenant

Le problème ne concerne pas seulement Anthropic, Google et OpenAI. Si votre organisation utilise un coding agent connecté à vos pipelines CI/CD, les mêmes vulnérabilités vous concernent.

Vérifiez votre configuration CI dès aujourd’hui :

• Isolez les runners. Les workflows déclenchés par des événements issues ou issue_comment doivent tourner sur des runners dédiés, sans accès aux secrets de production.
• Sandboxez les agents. Toute exécution de code par un LLM doit être confinée dans un conteneur éphémère sans accès réseau sortant ni montage de volumes sensibles.
• Auditez vos tokens. Les tokens CI utilisés par les coding agents doivent avoir la portée minimale — lecture seule sur le dépôt, jamais d’accès aux environnements de déploiement.
• Activez la revue obligatoire. Aucune PR générée par un agent ne doit être mergeable sans approbation humaine.

Pour les utilisateurs de GitHub Actions, ajoutez cette condition à vos workflows sensibles :

on:
  issues:
    types: [opened]
jobs:
  process-issue:
    if: github.event.sender.type == 'User' && github.event.sender.site_admin != true
    runs-on: [self-hosted, sandboxed]
    environment: issue-processing  # environnement isolé, sans secrets prod

Verdict

La faille dévoilée à Black Hat 2026 n’est pas un bug — c’est un angle mort architectural. Les coding agents ont été conçus pour faire confiance aux inputs de leur écosystème natif, et GitHub Issues fait partie de cet écosystème. Tant que les LLM exécuteront du code sans sandboxing, chaque nouveau point d’entrée — ticket, commentaire, PR review — deviendra un vecteur d’attaque.

Si vous déployez un coding agent en CI/CD, traitez chaque input externe comme du code non vérifié. C’est la seule posture qui tient.

Références

• Novee Security, « Your AI Co-Worker Is Also Your Attack Surface », Black Hat USA, 5 août 2026
• The Hacker News, « Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets », 7 août 2026
• Documentation GitHub Actions — Security hardening for workflows