Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- No, 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.by TheRealPomax
- Help 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.
by rawgabbit - > a single quote in the title breaks out of echo '...' and allows arbitrary command execution.
Quote injection still alive and well in 2026. Gawd.
by chrisjj - I recently called some website's tech support because their web form was giving error 500. They said I need to make sure there were no single quotes in the form. Horrifying enough, removing the single quote fixed it. So they've either got SQL injection or something even worse.by frollogaston
- It'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.
by myself248 - This 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!
by cowthulhu - The 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.by johnwils
- They 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.
by nevertoolate - > 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.
by teraflop - The title is actually "Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Due to an AI-Generated GitHub Copilot Autofix"by sippeangelo
- I know like 3 of those words.
- Too long for hackernews :(by galnagli
- We'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.
by david_shaw - lol keep dreaming bro, mistakes like these were "extroardinarily rare" before LLM companies reared their thieving hands.by zapataband1
- Yeah I agree and I think code forges as well as AI harnesses are kinda the killer apps of this (relatively short) era.
I think once we figure out how to tighten the loop of user feedback, expert analysis, automatic/static verification and AI generation then technology is going to make another leap.
by worldsayshi - The 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?by vultour
- Github is having some problems -- will check! thanks a lot!by galnagli
- You're correct. The issue was introduced in this commit by a human not by copilot: https://github.com/snowflakedb/snowflake-connector-net/pull/...
However, GitHub Advanced Security, a bot, flagged something but not the real issue. So maybe that bot contributed a false sense of security.
Commit: https://github.com/snowflakedb/snowflake-connector-net/pull/...
by croemer - YAML 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.
by procone - And thus procone spoketh the truth.by cgannett
- Textproto is such much better than YAML for everything that YAML is used for. Sure, JSON has plenty of uses, but YAML is specifically used for configs that it's terrible at.by frollogaston
- I never figured out how the hell to write YAML and I definitely won't now that I trust the AI to do a better job than me. It's so unintuitive.
Every time I've tried in the past, something as simple as making a value a list had some nonsense expectations. I can't wrap my head around how that spec got any traction and wasn't laughed off the face of the earth the first time it was looked at by someone who didn't create it.
by hbn - When I see YAML in a product tech stack, I know that the developers have probably made other similarly poor life decisions and try to steer clear of the entire iceberg.by voakbasda
- It’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!
by fmbb - In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config filesby anonymars
- Yeah, the YAMLification of everything kinda killed my ability to understand "everything". Previously, if you knew the Linux userland well, I felt like you could figure anything out with enough digging.
Take CI for example, it was Jenkins and it ran a csh/bash/zsh whatever script and captured the output. Nice and simple (even if the scripts sometimes got insane).
GitHub actions is nothing like that. Weird home grown extensions to YAML with their own idiosyncrasies and dynamically pulling in plugins from god knows where. You can't just take a workflow and execute it locally like you could with a bash script.
by doix - It'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/...
by mjr00 - I 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.
by fg137 - I 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
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-fixby inahga - Proof that LLMs are trained on mediocre shit. That is by definition, mediocre shit.by cryo32