5 ms·

AWS merges malicious PR into Amazon Q

63 points by QuinnyPig 1y ago

skywhopper 1y ago
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 1y 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 1y 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 1y 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.
      - deleted 1y ago
        [deleted]
- shdjhdfh 1y 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.
  - shdjhdfh 1y 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/678851bbe9776228f55e0460e66a6167ac2a1685 https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...
    - personalcompute 1y ago
      I think you've got it! - 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/ 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 1y 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 1y 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.
        1y ago
- gruez 1y 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/678851bbe9776228f55e0460e66a6167ac2a1685 https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97... [2] https://github.com/aws/aws-toolkit-vscode/commit/d1959b996841883b3c14eadc5bc195fe8f65a63b https://github.com/aws/aws-toolkit-vscode/commit/d1959b99684...
blibble 1y ago
I guess they put their AI in charge of code review?
huey77 1y ago
https://archive.md/UAUnG https://archive.md/UAUnG
Kiboneu 1y 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.
Technetium 1y ago
I found a postmortem which seems to be well written: https://www.mbgsec.com/posts/2025-07-24-constructing-a-timeline-for-amazon-q-prompt-infection/ https://www.mbgsec.com/posts/2025-07-24-constructing-a-timel...

63 points by QuinnyPig 1y ago

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 1y 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 1y 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 1y 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.
    - deleted 1y ago
      [deleted]
shdjhdfh 1y 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.
- shdjhdfh 1y 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/678851bbe9776228f55e0460e66a6167ac2a1685 https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97...
  - personalcompute 1y ago
    I think you've got it! - 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/ 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 1y 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 1y 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.
      - 1y ago
gruez 1y 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/678851bbe9776228f55e0460e66a6167ac2a1685 https://github.com/aws/aws-toolkit-vscode/commit/678851bbe97... [2] https://github.com/aws/aws-toolkit-vscode/commit/d1959b996841883b3c14eadc5bc195fe8f65a63b https://github.com/aws/aws-toolkit-vscode/commit/d1959b99684...

blibble 1y ago

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

huey77 1y ago

https://archive.md/UAUnG https://archive.md/UAUnG

Kiboneu 1y 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.

Technetium 1y ago

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