In late April, a security incident involving Elementary Data's open-source Python CLI highlighted a growing threat in software supply chains. Attackers exploited a vulnerability in a GitHub Actions workflow to inject malicious code into the elementary-data package on PyPI. This Q&A breaks down what happened, who was affected, how to check your systems, and what steps the team took to prevent future breaches.
How Did the Attack Happen?
The attack stemmed from a flaw in one of Elementary's GitHub Actions workflows. The workflow was configured to execute shell commands based on text from pull request (PR) comments. This meant that any text posted in a PR comment would be directly passed to a shell command inside the runner. At 22:10 UTC on April 24, an attacker posted a malicious comment on a pull request. The workflow treated that comment as code, executing it and revealing sensitive secrets—including the PyPI publish token and the GitHub token—to the attacker. With those credentials, the attacker created branches and pull requests to stage a release, then triggered the official release workflow. By 22:20 UTC, the compromised elementary-data version 0.23.3 was live on PyPI, followed shortly by a malicious Docker image. This was a classic supply chain attack that exploited a common CI/CD misconfiguration.
Which Users Are Affected?
Only users who installed elementary-data version 0.23.3 from PyPI are directly affected, along with anyone who pulled the compromised Docker image during the short attack window. The malicious package remained live for only about 10 minutes before being detected. Importantly, Elementary Cloud, the Elementary dbt package, and all other versions of the CLI were untouched. However, for those running 0.23.3, the risk is serious because the malware had access to everything the environment could reach—including environment variables, credentials, and local files. If you installed that version, you need to take immediate action as described in the remediation steps.
What Damage Could the Malware Cause?
Once installed, the malicious code in elementary-data 0.23.3 could exfiltrate sensitive data from the affected environment. The malware left a marker file on the system: /tmp/.trinny-security-update on Linux/macOS, or %TEMP%\.trinny-security-update on Windows. If that file exists, it means the payload executed successfully. The malware had access to any secrets, API tokens, database credentials, or cloud provider keys that were available in the environment where the package ran. Depending on the user's setup, this could compromise production systems, CI/CD pipelines, or personal machines. The full extent of data theft is not yet known, but it's likely the attackers targeted credential harvesting.
What Should Affected Users Do Now?
First, check your installed version with pip show elementary-data | grep Version. If it shows 0.23.3, immediately remove it by running pip uninstall elementary-data, then install the clean version (0.23.4) with pip install elementary-data==0.23.4. Also update requirements files and lockfiles to reference the patched version. Next, search for the marker file .trinny-security-update in /tmp/ (or %TEMP% on Windows). If found, rotate every credential that environment could access—this includes cloud provider keys, API tokens, database passwords, and any other secrets. Notify your security team to investigate for suspicious activity using those credentials. Finally, monitor logs for any unusual outbound traffic or unauthorized access attempts.
How Did Elementary Respond to the Breach?
Elementary acted quickly after discovering the attack. By April 25, they had removed version 0.23.3 from PyPI, GitHub, and the Docker registry. Internally, they decommissioned the vulnerable workflow and audited all other GitHub Actions workflows for similar injection vulnerabilities. They regenerated all compromised secrets and moved to OIDC-based authentication to reduce reliance on long-lived tokens. Elementary also engaged an Israeli cybersecurity firm to conduct a thorough investigation and bolster their overall security posture. These steps aim to prevent future attacks that exploit CI/CD pipeline weaknesses. The incident serves as a reminder for all open-source maintainers to review their GitHub Actions configurations for command injection risks.
What Can Developers Learn from This Incident?
This attack highlights several key lessons for open-source maintainers and developers. First, never trust user input in CI/CD workflows. Treat pull request comments as untrusted data—just like form input on a web app. Use environment variables and parameterized actions instead of inlining comments into shell commands. Second, audit GitHub Actions workflows regularly for over-permissive triggers or direct exposure of secrets. Implement the principle of least privilege for tokens (e.g., use fine-grained PATs, OIDC tokens). Third, monitor for quick anomalies—the attack window was only 10 minutes, but automated alerts on unusual releases could catch such events earlier. Finally, rotate secrets after every incident and consider using ephemeral credentials. The shift to OIDC authentication by Elementary is a best practice that limits the blast radius of token leaks.