The Tag Trap: How a Single Commit Swap Turned Xygeni’s GitHub Action into a Clandestine Backdoor

An imperceptible edit to a single tag transformed a ubiquitous security auditing instrument into a clandestine backdoor. A malefactor compromised the official Xygeni GitHub Action, implanting a fully functional remote command shell capable of executing arbitrary directives upon the build servers. The savants at StepSecurity have meticulously chronicled this incident, which transpired on the 3rd of March, 2026.

An unidentified adversary usurped access to the credentials of the Xygeni project maintainers, subsequently injecting malignant code into the xygeni/xygeni-action repository—the official GitHub Action relied upon by upwards of 137 distinct repositories. The paramount peril lay in the reality that the assailant did not alter the patrons’ operational files. Instead, they stealthily redirected the v5 version tag to point towards the venomous commit. Consequently, any project designating xygeni/xygeni-action@v5 within its workflow inadvertently initiated the execution of the implanted backdoor.

The malignant code was masterfully masqueraded as a routine step dubbed “scanner version telemetry collection.” The script was surreptitiously appended to the action.yml configuration file, nestled seamlessly between the scanner’s installation and the primary diagnostic sweep. At a superficial glance, this maneuver appeared profoundly benign: it merely outputted the instrument’s version nomenclature. In actuality, the code detonated a concealed remote command shell.

Upon detonation, the Action registered itself with a command-and-control nexus situated at the IP coordinate 91.214.78.178, transmitting the hostname, the user nomenclature, and the operating system iteration, before initiating a relentless, multi-second polling cycle for nascent directives. The retrieved commands were executed via the eval function, and the ensuing output was cryptographically compressed and exfiltrated back to the adversarial server. Operating entirely in the background, this script ensured the primary security audit proceeded unabated, thereby arousing no suspicion whatsoever.

Within a fleeting three-minute operational window, the malefactor wielded the power to execute arbitrary commands across the build server. The spectrum of potential devastations encompassed the theft of environment variables—expressly including GitHub tokens and cryptographic access keys—the unauthorized perusal of source code, and the malicious substitution of build artifacts.

This incursion proved far more Machiavellian than a pedestrian code injection executed via a pull request. Indeed, three distinct pull requests bearing the identical malignant payload materialized within the repository; however, not a single one was ratified. Instead, the adversary simply transposed the v5 tag onto the venomous commit. Such a tag remains infinitely mutable at any given juncture, and the overwhelming majority of patrons specify this exact major version nomenclature within their configurations.

Owing to this sinister architectural flaw, thousands of projects could have unwittingly commenced the execution of malignant code devoid of a solitary alteration to their native files. The operational system’s configuration continued to innocently display the string uses: xygeni/xygeni-action@v5, even as the underlying code of the Action had been profoundly mutated.

The repository’s forensic ledgers illuminate that these venomous alterations originated from within the organization itself. The pull requests were birthed by three disparate sources: the maintainer account nico-car, an employee credential bearing the signature felix.carnicero@xygeni.io, and the GitHub service application xygeni-onboarding-app-dev[bot]. The entirety of these actions transpired within an agonizingly brief twenty-minute window. Such a rapid, orchestrated sequence strongly implies the catastrophic subjugation of credentials or access keys, rather than the machinations of an internal rogue actor.

The project’s vanguard swiftly shuttered the malignant pull requests and excised the tainted workflows from the repository. Alas, the v5 tag persistently remained tethered to the infected commit. As of the 9th of March, patrons are vehemently counseled to urgently migrate to version v6.4.0 or, alternatively, to permanently anchor their configurations to a specific commit hash in lieu of a mutable tag.

The siege upon Xygeni has once again laid bare the profound vulnerability festering within the GitHub Actions supply chain. Version tags possess an inherent mutability; thus, a singular transposition of a tag harbors the devastating capacity to surreptitiously substitute the underlying code for every patron utilizing the Action. A strikingly homologous stratagem was previously weaponized in 2025 during the assault upon the tj-actions/changed-files Action, an event wherein malefactors usurped access to the cryptographic secrets of thousands of repositories. The paramount defensive posture in such crucibles mandates anchoring GitHub Actions not to ephemeral tags, but exclusively to immutable commit identifiers. As a commit cannot be retroactively altered, the insidious substitution of code via tag manipulation is rendered an absolute impossibility.