GitHub Actions Supply Chain Attack: Trivy Breach & Workflow
The post GitHub Actions Supply Chain Attack: Trivy Breach & Workflow appeared first on Grip Security Blog.
Since the end of February, the popular Trivy security scanner has been under attack.
![[un]prompted 2026 – Detecting GenAI Threats at Scale With YARA-Like Semantic Rules](https://securityboulevard.com/wp-content/uploads/2018/01/TwitterLogo-002.jpg)
[un]prompted 2026 – Detecting GenAI Threats at Scale With YARA-Like Semantic Rules
The post GitHub Actions Supply Chain Attack: Trivy Breach & Workflow appeared first on Grip Security Blog.
Since the end of February, the popular Trivy security scanner has been under attack. In multiple different cases and campaigns, attackers targeted this repository by leveraging a misconfigured workflow in the GitHub Actions component. The blast radius from one compromised workflow is tremendous. Throughout this paper, we will go over the attack surface, summarize what happened, and give recommendations on how to reduce the risks involved with it.
Trivy GitHub Actions – By Aqua Security
Trivy is an open-source project created by Aqua Security. It’s a vulnerability scanner that runs as part of GitHub Actions workflows and scans for vulnerable Docker images, the GitHub repository itself, root file systems directories and much more. It is a popular vulnerability scanner, verified officially by GitHub, and it is widely adopted by the developer community.
Technical Analysis
GitHub Actions
GitHub Actions is a CI/CD platform integrated directly into GitHub. GitHub Action allows the user to automate different tasks including build, test, and deployment pipelines. Workflows are event-driven pipelines which operate and run according to different types of activities that happen on the repository – open pull requests, push commits, open issues and much more. In general, GitHub Actions consists of workflows defined through structured YAML files.
Over the years GitHub Actions gained more popularity among DevOps teams due to its flexibility. However, this popularity does not come without risks. Misconfigured workflows can expose the organization to different types of attacks including – tokens exfiltration, code execution, over-privileged permissions, supply chain attacks, and more.
The Hackerbot-Claw Campaign
On March 1st, StepSecurity published research regarding an AI bot named Hackerbot-claw, that searched for vulnerable workflows on open-source projects and attempted to steal credentials. During this campaign that lasted for 10 days, this AI bot successfully achieved code execution in some cases and exfiltration of a GitHub token with write permission in one specific case. This stolen GitHub token was from the Trivy repository.
According to StepSecurity, this stolen token was used to:
Make the repository private and rename it
Delete GitHub releases
Push a suspicious artifact to Trivy’s VSCode extension
How exactly did this bot exfiltrate the GitHub token? It happened due to one misconfigured workflow, specifically leveraging the “pwn request” vulnerability which we will discuss later.
Aqua Security’s response to this compromise:
Removed the vulnerable workflow
Removed the suspicious VSCode extension artifact
Restored the repository
Republished the latest version
Still restoring the GitHub releases.
Second Breach – March 20th
On March 20th, Trivy repository was hit again. Socket published research regarding this campaign which involved tag compromise rather than exploiting GitHub itself. Socket mentioned the following:
This latest incident impacts GitHub Actions, and is separate from the earlier OpenVSX compromise involving the VS Code extension.
However, in another report published by Socket, they mentioned that this malicious extension was probably due to the initial hackerbot-claw campaign which successfully exfiltrated a GitHub token with write permissions and pushed malicious artifact.
Socket security team noted that in this specific campaign, an attacker force pushed 75 out of 76 version tags in the Trivy GitHub Actions and added that more than 10,000 repositories referencing this Trivy action, making it extremely large supply chain attack.
Looking at the maintainer’s response to this incident reveals the story (again) – compromised credentials are the starting point:
Recent updates from the Trivy maintainers confirm that this attack was enabled by a compromised credential with write access to the repository. The incident is a continuation of the earlier March breach, during which credentials were exfiltrated from Trivy’s CI environment. Although secrets and tokens were rotated in response, the rotation process was not fully atomic, and the attacker may have retained access to newly issued credentials. This allowed the threat actor to perform authenticated operations, including force-updating tags, without needing to exploit GitHub itself. While the exact credential used in this phase has not been publicly specified, the root cause is now understood to be residual access from the earlier credential compromise.
The payload itself targeted a specific file in the Trivy repository called “entrypoint.sh”. Without going into details, Socket explained that this payload contains three main parts:
Collection of secrets from runner process memory.
Encryption of the collected data.
Exfiltration of the encrypted data to attacker-controlled server.
Follow up Attack – March 20th
On March 20th , following the Trivy actions compromise, Aikido published a notice regarding 47 malicious NPM packages which they called CainsterWorm. They added that this specific campaign was linked to a group called TeamPCP which were the same actors that performed the Trivy tag compromised. The compromised packages are as follows:
28 packages in the @EmilGroup scope
16 packages in the @opengov scope
The package @teale.io/eslint-config
The package @airtm/uuid-base32
The package @pypestream/floating-ui-dom
More information regarding this attack group can be found on Wiz Cloud Threat Landscape.
Expanding the Blast Radius – March 22nd
Two days after their initial research on the tag versioning compromise, Socket published their second research. This time, two new compromised image tags (0.69.5 and 0.69.6) were published to Docker Hub. Both images contain IoCs related to the same TeamPCP group discovered earlier. This indicates expansion of this campaign trying to leverage Docker images as another point in the supply chain attack.
Checkmarx GitHub Actions Compromise – March 23rd
TeamPCP strikes again. Sysdig published that the same attack group targeted new GitHub Actions workflow named Checkmarx AST. The same payload, the same infostealer with only entry point difference – the payload is injected to the “setup.sh” file unlike the “entrypoint.sh” file in the Trivy case.
Sysdig added that this compromised probably happened due to the Trivy compromise:
The TeamPCP stealer’s primary function is harvesting credentials from CI runner memory. When a compromised Trivy action executes in a workflow, it extracts GitHub personal access tokens (PATs) and other secrets from the Runner.Worker process memory. If those tokens have write access to repositories that also use Checkmarx actions, the attacker can use them to push malicious code to additional action dependencies.
TeamPCP continued with its malicious operations targeting popular software programs. On March 24th two malicious versions of “littlellm” Python package were published in PyPl with the same characteristics of the attacker group. Another case from March 27th is about Telnyx Python package.
Socket summarizes this campaign:
The pattern behind these attacks is becoming clear. This is not your run-of-the-mill opportunistic targeting of random vulnerable projects. They are aiming at scanners, GitHub Actions, and other developer infrastructure that already sit inside CI/CD pipelines and enterprise environments. This positioning allows attackers to harvest credentials, access sensitive systems, and identify weaknesses across organizations using these tools.
The following two timeline shows the significant impact of the Trivy supply chain attack. Although there is no connection between the first campaign (the hackerbot-claw campaign) and the second campaign of the TeamPCP – GitHub is a popular attack vector that must be monitored and controlled.
Misconfigured workflows
As mentioned previously, this campaign targeted vulnerable workflows to achieve its malicious goal. In this section, we will focus on why these workflows were vulnerable and how Grip can help to detect this kind of misconfigurations.
Workflow injection via pull request (“Pwn request vulnerability”)
Both Orca security and StepSecurity introduced this problem. The combination of over-privileged trigger + executing code from external pull request can lead to serious consequences including – secret exfiltration, code execution and repository compromised.
How this vulnerability happens?
“pull_request_target” is a trigger event that runs the workflow when activity on a pull request in the workflow’s repository occurs. This includes – open pull request, re-open a pull request, or updating the head branch of the pull request. The most interesting fact about this trigger, that it can be triggered from forked repositories. Forked repository means that a user created a local copy of the original repository and can create pull requests on the original one.
Even GitHub official documentation gives a warning about this trigger:
Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include poisoning and granting unintended access to write privileges or secrets.
Combining this trigger with the “actions/checkout” command pointing to the pull request’s head can lead to code execution in some cases by an external source. Let’s observe the following YAML and explain what happens:
name: MyCustomWorkflow
on: pull_request_target
…
Steps:
– name: Checkout Code
– uses: actions/checkout@v4
– with:
-ref: ${{ github.event.pull_request.head.sha }}
– name: Run script
run: sh/bash ./scripts/my_script.sh
Full exploitation process:
The attacker forks the repository.
The attacker creates a pull request on the main repository containing a malicious code. It can be injected into the script “my_script.sh” or to the workflow itself.
Trigger the workflow with the modified files.
How can Grip reduce the attack surface in GitHub?
SSPM Posture Checks
Grip’s SSPM policies mechanism follows industry best practices recommendations for GitHub. Grip’s product can integrate with critical SaaS applications within the organization such as GitHub and detect any misconfiguration in the application management.
The following SSPM polices can reduce risks associate with the problems listed in the discussed campaigns:
Forking Should Not Be Allowed for This Repository – Reduce unwanted pull requests from external sources.
Default Branch Should Not Allow Force Pushes – protects default branch history.
GitHub Actions should require immutable pinning reference using commit SHA.
Threat Detection & Response
By monitoring different components and API endpoints, Grip can detect anomalies related to GitHub. Workflows, webhooks, audit-log – all are inspected to find malicious activities within the application
GitHub Pwn request vulnerability
In cases where forking is necessary and enabled, Grip can detect vulnerable workflows by monitoring the content of the YAML files (and any changes related to it) and create a TDR detection when “pull_request_trigger” is found combined with reference to the pull request head within “checkout/action” step. This way, Grip alerts potential “pwn request” vulnerability and suggests mitigation steps.
Potential data exfiltration from a workflow
Grip detects YAML files that include potential token/secrets exfiltration. The detection is based on network utility use (curl/wget) + any kind of GITHUB_TOKEN or $ {{ secrets.*. }} mention in the same command. This kind of combination might indicate a malicious attempt to exfiltrate data to an external server using the YAML itself.
Over-privileged permission workflow
Over-privileged workflows violate the principle of least privilege by granting excessive access rights beyond what is required for their intended function. In the event of a workflow compromise, an attacker could inherit these permissions, potentially gaining read and write access to repositories. This level of access may allow the attacker to modify code, introduce malicious changes, or exfiltrate sensitive data. Grip created a detection for any workflow that has “permissions: write-all” within it.
GitHub Tag and Commit Integrity
A Git tag, which previously pointed to a cryptographically signed and verified commit, has been force-pushed to point to a new, unsigned commit. This indicates a potential supply chain compromise, as an attacker with compromised credentials can replace legitimate release code but cannot re-create the original GPG signature.
Summary
GitHub is a critical SaaS platform at the core of the software development lifecycle in many organizations. It enables development teams to manage code, collaborate efficiently, and automate deployment processes. Due to its central role, GitHub has become an attractive target for attackers.
Threats in this domain include arbitrary code execution, credential theft, and supply chain attacks. A single compromised repository can impact thousands of downstream projects, significantly increasing the potential blast radius. With the rise of AI, such attacks are becoming more scalable and sophisticated, as demonstrated in campaigns like hackerbot-claw.
Given this risk, proper configuration and continuous monitoring of GitHub environments are essential to ensure secure usage.
Grip addresses these challenges by integrating with critical SaaS applications like GitHub. Through its SSPM capabilities, organizations can identify and remediate misconfigurations using policies aligned with industry best practices.
In addition, Grip’s Threat Detection and Response (TDR) engine continuously monitors key GitHub components—including audit logs, workflows, and webhooks—to detect anomalies and generate actionable alerts.
You cannot prevent what you cannot see or enforce. See how Grip gives you continuous visibility and control over GitHub workflows and SaaS risk. Reach out for a demo today.
*** This is a Security Bloggers Network syndicated blog from Grip Security Blog authored by Grip Security Blog. Read the original post at: https://www.grip.security/blog/trivy-github-actions-supply-chain-attack
About Author
