PyPI's abuse volume has climbed steadily since 2022, with ReversingLabs, Checkmarx, Phylum, and Sonatype each publishing quarterly counts that consistently show thousands of malicious Python packages removed per year. Within that volume, a cluster of activity attributed to the account name mexalz and related aliases stood out for a few reasons: the operator reused a recognizable payload pattern across dozens of packages, cycled through fresh PyPI accounts as they were banned, and concentrated on typosquats of popular data-science and automation libraries.
This post walks through what security researchers have publicly documented about the mexalz cluster, how the payloads were structured, and what the campaign tells us about the state of PyPI abuse enforcement. It is not a disclosure of new indicators; it is a consolidation of research already published by multiple vendors and a reading of what those findings mean for defenders.
Who is 'mexalz' and what did they publish?
The mexalz identifier refers to a PyPI publisher account, and by extension to a cluster of related accounts that researchers have linked through shared code patterns, consistent package-name themes, and overlapping command-and-control infrastructure. The account published Python packages whose names typosquatted widely-used libraries in the data-science, web-scraping, and trading-bot ecosystems. Package counts in public write-ups vary, but observers including Phylum and Sonatype reported dozens of packages from this cluster being taken down across multiple waves.
The packages presented themselves as legitimate tools, often copying the README or even the function signatures of the library they impersonated. The malicious behavior was typically hidden in the setup.py install script or in an __init__.py module that executed on first import.
What does the mexalz payload actually do on install?
The mexalz payload typically does three things on install: it stages an infostealer, it collects browser and credential artifacts, and it exfiltrates the collected data to a remote endpoint. The staging step usually involves fetching a second-stage script from a paste site or a disposable host, writing it to a temporary location, and executing it in a background thread so the pip install command returns normally to avoid raising suspicion.
The infostealer stages that researchers have documented from this cluster focus on the same targets that commodity Windows stealers do: Chromium-based browser profiles, Discord tokens, cryptocurrency wallet files, and saved session cookies from common SaaS applications. On macOS and Linux the payloads are less polished but still attempt to read shell history, SSH keys, and cloud credential files such as ~/.aws/credentials.
How did the operator evade PyPI's abuse pipeline?
The operator evaded PyPI's abuse pipeline primarily by cycling accounts, by using free-tier email providers with disposable addresses, and by varying the obfuscation of the install-time payload across waves. When an account was banned, a near-identical set of packages would reappear under a new account within hours or days, often with the package names slightly mutated to avoid trivial string matching.
PyPI's current abuse response relies on a combination of automated signal collection, volunteer reports through the security@python.org address and the project's malware-reporting form, and manual review by the Packaging Working Group and trusted researchers. The mexalz cluster exploited the gap between automated signal and manual takedown, which on a best day is measured in hours and on a bad day in days.
Why does typosquatting still work on PyPI?
Typosquatting still works on PyPI because the registry's default behavior is to accept any available name on a first-come basis, because the pip install command does not warn about distance from popular names, and because developers frequently paste install commands from blog posts, LLM outputs, and Stack Overflow answers without verifying the spelling. PyPI introduced two-factor authentication requirements for maintainers of top projects and rolled out attestation signatures in 2024, but neither control addresses a user who simply types the wrong name.
The recent rise in slopsquatting, where attackers claim names that large language models hallucinate when asked for a library recommendation, has raised the stakes further. The mexalz cluster predates the slopsquatting wave but uses the same underlying weakness: the trust model assumes that if you typed the name, you meant that name.
Which ecosystems and projects were most impacted?
The data-science ecosystem was most impacted, followed by the crypto-adjacent automation-bot ecosystem. Packages with names resembling requests, beautifulsoup4, pandas, numpy, selenium, and various Binance and Solana client libraries were among the most frequent targets in public reports. These are libraries that developers install dozens of times a week on fresh environments, which maximizes the operator's chance of catching a typo or a copy-paste error.
Academic and research environments appeared disproportionately in victim reports, in part because their install hygiene tends to be weaker than enterprise environments and in part because student laptops often contain a mix of personal credentials and research-institution credentials that are valuable for follow-on intrusion.
What can a Python shop do beyond "don't typo"?
A Python shop can do several things beyond "don't typo." First, pin direct and transitive dependencies in a lockfile, using pip-tools, uv, poetry, or an equivalent, and review lockfile changes in code review. Second, disable or carefully audit setup.py install scripts; modern PEP 517 and PEP 621 packaging allows most projects to declare their build entirely in pyproject.toml, removing the need for arbitrary install-time code execution. Third, run installs in a sandbox with constrained network egress, so a stager that tries to fetch a second-stage payload from a paste site fails closed.
Finally, subscribe to advisories from the vendors and registries that actively track PyPI abuse. PyPI itself publishes a security page, the Python Packaging Authority maintains the advisory database pypa/advisory-database, and GitHub's Advisory Database ingests many of these reports. None of these sources is complete on its own; the union of them catches more.
What does the mexalz campaign tell us about PyPI in 2026?
The mexalz campaign tells us that PyPI in 2026 is still structurally vulnerable to account-cycling typosquatters, and that the registry's enforcement speed is bounded by human review capacity rather than by technical capability. The Python Software Foundation has publicly hired security engineers to work on this problem, and the rollout of Trusted Publishing and attestation signatures is a real step forward, but neither feature prevents a malicious account from publishing a new package with a deceptive name.
The systemic fix, if one exists, probably looks like a combination of registry-side reputation, ecosystem-wide policy on install-time code execution, and per-organization curation via proxies or mirrors. None of those is a single-vendor problem; all of them require coordinated investment over years.
How Safeguard.sh Helps
Safeguard.sh applies reachability analysis to PyPI dependency trees, reducing noise by 60 to 80 percent so that a typosquat flagged deep in a transitive chain still surfaces, while false positives from unused code paths stay quiet. Griffin AI autonomously opens pull requests that replace typosquat candidates with their legitimate counterparts and pins the correct version. Eagle classifies PyPI packages using behavioral and structural signals, catching install-time stagers and obfuscated payloads that static name-matching misses. The Gold registry mirrors only vetted Python packages, SBOM generation covers 100 levels of dependency depth to expose buried mexalz-style payloads, and container self-healing rebuilds images automatically when a PyPI dependency is pulled or reclassified.