top of page

Deceptive Packages - How Malicious Code Hides in Plain Sight on npm and Beyond


Pixel art: a computer with a skull on the screen, an arrow hitting a bullseye, a shield with a checkmark, and a folder labeled "npm". Dark tones.
Pixel art: a computer with a skull on the screen, an arrow hitting a bullseye, a shield with a checkmark, and a folder labeled "npm". Dark tones.

Open-source software is the backbone of modern development. Package managers like npm and PyPI allow developers to share and reuse code at scale. But this very openness is also its weakest link. A single typo or hasty install can open the door to malware, surveillance, or data theft and it's happening more often than you might think.


The Threat Behind Typos and Mimicry


One of the most common attack vectors in this space is typosquatting uploading a malicious package that looks nearly identical to a legitimate one. The difference might be just one letter, a plural, or even a Unicode character that looks like something else.


A recent example, uncovered by security researcher @bzvr_ (Leonid Bezvershenko),

shows just how subtle this deception can be. He identified two malicious npm packages requests-promises and requestz-promises uploaded to mimic the widely used but deprecated request-promise library.


With over 1.3 million weekly downloads, it's a lucrative target. Any developer who types the wrong name, or copies an outdated tutorial, could unknowingly install malware.


These fake packages often contain:


  • Obfuscated payloads designed to evade code review.

  • Post-install scripts that run automatically when the package is added.

  • Remote access tools that connect to external servers and exfiltrate data.


Another package, empty-validator-plugin, used Unicode steganography to hide its true purpose. Instead of readable code, it embedded dangerous logic behind characters that appear harmless or invisible to the human eye. Such tactics are crafted to defeat both automated scanners and human inspection.


This Isn't Just npm’s Problem


While npm is frequently targeted due to JavaScript’s popularity, Python’s PyPI has been under siege too. Attackers have uploaded packages like urlib3, requestss, or setup-tools, banking on typos or confusion.


In both ecosystems, these packages can:


  • Steal credentials or tokens stored in .env files.

  • Inject cryptominers into running systems.

  • Serve as initial access vectors for further exploitation.

  • Alter build or deployment pipelines in CI/CD environments.


It’s an attack that requires no brute force, no exploit just a misplaced character.


The Psychology of Trust


Developers often install packages without scrutinizing them. If it looks right, it's assumed safe. This trust is what attackers exploit. Since many of these packages are discovered after they’ve been installed hundreds or thousands of times, the damage is often already done.


Think of your dependency tree as an extension of your codebase. Every package you install brings its own risks and responsibilities.


Why Security Scanners Aren’t Enough


Automated tools like npm audit and pip-audit are useful, but they rely on known vulnerability databases. Typosquatted and newly created malicious packages often fly under the radar until a researcher flags them.


Even GitHub’s Dependabot won’t alert you if you install a malicious package from the start because it doesn’t know it’s malicious yet.


That’s why human diligence is still the best defense.


8 Practical Steps to Protect Your Development Pipeline


  1. Double-check package names especially when installing something new or unfamiliar.

  2. Copy install commands only from trusted documentation or official GitHub repositories.

  3. Look at the download count and publishing date on npm or PyPI. A recently published package with a name like a popular library should raise a red flag.

  4. Inspect the package manually — click through to the repository and review the code or package.json.

  5. Enable lockfiles (package-lock.json, poetry.lock) to freeze versions and detect unexpected changes.

  6. Use tools like Snyk, or npm’s own advisory feed for deeper insight into packages.

  7. Run packages in a sandbox if you're unsure about what they do.

  8. Keep your CI/CD environments secure — don't expose secrets, tokens, or environment variables unnecessarily.


What the Ecosystem Needs


This is not just a developer issue it’s a supply chain security crisis. As we shift toward microservices, containers, and rapid prototyping, the volume of dependencies per project grows exponentially. One popular open-source project today can have hundreds of transitive dependencies each a potential target.


Platforms like npm and PyPI are improving, but detection is reactive. Researchers like @bzvr_ play a crucial role in identifying threats, but community-wide awareness and education are essential for proactive defense.


Closing Thoughts


A typo should never compromise an entire application. Yet, this is the reality for thousands of developers each year. Security doesn’t start at the firewall anymore it starts at npm install.


The next time you add a new dependency, pause for a moment. That small command might save you hours of incident response later.


More Information:


Related Posts

bottom of page