PyPI package – A backdoored elementary-data version was pushed to PyPI (and Docker images) to steal secrets and crypto wallets. Misryoum explains what happened and what to do next.
A widely used open-source Python tool tied to the dbt ecosystem was hit by a supply-chain attack that smuggled an infostealer into a seemingly legitimate PyPI release.
The package. elementary-data. pulled roughly 1.1 million monthly downloads on PyPI and is used by data and analytics teams to observe pipelines.. In Misryoum’s reporting. the key fact is that the malicious version didn’t rely on taking over the maintainer’s accounts; instead. it abused the project’s release workflow to produce a backdoored artifact that looked official.
What the attackers actually did
The dangerous release was elementary-data 0.23.3.. That version was pushed to PyPI after an attacker manipulated GitHub Actions so attacker-controlled shell code executed during the workflow.. Misryoum notes the tactic matters: rather than immediately swapping in a rogue package. the attacker slipped the payload into the release process itself.
The workflow abuse hinged on a script-injection weakness in a GitHub pull request context.. From there, the pipeline was able to expose the workflow’s GITHUB_TOKEN.. With that token. the attacker could forge a signed commit and tag matching the release version. then trigger the project’s legitimate release pipeline.
Why Docker images got infected too
A second step expanded the blast radius beyond Python.. The project’s release workflow also built and pushed a Docker image as part of its deployment packaging.. As a result. the same backdoor that landed in the PyPI distribution also reached the Docker artifacts. including tags such as ghcr.io/elementary-data/elementary:0.23.3 and a :latest tag.
That combination is one reason supply-chain incidents become so painful operationally.. Teams often pull Python dependencies and container images through separate channels, but a workflow-level compromise can tie both together.. When both are affected. it’s not enough to uninstall a package—you may need to address the runtime images your systems are already using.
What the malware looked for (and what it stole)
The malicious distribution contained elementary.pth, designed to run automatically at startup and load a secrets-stealing payload. The scope described in Misryoum’s coverage is broad and targeted at the exact places developers and CI systems keep valuable credentials.
The payload focused on SSH keys and Git credentials. cloud provider access materials for AWS/GCP/Azure. and secrets typically stored in Kubernetes. Docker. and CI environments.. It also aimed at common developer artifacts like .env files and developer tokens. and it searched for crypto wallet files for currencies including Bitcoin. Litecoin. Dogecoin. Zcash. Dash. Monero. and Ripple.
Beyond credential theft. the malware also attempted to capture system information such as files under /etc/passwd. logs. and shell history.. That mix is consistent with attackers who want both immediate access (credentials and keys) and follow-on visibility (what the environment “knows” so they can move faster).
How quickly it was caught—and why the fix didn’t fully undo the damage
A community member. crisperik. spotted the malicious upload and raised an issue on the project’s GitHub. alerting the maintainer and shrinking the window during which the compromised version was freely available.. Misryoum stresses, however, that a clean follow-up release cannot un-compromise systems that already downloaded or pulled the infected artifacts.
The project then published elementary-data 0.23.4 as a replacement.. But anyone who already installed elementary-data==0.23.3 or pulled Docker images tagged with the compromised versions could still be running the backdoored code.. In other words, “patch released” and “risk removed” are not the same moment for incident response.
The analysis described in Misryoum’s narrative indicates systems that did not pin versions were particularly at risk, because automated dependency updates could silently fetch the backdoored build.
What teams should do now
If you used elementary-data 0.23.3 or deployed containers based on the affected image tags, Misryoum recommends treating the environment as compromised until proven otherwise. The practical checklist is straightforward: rotate all secrets and restore affected systems from a known safe point.
Rotation needs to be thorough because the payload explicitly sought many categories of credentials—cloud access, CI secrets, tokens, SSH keys, and more. In parallel, verify what images and dependency constraints are actually running in production and in your build pipelines.
Finally, review your software supply-chain hygiene.. Version pinning won’t stop a workflow exploit by itself. but it can prevent dependency managers from automatically pulling a new. infected build.. For organizations that rely on containers. pinning image digests and tightening release validation can reduce the chance that :latest-style tags become an accidental distribution channel for compromised artifacts.
The uncomfortable takeaway for the industry is that release pipelines are now part of the attack surface. not just the code they ship.. Misryoum expects more projects to revisit how they validate pull requests. secure workflow steps. and limit what tokens can do during release automation—because the fastest way to scale trust is also the fastest way to scale harm when trust is manipulated.