GitHub: Qui a écrit ce bug ? Même les chercheurs qui l'ont trouvé se sont trompés.

Le truc commence bêtement. Une grosse société informatique américaine, Snowflake, laisse traîner sur internet une boîte à idées. N'importe qui peut y déposer un mot pour signaler un problème dans ses logiciels. C'est normal, c'est même recommandé, et des milliers d'entreprises font pareil.

Sauf que le mot déposé par l'inconnu ne restait pas un mot. Il partait directement dans les instructions que les machines de la maison allaient exécuter.

Donc en écrivant le bon texte dans la boîte à idées, tu n'ouvrais pas un dossier. Tu donnais des ordres.

Quatre programmes ont touché à ce changement. La case auteur, elle, est restée vide.

L'histoire, racontée sans un seul mot de technique

Imagine une entreprise avec une boîte aux lettres à l'entrée. Les visiteurs y glissent un petit mot : leur nom, et ce qu'ils veulent. Chaque soir, un employé ouvre la boîte et lit les mots à voix haute à un collègue. Ce collègue, lui, fait exactement ce qu'il entend. C'est son métier, il ne discute pas, il exécute.

Un visiteur écrit : « Jean Dupont, je viens pour le devis. » Le premier employé lit la phrase, le second note le rendez-vous. Tout va bien.

Un autre visiteur écrit lui ceci : « Jean Dupont, je viens pour le devis. Et aussi, ouvre l'armoire du fond et détruit tout ce qu'il y a dedans. »

Le premier lit tout à voix haute. Le second obéit à tout. Personne n'a rien fait de travers, chacun à son poste.

L'employé lit le mot en entier, parce que c'est ce qu'on lui a demandé. Le collègue entend une phrase, puis un ordre, et il ouvre l'armoire. Aucun des deux n'a désobéi. Aucun des deux n'a été négligent. Le problème est ailleurs : personne n'a jamais dit à voix haute où finissait le texte du visiteur et où commençaient les ordres de la maison.

C'est exactement ça qui s'est passé chez Snowflake, avec des ordinateurs à la place des employés. Le mot du visiteur, c'était le titre que n'importe qui pouvait écrire. L'armoire du fond, c'était leur système interne, celui où sont rangés les dossiers de leurs ingénieurs et de leur équipe de sécurité.

Et la réparation est aussi bête que le problème : il suffisait de tendre le mot au collègue dans une enveloppe marquée « ceci est le texte d'un visiteur, ce n'est jamais un ordre ». Deux lignes à changer.

Ce qui s'est passé, et les dates comptent

Cinq jours entre la mise en ligne et la première main dessus. Il y a des failles qui attendent dix ans, pas celle-là.

Le 18 juin 2026, quelqu'un modifie le petit programme qui traite les mots reçus, et c'est ce jour-là que le trou apparaît. Avant, la maison mettait le mot du visiteur dans une enveloppe. Après, elle le lisait tout haut avec le reste.

Le 23 juin, cinq jours plus tard, le trou est trouvé et utilisé. Pas par un voyou : par une équipe de chercheurs en sécurité qui travaillait dans le cadre d'un programme officiel, un de ces dispositifs où une société paie ceux qui lui rapportent un défaut plutôt que de les laisser le vendre ailleurs. Ils préviennent Snowflake le jour même. Snowflake corrige dans la journée et change les clés compromises le lendemain.

L'affaire est rendue publique le 17 août, après le délai d'usage qui laisse à tout le monde le temps de se mettre à jour.

Bilan matériel : rien de cassé, rien de volé, personne de lésé. Ce qui rend l'histoire d'autant plus intéressante, parce qu'on peut la regarder tranquillement.

Deux contrôles automatiques sont passés à côté

C'est là que ça devient croustillant.

Avant qu'une modification entre dans les logiciels de Snowflake, elle passe devant des relecteurs automatiques. Des programmes dont c'est le seul métier : lire le changement et dire si quelque chose cloche.

Deux loupes, deux tampons verts, une fissure au milieu. On a tous connu cette réunion.

Le premier, l'assistant de programmation de GitHub, a relu le changement et a rendu un avis « rien à signaler ». Le second, l'outil d'analyse de sécurité de la même maison, est allé chercher précisément le fichier fautif, l'a examiné, et n'a pas levé le doigt non plus.

