A supply-chain attack has impacted the widely used PyPI package elementary-data, after attackers published a malicious release designed to steal developer secrets, cloud credentials, and cryptocurrency wallet data.
The compromised version, 0.23.3, was distributed through both PyPI and the project’s official container pipeline, extending the risk to Docker users who pulled affected images. Given the package’s scale—reportedly exceeding 1.1 million monthly downloads—the incident highlights the growing threat of software supply-chain attacks targeting developer ecosystems.
What Is elementary-data?
elementary-data is an open-source observability platform used primarily by analytics engineers and teams working with dbt (Data Build Tool) pipelines. It helps organizations monitor data quality, detect anomalies, and improve visibility across modern data infrastructure.
Because the package is integrated into CI/CD workflows, cloud environments, and production analytics pipelines, compromise of a trusted release can create significant downstream risk.
How the Attack Happened: GitHub Actions Workflow Exploitation
According to researchers at StepSecurity, the attackers did not compromise maintainer accounts directly. Instead, they exploited a flaw in the project’s automation workflow.
A malicious comment was posted on a pull request, triggering a GitHub Actions script injection vulnerability. This caused the CI workflow to execute attacker-controlled shell commands during the build process.
As a result, the attackers were able to expose the repository’s GITHUB_TOKEN, a privileged automation token commonly used for CI/CD tasks.
With this token, the attackers:
- Forged a signed commit
- Created a malicious release tag (v0.23.3)
- Triggered the legitimate release pipeline
- Published backdoored artifacts as if they were official releases
This method is particularly dangerous because it abuses trusted automation rather than obviously hijacking developer accounts.
Malicious Package and Docker Image Published as Official Releases
Once the release pipeline was triggered, the project’s own automation published:
- A malicious PyPI package:
elementary-data==0.23.3 - A compromised container image in GitHub Container Registry
- The latest tag, causing unpinned environments to auto-pull the malicious build
Affected image tags reportedly include:
ghcr.io/elementary-data/elementary:0.23.3
ghcr.io/elementary-data/elementary:latest
Because these artifacts came through the legitimate release process, they appeared authentic to users and automated systems.
Payload Behavior: Developer Secrets and Crypto Theft
The malicious release included a file named:
elementary.pth
Python .pth files can execute automatically when the interpreter starts, making them a stealthy persistence and code execution mechanism.
The embedded payload acted as an information stealer targeting sensitive developer and infrastructure data, including:
Credentials and Secrets
- SSH private keys
- Git credentials
- AWS, GCP, and Azure credentials
- Kubernetes secrets
- Docker authentication data
- CI/CD tokens
.envfiles and application secrets
Cryptocurrency Wallet Data
The malware reportedly searched for wallets associated with:
- Bitcoin
- Litecoin
- Dogecoin
- Zcash
- Dash
- Monero
- Ripple
Local System Intelligence
It also targeted:
/etc/passwd- Shell history
- Local logs
- Environment configuration data
This combination suggests the attackers were pursuing both cloud compromise and direct financial theft.
Why Docker Users Were Also at Risk
The project’s release workflow included a build-and-push container job that automatically generated Docker images from the same compromised source code.
As a result, organizations using containerized deployments were also exposed. Systems that relied on floating tags such as latest, or environments without strict version pinning, may have automatically retrieved the malicious image without manual approval.
This reinforces a critical supply-chain lesson: containers inherit the trustworthiness of their upstream build pipelines.
Detection and Rapid Community Response
The malicious upload was reportedly identified by community member crisperik, who opened a GitHub issue alerting maintainers shortly after publication.
A clean replacement version, 0.23.4, was quickly released. While this reduced the exposure window, any environment that installed 0.23.3 or pulled affected images should be considered potentially compromised.
Immediate Response Actions for Affected Users
Organizations and developers who installed the malicious package or container image should take immediate incident response steps:
1. Rotate All Secrets
Immediately rotate:
- Cloud credentials
- API keys
- SSH keys
- CI/CD tokens
- Database passwords
- Git credentials
2. Rebuild from a Known Safe State
Restore systems, CI runners, or containers from trusted backups or clean images.
3. Audit for Unauthorized Access
Review:
- Cloud activity logs
- Git repository access logs
- CI/CD execution history
- Container registry pulls
- Outbound network traffic
4. Pin Dependency Versions
Avoid using floating dependency or container tags in production pipelines.
Broader Supply-Chain Security Lessons
This incident demonstrates how modern attackers increasingly target build systems, automation tokens, and CI/CD workflows rather than individual endpoints.
Even highly trusted open-source packages can become attack vectors when workflow security is weak. To reduce risk, organizations should implement:
- Least-privilege CI tokens
- Pull request isolation for workflows
- Signed release verification
- Dependency provenance checks
- Runtime egress monitoring
- Continuous software bill of materials (SBOM) tracking
As open-source ecosystems continue to power modern infrastructure, securing the release pipeline is now just as important as securing the code itself.