GitHub: Who wrote this bug? Even the researchers who found it got it wrong.

It starts out stupidly. A large American tech company, Snowflake, leaves a suggestion box lying around on the internet. Anyone can drop in a note to report a problem in its software. That's normal, it's even recommended, and thousands of companies do the same.

Except the note left by the unknown person did not remain a note. It went straight into the instructions that the company's machines were going to execute.

So by writing the right text in the suggestion box, you were not opening a ticket. You were giving orders.

Four programs touched this change. The author box, for its part, remained empty.

The story, told without a single technical word

Imagine a company with a mailbox at the entrance. Visitors slip a little note into it: their name, and what they want. Every evening, an employee opens the box and reads the notes aloud to a colleague. That colleague does exactly what he hears. It's his job, he does not argue, he carries it out.

A visitor writes: "Jean Dupont, I'm here for the estimate." The first employee reads the sentence, the second writes down the appointment. Everything is fine.

Another visitor writes this instead: "Jean Dupont, I'm here for the estimate. And also, open the cupboard at the back and destroy everything inside it."

The first one reads everything aloud. The second one obeys everything. Nobody did anything wrong, everyone was at their post.

The employee reads the entire note, because that's what he was asked to do. The colleague hears a sentence, then an order, and he opens the cupboard. Neither of them disobeyed. Neither of them was careless. The problem lies elsewhere: nobody ever said aloud where the visitor's text ended and the company's orders began.

That's exactly what happened at Snowflake, with computers in place of the employees. The visitor's note was the title anyone could write. The cupboard at the back was their internal system, the one where the files of their engineers and security team are kept.

And the fix is as stupidly simple as the problem: all they had to do was hand the note to the colleague in an envelope marked "this is a visitor's text, it is never an order". Two lines to change.

What happened, and the dates matter

Five days between being put online and the first person getting their hands on it. There are vulnerabilities that wait ten years, not this one.

On June 18, 2026, someone modifies the little program that processes the notes received, and that is the day the hole appears. Before that, the company put the visitor's note in an envelope. After that, it read it out loud along with the rest.

On June 23, five days later, the hole is found and used. Not by some hoodlum: by a team of security researchers working as part of an official program, one of those schemes where a company pays people who report a flaw to it rather than letting them sell it elsewhere. They warn Snowflake that very same day. Snowflake fixes it that day and changes the compromised keys the next day.

The story was made public on August 17, after the customary delay that gives everyone time to catch up.

Material assessment: nothing broken, nothing stolen, nobody harmed. Which makes the story all the more interesting, because we can look at it calmly.

Two automated checks missed it

This is where it gets juicy.

Before a modification gets into Snowflake's software, it passes in front of automated reviewers. Programs whose only job is to read the change and say whether something is wrong.

Two magnifying glasses, two green stamps, a crack in the middle. We've all been in that meeting.

The first, GitHub's programming assistant, reviewed the change and gave a "nothing to report" verdict. The second, the security analysis tool from the same company, went looking for exactly the faulty file, examined it, and didn't raise its hand either.

Two passes over exactly the right document, zero alerts both times. This isn't a scandal, these tools still catch a good number of known errors. But the green stamp doesn't say "I found nothing". It gives the impression of saying "there is nothing". Those are not at all the same sentence.

The program missed its shot, then read the error message

The hole wasn't found by a human hunched over their screen. It was found by what is called an agent: a program controlled by artificial intelligence, which is given a goal and figures out on its own how to reach it. A sort of very fast intern, who doesn't sleep and never gets offended.

It spots the flaw. It writes a first piece of malicious text and sends it. It fails: it put a character in the wrong place, the machine on the other end sends back an error message.

First attempt failed, error message read, second attempt worked. Exactly what a human would do, in much less time.

And then, instead of stopping, it reads the error message. It understands what went wrong. It corrects its text, it sends it again. Second attempt, it works. Then it carries on all by itself: it checks what it now has access to, and it assesses how far it could go.

This detail is worth all the speeches. The difference between a tool that analyzes and an agent isn't the power of the AI, it's the loop: try, screw up, read, correct, try again. It's the same movement as the one I was describing two weeks ago, when these tools started asking for permission less often before taking action. Here, we can see the result.

And now, the question nobody could answer

When this bug came out, the version that spread everywhere fit into one sentence: one AI wrote the bug, another AI found it. It's pretty, it shares itself, and it's false.

