This month, an unidentified threat actor gained unauthorized access to a GitHub Action maintained by application security vendor Xygeni, utilizing a technique known as tag poisoning.
Xygeni, which provides application security tooling, stated in a March 10 security incident report that it detected suspicious activity affecting the repository used to publish the xygeni/xygeni-action component.
The threat actor initially used pull requests to attempt to introduce an unauthorized command-and-control implant into the repository. Xygeni reported that these attempts were blocked by existing branch detection rules. The unauthorized party then shifted their approach, utilizing a separate vector by moving the mutable v5 tag to reference a compromised commit created during the initial pull request attempts.
As a result, workflows referencing xygeni/xygeni-action@v5 retrieved the modified code without any visible changes to their workflow definitions. The actor gained access using compromised credentials associated with a maintainer’s personal access token (PAT) and a GitHub App installed on the affected repository.
Xygeni identified the follow-on activity on March 9 after receiving community reports, and the tag was removed as part of ongoing incident response procedures. According to the vendor, no unauthorized code was merged into the repository's main branch, there is no evidence of unauthorized access to Xygeni's platform or customer data, and the manipulated tag has been permanently deleted.
Root cause analysis and remediation
Xygeni provided a detailed timeline of the incident alongside root cause analysis and remediation recommendations.
The company concluded the incident stemmed from the compromise of a GitHub App private key that had been installed on the repository with unnecessarily broad permissions. The threat actor used the maintainer's PAT in tandem with the GitHub App's credentials—using one identity to create pull requests and the other to approve them, as neither could bypass repository protections independently.
To safeguard against similar events, Xygeni has committed to enforcing release immutability across its repositories, hardening repository permissions, requiring cryptographically signed commits for maintainers, and restricting write access to a limited group of administrators.
The vendor advises customers to update their workflows to pin to a safe commit SHA, audit continuous integration (CI) logs, and rotate any secrets exposed to CI runners during the exposure period.
Incident timeline analysis
Xygeni continues to investigate the exact method used to obtain the private key, noting that .pem files can be exposed through misconfigured workflows, local developer environment access, or insecure secret storage.
One of the first public indicators of the event came on March 9 via StepSecurity CEO Varun Sharma. Sharma detailed that on March 3, 2026, an unauthorized party with maintainer and GitHub App token access injected a reverse shell into the official action, disguising the code as a scanner telemetry step. While the pull requests carrying the code were closed without merging, moving the v5 shortcut tag meant anyone referencing the tag ran the implant for seven days (March 3–10).
The primary mechanism for the incident, Sharma observed, was the mutable v5 tag, which anyone with write access could point to an arbitrary commit. Although Xygeni acted quickly to close the initial pull requests and delete associated workflows from the repository, Sharma stated the initial March 9 remediation still included the v5 tag. Complete remediation occurred on March 10 after StepSecurity reported the oversight.
Sharma noted that closing the pull requests and deleting workflows did not mitigate the active exposure because the v5 tag was the core delivery mechanism. Any workflow running @v5 during this timeframe gave the unauthorized party a three-minute window of arbitrary command execution on the CI runner, granting potential access to the GITHUB_TOKEN, repository secrets, and source code.
Xygeni disputes certain aspects of this timeline, specifically regarding when the v5 tag was poisoned. The company noted that GitHub's repository activity logs do not record tag force-push events, making it difficult to verify the exact timing of the tag manipulation. Xygeni confirmed the tag was altered at some point between the commit creation and its discovery by the community on March 9.