CVE-2026-31976 is a supply chain compromise of xygeni-action, the GitHub Action for the Xygeni scanner, scored 9.8. An attacker with stolen credentials moved the mutable v5 tag to a malicious commit. Pin to the verified v6.4.0 commit and rotate secrets if you ran @v5.
What's affected
Workflows that referenced xygeni/xygeni-action@v5 during the affected window, which the advisory puts at about March 3 to 10, 2026. The advisory lists the affected version as v5 and the patched version as v6.4.0.
The advisory says the malicious pull requests were blocked by branch protection and never merged. The attacker used compromised app credentials to move the v5 tag to a commit from one of those unmerged pull requests, and that commit stayed in the repository's object store.
The compromised v5 tag has since been removed, so workflows that still use @v5 now fail with a reference not found error.
How to check if you're exposed
Search all your repositories for the action.
grep -rn "xygeni/xygeni-action" .github/workflows
Any workflow that used the v5 reference needs a look. Then work out whether it ran between March 3 and 10, 2026, using your Actions run history.
The advisory also gives indicators to search for. Check CI logs and network records for outbound connections to 91.214.78.178, and for DNS lookups of security-verify.91.214.78.178.nip.io.
What to do now
- Update workflows to pin the verified commit for v6.4.0, which the advisory gives as 13c6ed2797df7d85749864e2cbcf09c893f43b23.
- If a workflow ran with @v5 in the affected window, rotate every secret the runner could read: repository and environment secrets, deploy keys and cloud tokens.
- Audit CI logs for connections to the address and hostname listed in the advisory.
- Review recent releases and published artifacts built by those workflows for signs of tampering.
- As an alternative, the advisory says you can run the scanner through its command line installation instead of the action.
Why it matters
The record lists CWE-506, embedded malicious code. Per the advisory, the injected step looked like scanner telemetry. It registered the CI runner with a remote server and then polled it for commands that it ran in the shell, sending the output back. It ran quietly beside the real scan.
The root problem is how GitHub Actions references work. A tag such as v5 is mutable, so whoever controls it can change what every workflow gets on its next run. A full commit SHA cannot be moved. That is why the standard advice is to pin third party actions by SHA and review changes before you move the pin.
The advisory states that the realized risk was limited: the tag was mostly used by the vendor's own and affiliated repositories, no external public repositories were found using it, the window was about six days, and no exploitation of downstream users was confirmed. It adds that private repository use cannot be ruled out.
This is a real compromise of a security tool's delivery path, not just a flaw. Treat it as an incident check for any workflow that used the tag, even though the confirmed spread was small. Continuous monitoring of the actions your pipelines reference makes this sort of review quick. Safeguard's free in-browser scan at https://gold.safeguard.sh/scan covers dependencies, and a similar habit applies to your workflow files.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the action still work with @v5?
No. The advisory says the compromised tag was removed, so references to it fail.
Is it safe to use the scanner at all?
The advisory says the CLI installation route bypasses the action and is not affected by this incident. Follow the vendor's current guidance.
Why pin to a commit SHA?
A SHA cannot be moved to different code, while a tag can. That is exactly what happened here.
Sources
Last reviewed: 19 October 2026.
