I’m curious exactly what happened here. The 404media article isn’t detailed enough to be sure. My guess is the PR took advantage of some code injection possibilities in the GitHub Actions on the repo to grant the attacker admin access. But that’s a wild guess.
QuinnyPig•6mo ago
Exactly my position. I can’t realistically assess the potential scope of damage without a proper disclosure from AWS’s normally-excellent security team.
shdjhdfh•6mo ago
Your article breathlessly blames AWS for being reckless while having no real facts about the compromise. The whole thing reads like click bait.
QuinnyPig•6mo ago
You’re absolutely right that we don’t have a complete postmortem—and that’s exactly the problem.
I’d love to have real facts from AWS about the full scope of this incident. But instead of a disclosure, we got a version quietly pulled from the VS Code extension marketplace, no CVE, no changelog note, and a statement that reads like it was pre-approved by legal and sanitized with a pressure washer.
When a malicious prompt that attempts to wipe both local and cloud resources makes it into a shipping release of a tool that’s been installed nearly a million times, I don’t think “hey maybe we should talk about this” qualifies as breathless or clickbait. It qualifies as basic scrutiny.
And yes, I’ve praised AWS’s security posture before. I’d still prefer they lead with transparency instead of hoping no one notices the /tmp/CLEANER.LOG.
shdjhdfh•6mo ago
The prompt 404 quotes in the article doesn't appear to exist anywhere in the git history for the repo they point to. It seems unlikely that Amazon would rewrite git history to hide this. Maybe the change was in a repo pulled in as a dependency.
- That commit's date matches the date in the 404media article (July 13th)
- The commit message is totally unrelated to the code (highly suspicious)
- The code itself downloads additional code at runtime (highly highly suspicious)
I have not yet been unable to uncover the code it downloads though. It downloaded code that was hosted in the same repo, https://github.com/aws/aws-toolkit-vscode/, just on the "stability" branch. (downloads a file called "scripts/extensionNode.bk") The "stability" branch presumably was a branch created by the attacker, and has presumably since been deleted by Amazon.
rusteh1•6mo ago
I'm not a git expert, but how was the attacker able to push the stability branch directly to the Amazon owned repo? The PR would have been to merge the modified branch to main right?
shdjhdfh•6mo ago
My guess is that skywhopper is correct. We're only able to see the tail end of the attack, but the repo was likely compromised in some way.
wunderwuzzi23•6mo ago
AWS issued a post and they talk about revoking and replacing a credential.
Joseph's 404 article quotes the hacker as saying they "got admin privileges on a silver platter," so I think this is it: first part of the breach was gaining the GitHub permission to create a branch. Possibly just by asking.
Another thing to note, the AI angle on this is nonsensical. The commit could have just as easily done many other negative things to the system without AI as a layer of indirection.
dylnuge•6mo ago
Neither the 404 Media article nor this one claim otherwise. I think the key "AI angle" here is this (from the 404 Media article):
> Hackers are increasingly targeting AI tools as a way to break into peoples’ systems.
There are a lot of AI tools which run with full permission to execute shell commands or similar. If the same kind of compromise happened to aws-cli, it could be equally catastrophic, but it's not clear that the attack vector the hacker used would have been viable on a repo with more scrutiny.
Corrado•6mo ago
I think the AI angle for this is that it is a force multiplier. You don't have to write specific commands, you just have to prompt generic things and it will helpfully fill in all the details. This also allows you to avoid having certain keywords in the PR (ie. `rm -rf`) and possibly evade detection.
gruez•6mo ago
>My guess is the PR took advantage of some code injection possibilities in the GitHub Actions on the repo to grant the attacker admin access. But that’s a wild guess.
Someone below mentioned the offending commit[1], which seems to be a doppelganger of another commit[2]. Maybe the exact commit message broke the automation?
skywhopper•6mo ago
QuinnyPig•6mo ago
shdjhdfh•6mo ago
QuinnyPig•6mo ago
I’d love to have real facts from AWS about the full scope of this incident. But instead of a disclosure, we got a version quietly pulled from the VS Code extension marketplace, no CVE, no changelog note, and a statement that reads like it was pre-approved by legal and sanitized with a pressure washer.
When a malicious prompt that attempts to wipe both local and cloud resources makes it into a shipping release of a tool that’s been installed nearly a million times, I don’t think “hey maybe we should talk about this” qualifies as breathless or clickbait. It qualifies as basic scrutiny.
And yes, I’ve praised AWS’s security posture before. I’d still prefer they lead with transparency instead of hoping no one notices the /tmp/CLEANER.LOG.
shdjhdfh•6mo ago
shdjhdfh•6mo ago
personalcompute•6mo ago
- That commit's date matches the date in the 404media article (July 13th)
- The commit message is totally unrelated to the code (highly suspicious)
- The code itself downloads additional code at runtime (highly highly suspicious)
I have not yet been unable to uncover the code it downloads though. It downloaded code that was hosted in the same repo, https://github.com/aws/aws-toolkit-vscode/, just on the "stability" branch. (downloads a file called "scripts/extensionNode.bk") The "stability" branch presumably was a branch created by the attacker, and has presumably since been deleted by Amazon.
rusteh1•6mo ago
shdjhdfh•6mo ago
wunderwuzzi23•6mo ago
So maybe the hacker was able to directly push?
https://aws.amazon.com/security/security-bulletins/AWS-2025-...
unitof•6mo ago
personalcompute•6mo ago
shdjhdfh•6mo ago
dylnuge•6mo ago
> Hackers are increasingly targeting AI tools as a way to break into peoples’ systems.
There are a lot of AI tools which run with full permission to execute shell commands or similar. If the same kind of compromise happened to aws-cli, it could be equally catastrophic, but it's not clear that the attack vector the hacker used would have been viable on a repo with more scrutiny.
Corrado•6mo ago
gruez•6mo ago
Someone below mentioned the offending commit[1], which seems to be a doppelganger of another commit[2]. Maybe the exact commit message broke the automation?
[1] https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...
[2] https://github.com/aws/aws-toolkit-vscode/commit/d1959b99684...