Some of them were likely already compromised before these incidents, here's one of the accounts near the top making malicious commits to its own repository before the first hack:
"Briefly" is doing a lot of work there. Pre-deploy scans are useless once a bad mutation is actually live. If you don't have a way to auto-revert the infrastructure state instantly, you're just watching the fire spread.
this is painfully accurate. ive worked in security for years and the tools we trust the most get the least scrutiny because everyone assumes "well its a security tool, it must be secure." the irony is these tools usually run with the highest privileges in the pipeline. trivy sits in CI with access to every secret in your environment and nobody questions it because its supposed to be the thing protecting you.
Similarly one of our biggest causes of power outages when I worked with a DC was the UPSes. And the biggest causes of data loss were the hardware RAID controllers. Feels like there's a fundamental law lurking under this stuff.
As the complexity of a system increases, the number of single points of failure also tends to increase. Sometimes you can make sure that several subsystems need to fail before the whole system fails. Often, the best you can do is swap one SPoF (e.g. unreliable power grid) for another, more robust SPoF (unreliable UPS).
This attack seems predicated on a prior security incident (https://socket.dev/blog/unauthorized-ai-agent-execution-code...) at Trivy where they failed to successfully remediate and contain the damage. I think at this time, Trivy should’ve undertaken a full reassessment of risks and clearly isolated credentials and reduced risk systemically. This did not happen, and the second compromise occurred.
Frustratingly, hash pinning isn’t good enough here: that makes the action immutable, but the action itself can still make mutable decisions (like pulling the “latest” version of a binary from somewhere on the internet). That’s what trivy’s official action appears to do.
(IOW You definitely should still hash-pin actions, but doing so isn’t sufficient in all circumstances.)
Edit: ah, I see you are referring to the setup-trivy action rather than the trivy-action. Yeah, that looks like a bad default, although to be fair it is a setting that they document quite prominently, and direct usage of the setup-trivy action is a bit atypical as-is.
That's true. This specific attack was mitigated by hash pinning, but some actions like https://github.com/1Password/load-secrets-action default to using the latest version of an underlying dependency.
I don’t think “briefly compromised” is accurate. The short span between this and the previous compromise of trivy suggests that the attacker was able to persist between their two periods of activity.
To be clear, this is a supply chain attack on everyone that uses Trivy, not a supply chain attack on Trivy. It was a direct attack on Trivy, exploiting components that Aqua had full control and responsibility for. The term “supply chain attack” has a connotation of “it’s not really my fault, it was my dependencies that got compromised”.
Of course, every entity is ultimately accountable for its own security, including assigning a level of trust to any dependencies, so it’s ultimately no excuse, but getting hit by a supply chain attack does evoke a little more sympathy (“at least I did my bit right”), and I feel like the ambiguous wording of the title is trying to access some of that sympathy.
A supply chain attack is an attack on a provider of a solution that is then deployed further. The issue with a supply chain attack is that the ultimate victim brings in trusted software that was compromised upstream.
The Go binary was also compromised, but there's almost no information what the compromised binary did. Did it drop a python script? Did it do direct scanning?
If trivy docker image was used, what's the scope (it does not include python).
This is a very old vulnerability, and to see companies falling for it is mental.
The year is 2026 and companies are still using tag over hash. It is well known that you can release different code under the same tag without alerting users.
Are the spam comments all from compromised accounts, presumably compromised due to this hack?
I only clicked on a handful of accounts but several of them have plausibly real looking profiles.
Some of them were likely already compromised before these incidents, here's one of the accounts near the top making malicious commits to its own repository before the first hack:
https://github.com/Hancie123/mero_hostel_backend/commit/4bcb...
what comments?
Ah, I think the HN post was merged. My original comment was in response to this related github discussion: https://github.com/aquasecurity/trivy/discussions/10420
There are hundreds of automated spam comments there from presumably compromised accounts. The new OP is much more clear regarding what has happened.
Briefly?
"Trivy Supply Chain Attack Spreads, Triggers Self-Spreading CanisterWorm Across 47 npm Packages"
https://it.slashdot.org/story/26/03/22/0039257/trivy-supply-...
"Briefly" is doing a lot of work there. Pre-deploy scans are useless once a bad mutation is actually live. If you don't have a way to auto-revert the infrastructure state instantly, you're just watching the fire spread.
Seriously. All credentials compromised that it can see. It's active in CI/CD pipelines and follow on attacks are happening.
Pretty ironic that the security tool is insecure
You must be new to this. The median line of code in a security tool is materially less secure than the median line of code overall in the industry.
this is painfully accurate. ive worked in security for years and the tools we trust the most get the least scrutiny because everyone assumes "well its a security tool, it must be secure." the irony is these tools usually run with the highest privileges in the pipeline. trivy sits in CI with access to every secret in your environment and nobody questions it because its supposed to be the thing protecting you.
Similarly one of our biggest causes of power outages when I worked with a DC was the UPSes. And the biggest causes of data loss were the hardware RAID controllers. Feels like there's a fundamental law lurking under this stuff.
As the complexity of a system increases, the number of single points of failure also tends to increase. Sometimes you can make sure that several subsystems need to fail before the whole system fails. Often, the best you can do is swap one SPoF (e.g. unreliable power grid) for another, more robust SPoF (unreliable UPS).
This attack seems predicated on a prior security incident (https://socket.dev/blog/unauthorized-ai-agent-execution-code...) at Trivy where they failed to successfully remediate and contain the damage. I think at this time, Trivy should’ve undertaken a full reassessment of risks and clearly isolated credentials and reduced risk systemically. This did not happen, and the second compromise occurred.
They did a lot of what you describe, although perhaps not well enough.
It seems not enough again, as their Docker images have now been compromised (as of March 22nd, 2026): https://github.com/aquasecurity/trivy/security/advisories/GH...
Don't forget to pin your GitHub Actions to SHAs instead of tags, that may or may not be immutable!
Frustratingly, hash pinning isn’t good enough here: that makes the action immutable, but the action itself can still make mutable decisions (like pulling the “latest” version of a binary from somewhere on the internet). That’s what trivy’s official action appears to do.
(IOW You definitely should still hash-pin actions, but doing so isn’t sufficient in all circumstances.)
I'm pretty sure the trivy action does not do that.
FWICT, it pulls the latest version of trivy by default. If that latest tag is a mutable pointer (and it typically is), then it exhibits the problem.
Then why do they hard code the trivy version and create PRs to bump it?
https://github.com/aquasecurity/trivy-action/blob/57a97c7e78...
https://github.com/aquasecurity/trivy-action/pull/519
Edit: ah, I see you are referring to the setup-trivy action rather than the trivy-action. Yeah, that looks like a bad default, although to be fair it is a setting that they document quite prominently, and direct usage of the setup-trivy action is a bit atypical as-is.
That's true. This specific attack was mitigated by hash pinning, but some actions like https://github.com/1Password/load-secrets-action default to using the latest version of an underlying dependency.
This attack was not mitigated by hash pinning. The setup-trivy action installs the latest version of trivy unless you specify a version.
Oh, I was referring to `aquasecurity/trivy-action` that was changed with a malicious entrypoint for affected tags. Pinned commits were not affected.
I don’t think “briefly compromised” is accurate. The short span between this and the previous compromise of trivy suggests that the attacker was able to persist between their two periods of activity.
The irony of your vulnerability scanner being the vulnerability.
Ever heard of IBM QRadar SIEM?
Yes... Any more context? Were they leaking data?
To be clear, this is a supply chain attack on everyone that uses Trivy, not a supply chain attack on Trivy. It was a direct attack on Trivy, exploiting components that Aqua had full control and responsibility for. The term “supply chain attack” has a connotation of “it’s not really my fault, it was my dependencies that got compromised”.
Of course, every entity is ultimately accountable for its own security, including assigning a level of trust to any dependencies, so it’s ultimately no excuse, but getting hit by a supply chain attack does evoke a little more sympathy (“at least I did my bit right”), and I feel like the ambiguous wording of the title is trying to access some of that sympathy.
The term “supply chain attack” has a connotation of “it’s not really my fault, it was my dependencies that got compromised”.
In my experience that is definitely not true, and I've never heard anyone use it that way. Even though you are correct in who the target was.
A supply chain attack is an attack on a provider of a solution that is then deployed further. The issue with a supply chain attack is that the ultimate victim brings in trusted software that was compromised upstream.
yeah, we keep learning the same lesson: the tool that audits your supply chain is the single best target for compromising it
How do you simultaneously revoke all credentials of all your accounts spanning multiple services/machines/users?
Lots more technical research about the actual attack and how it worked here: https://socket.dev/blog/trivy-under-attack-again-github-acti...
Disclosure: I’m the founder of Socket.
Great analysis!
The Go binary was also compromised, but there's almost no information what the compromised binary did. Did it drop a python script? Did it do direct scanning?
If trivy docker image was used, what's the scope (it does not include python).
Sounds like Trivy is still compromised:
https://www.aquasec.com/blog/trivy-supply-chain-attack-what-...
Мы позвали царского дегустатора проверить суп на яд, но яд оказался на его ложке.
Still compromised: https://socket.dev/blog/trivy-under-attack-again-github-acti...
This is a very old vulnerability, and to see companies falling for it is mental.
The year is 2026 and companies are still using tag over hash. It is well known that you can release different code under the same tag without alerting users.