A widely used open-source data observability tool briefly became a credential-stealing package over the weekend, after attackers turned a GitHub Actions workflow flaw into a malicious release.
Elementary Data said that version 0.23.3 of its open-source Python CLI, elementary-data, was published to PyPI and pushed as a Docker image on April 24 with malicious code. The company says the artifacts were not produced by its team and that the affected release was removed the next morning.
The practical advice is blunt: anyone who installed elementary-data 0.23.3, or pulled and ran the affected Docker image during the incident window, should assume credentials available in that environment may have been exposed.
The breach path
This was not a simple typo-squatting campaign or a fake package with a similar name. According to Elementary, the attacker opened a pull request containing malicious code and exploited a script-injection vulnerability in one of the project's GitHub Actions workflows. That gave the attacker a path to publish a real release under the project's normal package channels.
That detail matters. Developers often treat signed or official package releases as the safe side of the supply-chain problem. This incident shows the weaker point can sit earlier in the release machinery: CI workflows, pull request triggers, overly broad tokens, and publishing credentials that are reachable from automation.
Ars Technica reported that the malicious release scanned for sensitive data including user profiles, data warehouse credentials, cloud provider keys, API tokens, SSH keys, and .env file contents. Elementary says Elementary Cloud, the Elementary dbt package, and other CLI versions were not affected.
Who needs to act
The impacted group is narrower than every Elementary user, but serious for anyone in it. Elementary says only users who downloaded and executed CLI version 0.23.3, or pulled the affected Docker image during the April 24 to April 25 window, need to respond.
Those users should check installed versions, uninstall 0.23.3, move to 0.23.4, and pin lockfiles to the fixed version. They should also clear caches and look for the malware marker file listed in Elementary's incident report.
The bigger job is credential rotation. If the package ran on a developer laptop, the exposed material could include local profiles, SSH keys, cloud credentials, and environment files. If it ran in CI, the risk can be worse because build runners often hold deployment tokens, package registry credentials, cloud keys, and other high-value secrets.
In other words, this is not only a package update problem. It is an incident response problem.
The bigger lesson for software teams
Open-source supply-chain risk is increasingly about trusted automation, not only malicious strangers uploading suspicious packages. A project can have a real maintainer base, a legitimate package name, and a normal release channel, while still shipping a poisoned artifact if the release pipeline is compromised.
Teams using public GitHub repositories should review workflows that run on pull requests, especially workflows that interpolate user-controlled branch names, commit messages, issue text, or PR metadata into shell commands. Publishing jobs should be isolated from untrusted PR execution, and tokens should be scoped so a compromised test workflow cannot become a release workflow.
For companies consuming open-source packages, the response is less glamorous but more useful: lock dependencies, monitor for yanked or flagged versions, keep package provenance where possible, and avoid placing broad production secrets into routine build environments.
The elementary-data incident appears contained, but it is a clean example of why developer tooling attacks keep working. The attackers do not need to break the whole ecosystem. They only need one trusted automation path with enough permissions to ship code.
