6 ms·
AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira
- sippeangelo 2mo agoThe title is actually "Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Due to an AI-Generated GitHub Copilot Autofix"
- galnagli 2mo agoToo long for hackernews :(
- diego_sandoval 2mo agoI know like 3 of those words.
- forestry 2mo agoPeer review of changes is still important.
- Twirrim 2mo agoYou can't rely on people spotting the significance of such changes
- fn-mote 2mo ago^^ Absolutely. Nothing in the PR jumps out as a red flag. Unless you know how the internals work, I suppose.
- chrisjj 2mo ago> Nothing in the PR jumps out as a red flag. Made by AI?
- larsonian 2mo agoAre you kidding? It's a very obvious case of quote injection. Not some subtle race condition or anything.
- joombaga 2mo agoI think it's obvious too. I'd call out any case of `${{ }}` interpolation in a `run` block, and it's something I watch for in PRs. I also know other people don't watch for this, as I've corrected it about a hundred times. Over the last 10 years my average colleague understands less and less about injection or to watch for it at layer boundaries.
- bigfishrunning 2mo agoShouldn't anyone reviewing such a PR know how the internals work?
- koiueo 2mo agoNot anymore, it seems
- eithed 2mo agoTests would have caught it = https://github.com/rhysd/actionlint https://github.com/rhysd/actionlint injection check
- thejosh 2mo agoalso been a huge fan of zizmor (https://github.com/zizmorcore/zizmor https://github.com/zizmorcore/zizmor) lately, basically: "am I going to footgun myself?"
- dv_dt 2mo agoI have been talking to people who want to autoreview and autoapprove "minor" AI prs. For security especially, I think if the models weren't enough to prevent the issues, they aren't enough to judge what is minor.
- Rumudiez 2mo agoMulti-model cross-review is important
- acedTrex 2mo agoIt's not actually, thats just shoving more shit into the shit pipeline. Humans need to review this stuff yall there's no way around that, apparently to some, very inconvenient reality.
- devin 2mo agoIt’s clear that they want this to be true so bad that they’re just not going to do it, and will spend a ton of money on quality gates and mitigation strategies instead of just reading some code.
- _joel 2mo agoI'm all for using a council of LLMs, I wrote a tool for it https://github.com/joelio/owl https://github.com/joelio/owl - but you still need to read through PRs yourself, at the very least.
- throwlifeaway 2mo ago[dead]
- deleted 2mo ago[deleted]
- chrisjj 2mo ago> a single quote in the title breaks out of echo '...' and allows arbitrary command execution. Quote injection still alive and well in 2026. Gawd.
- danqqqq 2mo ago[dead]
- myself248 2mo agoIt's appalling that computing in general, and unix in particular, seems to have this habit of intermingling payload and overhead. It's like in-band signalling in the telephone network, where if you whistled the right tones into your call, you could affect the way the network processed said call. Except Ma Bell responded to that system being exploited by designing a comprehensive overhaul of the way signalling was handled, and spent a squadzillion dollars upgrading millions of tons of switching equipment to categorically exclude that entire class of attack from ever being possible. Software, on the other hand, would need to replace no equipment whatsoever. Existing processors are perfectly capable of running code that handles the length of a string separately from its contents. There are existing languages that do this, they're just.... not used. String escapes and buffer overflows exist, going on decades now, due to nothing more than laziness, inertia, and negligence.
- simoncion 2mo ago> It's like in-band signalling in the telephone network... The major LLM providers claim that they are very committed to security and that their products are very dangerous and capable of great harm. Given that their tools do what Ma Bell's systems did in the mid-1900s, [0] -which the entire software world relearned was a terrible idea by the early 1990s- they are definitely 1) Lying about the extent of their commitment to security 2) Lying about the extent of the harm that their tools are capable of 3) Both My money is on #3. Because of the fact that -in the absence of unambiguous laws that require meaningfully-severe punishment- even the most fucknasty and amateur hour security failures nearly always have little to no impact on the company that causes them, the major LLM providers have absolutely done the smart thing by providing commercial tools that have remote code execution vulns that would automatically give them a Critical CVSS score. To put it another way: "the market" has no idea how to evaluate computer security claims. Because of this, every dollar you spend on proactively fixing security problems is nearly always a dollar wasted... it's better to wait until someone important gets Big Mad before spending the money. Does this make the world worse? Absolutely! Does this make companies selling software and software services much more money? Definitely! [0] If the major LLM providers did separate unsanitized data from program instructions and ensure that the two are never mixed, things like [1] would not be possible. [1] <https://www.schneier.com/blog/archives/2026/08/prompt-injections-for-defense.html https://www.schneier.com/blog/archives/2026/08/prompt-inject...>
- teraflop 2mo ago> The workflow had an if: condition that appeared protective: > if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') > However, on issues events, github.event.pull_request is always null. This is extra dumb because even if you thought this condition was correctly testing the user's identity, it shouldn't have "appeared protective" upon even a moment's thought. If it worked correctly, it would obviously just exclude one bot user while allowing all other users, so it wouldn't provide any protection at all. But more likely, this condition was never intended to be "protective" at all, and it's only being described that way because the writeup is LLM slop.
- mjr00 2mo agoIt's interesting to look at what was being attempted when the vulnerability was introduced[0] > Workflows like jira_close.yml use deprecated atlassian JIRA actions and have a dependency on the gh-actions repo. This is not ideal and unecessarily complex. PR updates jira_close workflow to use direct API calls via curl. It preserves custom fields used too. I won't speak to this projects' management and how they prioritize things, but from my own experience, pre-AI, this type of change would have been firmly in the "this is a minor annoyance, put it in the Tech Debt Backlog alongside the 50000 other tickets" and never actually done. The cost of a human investing the time understanding how to fix the problem, doing code changes, testing them, and deploying them is just way too high for what actual value this change brings, which is close to nothing. Now with AI, it's as simple as firing up an agent and telling them to make a change; as much effort as writing that backlog Jira ticket in the first place. Similar to the problem open source is having with low-value PRs, companies are going to have to start realizing that code is not free to review or maintain, even when it's generated for ~free, in their internal processes. Just because an agent can fix a minor tech debt annoyance with a few lines of instructions doesn't mean it should. [0] https://github.com/snowflakedb/snowflake-connector-net/pull/1218 https://github.com/snowflakedb/snowflake-connector-net/pull/...
- fg137 2mo agoI have seen plenty of "my backlog has never been shorter" comments here. I'm interested in how that turns out 6 months later. In my team, we have plenty of enhancement requests from users. We address those that make obvious sense and are trivial to do but withhold from others, even though the code change itself is likely small. Because we don't know if there is more than a single user that can actually benefit from it, if it has unintended consequences, or if it causes maintainence issue down the road.
- ctoth 2mo ago> but withhold from others, even though the code change itself is likely small. Prediction: programming is going to change massively not only because the cost of creating code will go down, but because people are so tired of this sort of gatekeeping "we know better" from programmers.
- mhrsntrk 2mo ago[flagged]
- procone 2mo agoYAML is a nightmare fuel spec. In its quest to make markup "human readable", it has created countless footguns. I honestly prefer XML at this point.
- fmbb 2mo agoIt’s find for actions and workflows as long as you do no interpolation and logic. Better move as much of that as possible into your own scripts. And your scripts can be portable between forges, and even run locally!
- NewJazz 2mo agoAssigning an env var to an empty variable (env: { myvar: ${{unsetfoo}} }) should trigger an error, not silently pass an empty string.
- RHSeeger 2mo agoThe YAML spec/parse _itself_ does interpolation and logic - incorrectly in some cases. YAML is pretty much never the right solution.
- formerly_proven 2mo ago> It’s find for actions and workflows as long as you do no interpolation and logic. How do you specify actions and workflows without interpolation and logic kind sir?
- TheRealPomax 2mo agoNo, Snowflake allowing autofixes compromised their Jira. If you tell someone to shoot you in the foot, and they shoot you in the foot, you shot yourself in the foot, just with more steps. If someone else finds the memo that says you've set up foot shooting as a service, and then they trigger that service, you still shot yourself in the foot.
- rawgabbit 2mo agoHelp me understand. Snowflake configured their Github repo to allow auto fixes by Copilot. It got merged automatically without anyone's review? And introduced essentially script-injection vulnerability through the title field? If this is the case, I would say Snowflake should shut down its repo and get off Github asap.
- rafram 2mo agoNo. A Snowflake maintainer opened a PR, Copilot suggested a change (introducing a vulnerability), the maintainer accepted and committed it to their PR, and another Snowflake maintainer approved and merged the PR.
- lelanthran 2mo agoAnd that's going to continue because no one is reading the code even when they approve it. It's a very strange thing indeed, but not unexpected: we warned that skills not used will eventually atrophy.
- rawgabbit 2mo agoThanks.
- otterley 2mo agoI don't see anything in the article that says that two maintainers, let alone one, reviewed the PR manually and approved it before merging. Where are you getting this information from?
- antiloper 2mo agoSomeone forgot to add "make no mistakes!" when triggering autofix /s
- vultour 2mo agoThe first linked PR (#1218) has only one commit co-authored by Copilot and it's not related to the vulnerability, and neither are the other suggestions in the PR. Am I missing something?
- galnagli 2mo agoGithub is having some problems -- will check! thanks a lot!
- vultour 2mo agoI must be too tired because I cannot figure out what happened in that pull request. The PR/source branch was over a year old with none of the commits adding up to the full diff. There is [1], which introduced the vulnerability but didn't remove the environment variables above, then master is merged into it via [2] (but still doesn't show the variables being removed), yet in the full PR diff they're gone. In any case, I'm pretty sure you misattributed the vulnerability to Copilot because the PR got squash-merged and _all_ of the changes were then attributed to every contributor in that PR, despite Copilot only appearing on one of the commits. [1] https://github.com/snowflakedb/snowflake-connector-net/commit/094038e59d112906f1790acf39999045fc0df243 https://github.com/snowflakedb/snowflake-connector-net/commi... [2] https://github.com/snowflakedb/snowflake-connector-net/commit/51dc7381e64c60033ec10c52939ff4ae1d3d83ab https://github.com/snowflakedb/snowflake-connector-net/commi...
- croemer 2mo agoYes, it's misattributed, a human introduced it: https://github.com/snowflakedb/snowflake-connector-net/pull/1218/changes/094038e59d112906f1790acf39999045fc0df243 https://github.com/snowflakedb/snowflake-connector-net/pull/...
- galnagli 2mo agoThanks @vultour and croemer for your proactiveness -- you are correct,I updated the blog to clarify that Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities, it's unclear whether the code-change was AI-Assisted
- inahga 2mo agoI probably would have made the same mistake. It is negligent to write GitHub Actions without using static analysis. Use zizmor in CI https://github.com/zizmorcore/zizmor https://github.com/zizmorcore/zizmor error[template-injection]: code injection via template expansion --> .github/workflows/jira_issue.yml:24:29 | 22 | run: | | --- this run block 23 | # Escape special characters in title and body 24 | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g") | ^^^^^^^^^^^^^^^^^^^^^^^^ may expand into attacker-controllable code | = note: audit confidence → High = note: this finding has an auto-fix
- madeofpalk 2mo agoGithub Actions is actually so incredibly scary to have on public repo. It's full of so many footguns that's far from obvious. It's a shame Github is buried under their current server issues, because it would be great to get improvements all of this - at least warning/erroring on these sorts of things themselves.
- btown 2mo agoThis is a really cool tool! Would zizmor have caught the below as well? From the article: > The workflow had an if: condition that appeared protective: > if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') > However, on issues events, github.event.pull_request is always null. So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is always true, and every GitHub user passes the gate. Speaking broadly: it's a massive reminder that AI is trained on a veritable mountain of insecure GitHub Actions examples, many of which "fail open" in highly unpredictable ways even if widely used. Actions is almost unique in this regard, with the combination of a difficult-to-audit language and the type of privileged RCE environment that makes attackers salivate. (I do think that this stems in part from GitHub's often-inscrutable documentation, and a decision to release Actions without a robust security linting solution, leaving that to the community - but I do understand how it's an uphill battle, and we could have ended up with a much less flexible CI/CD system without this having shipped fast.)
- johnwils 2mo agoThe env + jq was there on purpose. Autofix swapped it for a string in a shell. That's the part that needed a person on the diff.
- MerriBan 2mo ago[flagged]
- beyondscale-sha 2mo ago[dead]
- cowthulhu 2mo agoThis really shows why most languages evaluate all NULL comparisons to FALSE. For something as critical as Actions, it’s crazy to me that they wouldn’t fail-closed, and instead fail open when encountering a null. Scary stuff!
- kozikow 2mo agoIssues will happen AI, or not AI. It's same as "self driving car made an accident"! I'm not saying blindly trusting auto-fix is not bad. I'm just saying that interpreting singular issue as way to downplay AI-assisted engineering without giving a "denominator" is not honest reporting.
- CodeWithLeo 2mo ago[flagged]
- supriyo-biswas 2mo agoPlease do not post LLM generated comments here. Thank you.
- kshacker 2mo agoWhat made you make that assessment?
- bakugo 2mo ago- Three different instances of "The X is Y" in a single short comment - Relatively new account, "AI Engineer building agentic systems" - Most past comments contain em-dashes, more "The X is Y", etc.
- kshacker 2mo agoWhat triggered me to ask was because I can see myself writing that. Not the content but the style. In the old days, I will spend time finessing an argument and feel happy about it. But with the pace nowadays plus the AI, it is a different world, so do not know.
- tripdout 2mo agoWhy is the original pattern (with the env var in double quotes) not vulnerable? Why can you close the single quotes early but you can't just include double quotes in your title? Is it something to do with the GitHub templating?
- benmmurphy 2mo agoi'm not sure if there was an original pattern where the env var was in double quotes. https://github.com/snowflakedb/snowflake-connector-net/pull/1218/files https://github.com/snowflakedb/snowflake-connector-net/pull/... but if you have: X=$(echo "$BLAH") then in bash I believe this is safe, because bash will just substitute this as putting the BLAH variable as the first argument to echo without doing any further parsing. without the double quotes can be safe as well but more risky. X=$(echo $BLAH) and the only difference is bash will split the arguments. so if you have BLAH="x y" then bash will pass two arguments to echo. though, this can be dangerous if the command you are invoking has dangerous command line options. however, they had something similar to: TITLE=$(echo '${{ github.event.issue.title }}') and this ${{ }} is some kind of template substitution that is happening before the command is sent to bash. so if the variable `github.event.issue.title` was `foo bar` then bash sees something like: TITLE=$(echo 'foo bar') and then you start to have problems because `'` can be put into the title to escape. the bash variable substitution will protect you in a lot of cases from command line injection but if you pass user input directly into command evaluation without using variables then bash can't protect you.
- fossilwater 2mo agoGitHub has an article about it https://docs.github.com/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable https://docs.github.com/en/actions/reference/security/secure...
- nevertoolate 2mo agoThey didn’t really sell this PR well: > Workflows like jira_close.yml use deprecated atlassian JIRA actions and have a dependency on the gh-actions repo. This is not ideal and unecessarily complex. And then goes on: > PR updates jira_close workflow to use direct API calls via curl. Duplicating the logic into OUR codebase via a hand rolled curl, so we can get rid of “needless abstractions”. Auch. And of course the whole thing embedded into a yaml file. This code is the typical kaleidoscope sometimes written by junior devs (and LLMs). On review you just kindly ask to be rewritten into a simple program or just close it as the effort doesn’t worth it.
- david_shaw 2mo agoWe're going to see more of this before we see, hopefully, substantially less of it. What I'm seeing now in industry -- and I think this autofix issue is a precise example of it -- is a natural evolution of the "LGTM!" review that's so prevalent in software development and similar disciplines. For years, the dramatic majority of "code review" was a quick glance followed by "Looks good to me." Sure, critical workflows have more scrutiny. Sure, not everyone fell victim to this trap. Sure, there are many exceptions. But it's a meme for a reason: most people weren't really reviewing code assigned to them. They were effectively rubber-stamping most things. So now, in the age of AI, those same people are (sometimes still) expected to be responsible for what their automated developer friend Claude is doing. It's absolutely unreasonable to think that most people are giving the PR more than a glance, and in many organizations they're explicitly trying to remove humans from the loop. One day, AI development and code review will be so good that mistakes like this will be extraordinarily rare. For the near-future, though, I anticipate we'll see more of this before we see less.
- zapataband1 2mo agolol keep dreaming bro, mistakes like these were "extroardinarily rare" before LLM companies reared their thieving hands.
- cj 2mo ago“There is absolutely no way Bitcoin will ever trade for more than $200.. Impossible!” he said.
- preg_match 2mo agoMistakes like this were always common because GHA is evil. If you pull a random action and read the code, chances are it has a few bugs. Vulnerabilities and bugs are becoming rarer due to AI. We’ve already seen the Linux kernel stamp out vulnerability after vulnerability, some of which have existed for over a decade. That doesn’t mean AI just does the work. You need highly skilled engineers leading it. Which the Linux kernel has. But yes, AI is good at reading code and finding defects. It’s good today. Not all models, you need a highly quality model, but yes it’s good today.
- AIorNot 2mo agoSheesh these anti ai posts feel like when I hear about a self driving car is doing something bad.. ie 'man bites dog' vs 'dog bites man' Human responsibility over AI oversight folks.. even forgoing AI, we're still gonna get compromised code either way.. deal with it.
- uygar 2mo ago[flagged]
- ferrow 2mo ago[flagged]
- Helmward 2mo ago[flagged]
- h4kunamata 2mo agoHuman error. AI generated code, must be scanned for code quality, SAST, SCA, etc, just like a developer's code would. It looks like they accepted AI code without verifying. Deserved!
- bobbylarson 2mo ago[dead]
- m4rtink 2mo agoI think GitHub itself could use a nice "Autofix" right about now. ;-)
- tizerluo 2mo ago[flagged]
- qqt 2mo ago[flagged]
- KronisLV 2mo agoWhere’s the bullet point about the way we do programming being horrible? Not even the work, but the tools and languages afforded to us. github.event.issue.title is very obviously data. It should never be POSSIBLE to treat that as an instruction. Furthermore, the idea of any code being able to access the tokens instead of allowlisted software and only with specific commands, and also no housekeeping to prevent the DATA of the token from ever being sent to anything other than a desired host… all of it feels fundamentally wrong. The fact that our OSes don’t help with that is so saddening.
- baobabcat-ai 2mo ago[flagged]
- ferrow 2mo ago[flagged]
- MiroslavPokorny 2mo agoMany OWASP items are injection attacks in some form or another. SQL Injection has been highlighted there and more for over 20 years, and almost nobody learns. Remember that AI learns its code design by reading the code shared by the masses, which means that while this story highlights a single item, a large number of programmers themselves dont know or understanding this basic problem. Its probably also a sad example that AI doesnt think it only copies it doesnt actually think about why something should or shouldnt be done.
- toedat 2mo ago[flagged]
- goodfault 1mo ago[flagged]