PyPI Package With 1.1M Downloads Hijacked to Push Infostealer

The popular Python package elementary-data has been compromised in a supply chain attack that pushed malicious code to approximately 1.1 million monthly users. Version 0.23.3 contained an infostealer targeting developer credentials and cryptocurrency wallets.

What makes this incident worse: the malicious release propagated beyond PyPI. The project's automated CI/CD workflow builds Docker images directly from the package code and uploads them to container registries. Attackers got a two-for-one deal—anyone pulling the tainted package version or the corresponding Docker image received the payload.

Supply Chain Attacks Keep Coming

This is the fourth significant PyPI supply chain compromise in the past week alone. We covered the PyTorch Lightning incident on May 1 where versions 2.6.2 and 2.6.3 were weaponized by the TeamPCP threat actor for credential theft. Before that, similar tactics hit SAP npm packages with the Mini Shai-Hulud payload.

The pattern is consistent: compromise a maintainer account or exploit a gap in the publishing workflow, inject credential-stealing code, and harvest tokens from developers who have access to corporate infrastructure and cloud environments.

What elementary-data Does

elementary-data is a data observability platform that helps data engineers monitor data quality, track schema changes, and identify pipeline issues. The package integrates with data warehouses, databases, and orchestration tools—meaning users typically configure it with credentials to production systems.

That makes elementary-data users high-value targets. A compromised developer machine running this package likely has access to Snowflake credentials, database connection strings, and cloud service tokens.

How the Attack Worked

According to initial reports, the attacker pushed a malicious version 0.23.3 that targeted developer data and cryptocurrency wallets for theft. The specific infostealer variant hasn't been publicly identified yet.

The attack surface extended beyond direct PyPI downloads due to the project's automated build workflow. When the malicious code entered the repository, the CI pipeline:

1. Built the package from source code
2. Created a Docker image containing the compromised code
3. Uploaded the Docker image to a container registry

Anyone using the Docker image instead of installing via pip received the same malicious payload. Container-based deployments don't always receive the same scrutiny as direct package installations, creating a blind spot.

Affected Systems and Remediation

If you installed elementary-data version 0.23.3 via pip or pulled the corresponding Docker image, assume your development environment is compromised.

Immediate steps:

1. Remove version 0.23.3 and install a known-good version
2. Rotate any credentials stored in environment variables, config files, or credential managers on affected machines
3. Review cloud service access logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs) for unauthorized API calls
4. Check cryptocurrency wallet activity if any wallet data was accessible from the compromised system
5. Scan for persistence mechanisms—infostealers often drop secondary payloads

For containerized deployments, rebuild images from verified source and redeploy. Don't just update the base image version.

Why This Keeps Happening

PyPI and npm don't require package maintainers to use hardware security keys for authentication. Maintainer accounts get compromised through credential stuffing, session token theft via infostealers on their personal machines, or phishing. Once an attacker controls a maintainer account, they can push arbitrary code to millions of downstream users.

The OAuth token abuse trends we analyzed last week show a 146% increase in attacks targeting these authentication mechanisms. Attackers understand that developer credentials are worth more than typical corporate user accounts—they provide access to source code, deployment pipelines, and production infrastructure.

Broader Supply Chain Context

Supply chain attacks against package registries have become routine. According to Sonatype's State of the Software Supply Chain report, attacks on open source packages increased 700% between 2019 and 2025.

The challenge is structural. Open source maintainers often work unpaid and lack resources for security tooling. Package registries serve millions of packages and can't manually review every release. CI/CD pipelines automatically rebuild downstream dependencies, amplifying the blast radius of any compromise.

Organizations depending on open source packages should:

• Pin dependencies to specific versions rather than floating ranges
• Use lockfiles and verify checksums
• Monitor for unusual package updates via tools like Dependabot or Snyk
• Run dependency installations in sandboxed environments before production deployment
• Require code review for dependency version bumps, treating them like any other code change

For teams building internal security awareness, our malware defense guide covers how supply chain attacks bypass traditional perimeter defenses.

Indicators of Compromise

At publication time, specific IOCs including file hashes and C2 infrastructure for this incident have not been publicly released. Monitor the PyPI security advisories for updates.

The PyPI security team has removed version 0.23.3. If your package manager shows this version as available, your mirror may be caching the malicious release.