Take a school project made by four people. Each one writes their pages separately, one of the four pastes everything back together into a single document, and we put all four names on the cover. Six months later, we discover that one sentence in the project was copied from somewhere else. Who wrote it? The cover doesn't say. It just says that all four passed through there.

That's word for word what happened here. GitHub's assistant is listed among the authors of the June 18 change. Except its identified contribution concerned another file in the same batch. The dangerous line itself comes from an older modification, signed by a human. The two were pasted back together, and it's the pasted-together document that carries both names.

So the assistant took part in the change. It did not write the faulty line. And the team that discovered the flaw, professionals paid to pore over this kind of history, still got it wrong and had to correct its own publication. That, by the way, is rather good news: they could have let the version that suited them stand.

The company's cofounder said it plainly, and it's the sentence to remember from the whole affair: in a world where several AI agents run on every modification request, scan it and modify it, clear attribution between humans and AI becomes harder to establish, and looking at the co-authors is no longer enough.

That's the real subject. Not “AI writes bugs”, we know that, humans do too and have been doing it for much longer. But the fact that we've lost the answer to a question that had never caused a problem in thirty years: who wrote this line? The history exists, it's complete, it's public, and it's no longer enough.

Concretely, what does that change for you?

If you don't do computer science, you might tell yourself that all this is happening very far from your living room. Three reasons why not.

The first: the software on your phone, in your bank, in your car and on your television isn't written in one block by a single company. It's assembled from hundreds of pieces that came from elsewhere, many of them public and having exactly this kind of open idea box. What happens in one of those pieces eventually reaches you, without you having to install anything.

The second is time. Ten years ago, a stupid mistake like this could quietly sleep for years, because a curious human had to come along, have the time and feel like it. Today, programs read everything, all the time, without getting tired. Five days. It works both ways, by the way: the same programs also work for the people defending themselves. But the window during which an error remains invisible has just shrunk to almost nothing.

The third is the most troublesome, and it will eventually end up in court. When a device lets you down, there's always someone at the other end: a manufacturer, a warranty, an insurance company. It works because we know how to trace the error back to the person who made it. The day four programs have written, reviewed, corrected and pasted back together the same piece of software, who do you send the bill to? For now, nobody has an answer. Not the lawyers, not the insurers, and apparently not the security researchers either.

If you're a developer

Here's the technical part, for those concerned. The others can skip to the next paragraph without missing anything.

The repository is snowflakedb/snowflake-connector-net, public. The faulty file, jira_issue.yml, a GitHub Actions workflow triggered when an issue is opened and tasked with creating the corresponding Jira ticket. Here's the dangerous form, reduced to the bare bones:

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

The title, controlled by an unauthenticated user, is interpolated into the script before its evaluation by the shell. It therefore doesn't become data, it becomes program text. A title that closes the quote and adds a semicolon, and the rest is treated as a new command. It's the same family as SQL injection, more direct.

The safe form takes two more lines:

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

The value passes through an environment variable and never enters the construction of the script. It was actually the pattern previously used in this repository, replaced by direct interpolation during a restructuring.

Three things to check on your side, and the first takes two minutes if you have repositories on GitHub:

• Look for all direct interpolations of external content in a run: block: issue title and body, branch name, commit message, author name. Anything that starts with ${{ github.event. is suspicious by default. Pass them through environment variables.
• Look at who can trigger your workflows. A trigger on issue opening in a public repository means the whole world is pressing the button.
• Don't rely on an assistant's automatic review to validate what another assistant proposed. We just had two in a row that looked at the right file without seeing anything.

What I think

What remains with me from this story isn't the flaw. It's ordinary, we fix ones like it every week, and this one was plugged the same day by serious people.

No, what remains with me is the author field. I wrote two weeks ago that the real question was no longer whether the machine codes better than I do. Here's a new one, which I hadn't thought of: when three or four programs have written, reviewed, fixed and merged the same change, who answers when it breaks?

In this case, nobody lost anything, but it could have been serious.

Sources

• Wiz Research : Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot, August 17, 2026, updated the same day to clarify the assistant's role
• CSO Online : Snowflake flaw slips past AI checks, gets exploited by another AI, August 19, 2026, with the quote from Wiz's cofounder
• The Hacker News : Snowflake GitHub Actions flaw lets crafted issues trigger command injection
• GitHub Documentation: hardening GitHub Actions security, the passage about using environment variables