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.
>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?
Exactly my position. I can’t realistically assess the potential scope of damage without a proper disclosure from AWS’s normally-excellent security team.
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.
Readit News
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...
Another article came out earlier about dataloss from some vibecoding project and an automated snapshot setup would have mitigated this very issue.