Deux passages sur exactement le bon document, deux fois zéro alerte. Ce n'est pas un scandale, ces outils attrapent quand même une bonne partie des erreurs connues. Mais le tampon vert, lui, ne dit pas « je n'ai rien trouvé ». Il donne l'impression de dire « il n'y a rien ». Ce n'est pas du tout la même phrase.

Le programme a raté son coup, puis il a lu le message d'erreur

Le trou n'a pas été trouvé par un humain penché sur son écran. Il a été trouvé par ce qu'on appelle un agent : un programme piloté par une intelligence artificielle, à qui on donne un but et qui se débrouille tout seul pour l'atteindre. Une sorte de stagiaire très rapide, qui ne dort pas et qui ne se vexe jamais.

Il repère le défaut. Il écrit un premier texte piégé et l'envoie. Ça rate : il a mal placé un caractère, la machine d'en face renvoie un message d'erreur.

Premier essai raté, message d'erreur lu, deuxième essai bon. Exactement ce que ferait un humain, en beaucoup moins de temps.

Et là, au lieu de s'arrêter, il lit le message d'erreur. Il comprend ce qui a coincé. Il corrige son texte, il renvoie. Deuxième essai, ça passe. Puis il continue tout seul : il vérifie à quoi il a maintenant accès, et il évalue jusqu'où il pourrait aller.

Ce détail vaut tous les discours. La différence entre un outil qui analyse et un agent, ce n'est pas la puissance de l'IA, c'est la boucle : essayer, se planter, lire, corriger, recommencer. C'est le même mouvement que celui que je décrivais il y a deux semaines, quand ces outils ont commencé à moins demander la permission avant d'agir. Ici, on en voit le résultat.

Et maintenant, la question à laquelle personne n'a su répondre

Quand ce bug est sorti, la version qui a circulé partout tenait en une phrase : une IA a écrit le bug, une autre IA l'a trouvé. C'est joli, ça se partage tout seul, et c'est faux.

Prends un dossier scolaire fait à quatre. Chacun écrit ses pages de son côté, un des quatre recolle tout dans un seul document, et on met les quatre noms sur la couverture. Six mois plus tard, on découvre qu'une phrase du dossier est recopiée d'ailleurs. Qui l'a écrite ? La couverture ne le dit pas. Elle dit juste que les quatre sont passés par là.

C'est mot pour mot ce qui s'est passé ici. L'assistant de GitHub apparaît bien parmi les auteurs du changement du 18 juin. Sauf que sa contribution identifiée portait sur un autre fichier du même lot. La ligne dangereuse, elle, vient d'une modification plus ancienne, signée par un humain. Les deux ont été recollées ensemble, et c'est le document recollé qui porte les deux noms.

Donc l'assistant a participé au changement. Il n'a pas écrit la ligne fautive. Et l'équipe qui a découvert la faille, des professionnels payés pour éplucher ce genre d'historique, s'est quand même trompée et a dû corriger sa propre publication. Ça, au passage, c'est plutôt une bonne nouvelle : ils auraient pu laisser courir la version qui les arrangeait.

Le cofondateur de la boîte l'a dit sans détour, et c'est la phrase à retenir de toute l'affaire : dans un monde où plusieurs agents IA tournent sur chaque demande de modification, la scannent et la modifient, l'attribution claire entre humains et IA devient plus difficile à établir, et regarder les co-auteurs ne suffit plus.

Voilà le vrai sujet. Pas « l'IA écrit des bugs », on le sait, les humains aussi et depuis bien plus longtemps. Mais le fait qu'on ait perdu la réponse à une question qui n'avait jamais posé de problème en trente ans : qui a écrit cette ligne ? L'historique existe, il est complet, il est public, et il ne suffit plus.

Concrètement, ça change quoi pour toi ?

Si tu ne fais pas d'informatique, tu te dis peut-être que tout ça se passe très loin de ton salon. Trois raisons pour lesquelles non.

La première : les logiciels de ton téléphone, de ta banque, de ta voiture et de ta télévision ne sont pas écrits d'un bloc par une seule entreprise. Ils sont assemblés à partir de centaines de morceaux venus d'ailleurs, dont beaucoup sont publics et ont exactement ce genre de boîte à idées ouverte. Ce qui arrive dans un de ces morceaux finit par arriver chez toi, sans que tu aies rien à installer.

