AWS merges malicious PR into Amazon Q (opens in new tab)

(lastweekinaws.com)

63 pointsQuinnyPig8mo ago20 comments

20 comments

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.

gruez8mo 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?

[1] https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...

[2] https://github.com/aws/aws-toolkit-vscode/commit/d1959b99684...

QuinnyPigOP8mo 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.

shdjhdfh8mo ago

Your article breathlessly blames AWS for being reckless while having no real facts about the compromise. The whole thing reads like click bait.

1 more reply

shdjhdfh8mo 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.

shdjhdfh8mo ago

Ah, I think it might have been this, which was reverted and seems to have been pushed directly to master: https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...

2 more replies

Technetium8mo ago

I found a postmortem which seems to be well written: https://www.mbgsec.com/posts/2025-07-24-constructing-a-timel...

huey778mo ago

https://archive.md/UAUnG

Kiboneu8mo ago

Copy-on-write filesystems should be the norm.

Another article came out earlier about dataloss from some vibecoding project and an automated snapshot setup would have mitigated this very issue.

blibble8mo ago

I guess they put their AI in charge of code review?

j / k navigate · click thread line to collapse

20 comments

skywhopper8mo ago

gruez8mo 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?

[1] https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...

[2] https://github.com/aws/aws-toolkit-vscode/commit/d1959b99684...

QuinnyPigOP8mo 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.

shdjhdfh8mo ago

Your article breathlessly blames AWS for being reckless while having no real facts about the compromise. The whole thing reads like click bait.

1 more reply

shdjhdfh8mo ago

Ah, I think it might have been this, which was reverted and seems to have been pushed directly to master: https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...

2 more replies

Technetium8mo ago

I found a postmortem which seems to be well written: https://www.mbgsec.com/posts/2025-07-24-constructing-a-timel...

huey778mo ago

https://archive.md/UAUnG

Kiboneu8mo ago

Copy-on-write filesystems should be the norm.

Another article came out earlier about dataloss from some vibecoding project and an automated snapshot setup would have mitigated this very issue.

blibble8mo ago

I guess they put their AI in charge of code review?

j / k navigate · click thread line to collapse