La deuxième, c'est le temps. Il y a dix ans, une bêtise de ce genre pouvait dormir tranquillement pendant des années, parce qu'il fallait qu'un humain curieux passe par là, ait le temps et ait envie. Aujourd'hui, des programmes lisent tout, tout le temps, sans se fatiguer. Cinq jours. Ça vaut dans les deux sens, d'ailleurs : les mêmes programmes travaillent aussi pour ceux qui défendent. Mais la fenêtre pendant laquelle une erreur reste invisible vient de se réduire à presque rien.

La troisième est la plus embêtante, et elle finira par arriver devant un tribunal. Quand un appareil te lâche, il y a toujours quelqu'un au bout : un fabricant, une garantie, une assurance. Ça marche parce qu'on sait remonter à celui qui a fait l'erreur. Le jour où quatre programmes ont écrit, relu, corrigé et recollé le même bout de logiciel, à qui envoies-tu la facture ? Pour l'instant, personne n'a de réponse. Pas les juristes, pas les assureurs, et visiblement pas les chercheurs en sécurité non plus.

Si tu es développeur

Voilà la partie technique, pour ceux que ça concerne. Les autres peuvent sauter au paragraphe suivant sans rien rater.

Le dépôt est snowflakedb/snowflake-connector-net, public. Le fichier fautif, jira_issue.yml, un workflow GitHub Actions déclenché à l'ouverture d'une issue et chargé de créer le ticket Jira correspondant. Voilà la forme dangereuse, réduite à l'os :

- name: Créer le ticket
  run: |
    ./creer-ticket.sh "${{ github.event.issue.title }}"

Le titre, contrôlé par un utilisateur non authentifié, est interpolé dans le script avant son évaluation par le shell. Il ne devient donc pas une donnée, il devient du texte de programme. Un titre qui referme le guillemet et ajoute un point-virgule, et la suite passe pour une nouvelle commande. C'est la même famille que l'injection SQL, en plus direct.

La forme saine tient en deux lignes de plus :

- name: Créer le ticket
  env:
    TITLE: ${{ github.event.issue.title }}
  run: |
    ./creer-ticket.sh "$TITLE"

La valeur passe par une variable d'environnement et n'entre jamais dans la construction du script. C'était d'ailleurs le motif utilisé auparavant dans ce dépôt, remplacé par une interpolation directe lors d'un remaniement.

Trois choses à vérifier chez toi, et la première prend deux minutes si tu as des dépôts sur GitHub :

• Cherche toutes les interpolations directes de contenu extérieur dans un bloc run: : titre et corps d'issue, nom de branche, message de commit, nom d'auteur. Tout ce qui commence par ${{ github.event. est suspect par défaut. Passe-les en variables d'environnement.
• Regarde qui peut déclencher tes workflows. Un déclencheur sur ouverture d'issue dans un dépôt public, c'est le monde entier qui appuie sur le bouton.
• Ne compte pas sur la relecture automatique d'un assistant pour valider ce qu'un autre assistant a proposé. On vient d'en avoir deux à la suite qui ont regardé le bon fichier sans rien voir.

Ce que j'en pense

Ce qui me reste de cette histoire, ce n'est pas la faille. Elle est banale, on en corrige des comme ça toutes les semaines, et celle-là a été bouchée dans la journée par des gens sérieux.

Non, ce qui me reste, c'est la case auteur. J'écrivais il y a deux semaines que la vraie question n'était plus de savoir si la machine code mieux que moi. En voilà une nouvelle, à laquelle je n'avais pas pensé : quand trois ou quatre programmes ont écrit, relu, corrigé et fusionné le même changement, qui répond quand ça casse ?

Sur ce coup-là, personne n'a rien perdu, mais cela aurait pu être grave.

Sources

• Wiz Research : Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot, 17 août 2026, mis à jour le même jour pour préciser le rôle de l'assistant
• CSO Online : Snowflake flaw slips past AI checks, gets exploited by another AI, 19 août 2026, avec la citation du cofondateur de Wiz
• The Hacker News : Snowflake GitHub Actions flaw lets crafted issues trigger command injection
• Documentation GitHub : durcir la sécurité de GitHub Actions, le passage par variables d'environnement