• Posted by: Eng. Donya Bino
• December 11, 2025

How Malicious Packages Cause Developers to Leak API Keys

The majority of API key leaks do not happen because developers want to leak an API key. They usually happen by accident, through regular activity such as adding a library, testing a tool, or running a quick script.

Once you import a bad or hacked library into your app, the problem begins. The bad libraries do not reveal themselves; they will wait for an opportunity to read environment variables or scan local directories.

Once they find something interesting, API keys, secrets, tokens, they send it off to an attacker.
And because everything looks “normal,” no one notices until the damage is done.

How Malicious Packages Pull It Off
Attackers don’t need anything complex. The techniques are usually simple and blend right into legitimate code.

The most common ways in which we see API keys leaked are:
1. Retrieval of Environment Variables
Many teams during development store keys in .env files or environmental variables. A malicious package can access any environment variable it finds the second it runs.
If it’s an npm or Python package with an installation script? Even easier, it triggers before the app even launches.

2. Scanning Local Project Files
Some projects include keys directly in config files.
Attackers know this, so their packages quietly scan directories like:
1. /config
2. /secrets
3. .git/
4. .env
If they find something useful, they bundle it and send it out.

3. Git Token Harvesting
Tokens saved in Git clients or global configs are a goldmine.
A malicious package only needs a few lines of code to read:
1. .gitconfig
2. Git credential helpers
3. Cached tokens
After that, private repos become an open book.

4. Typosquatting
One misplaced character, requests vs request or color vs colour and you’re installing the wrong thing.
These lookalike packages often contain one job: steal secrets.

What This Looks Like in Real Life
We’ve seen situations where a single npm install or pip install pulled in a malicious dependency that immediately scanned the machine.

Developers didn’t notice anything unusual.
Builds still worked.
Apps still launched.
But behind the scenes, the package had already exfiltrated:
1. cloud API keys
2. database credentials
3. GitHub tokens
4. service account keys
In a few cases, attackers used the stolen keys.

How Teams Can Reduce the Risk Without Slowing Down
You don’t need a heavy process, just habits that make these attacks harder to pull off.
1. Double-check packages before installing
Look at:
1. the maintainer
2. the repository
3. the update history
4. whether the name looks “off”
A 10-second check saves a lot of cleanup time.

2. Lock dependencies
Use package-lock.json, requirements.txt, or similar.
Locked dependencies mean fewer surprises from unexpected updates.

3. Keep secrets out of local environments when possible
Local dev doesn’t always need production-level keys.
Smaller blast radius = safer mistakes.

4. Employ a Secret Scanner
Utilize the secret scanners in GitHub, GitLab, and any IDEs that have built-in secret scanners for detecting exposed keys. While these tools do not provide 100% detection, they provide detection for many of the more common mistakes that people make.

5. Regularly Rotate Your Keys
Regularly rotating keys limits the time frame wherein stolen credentials can be used. If your old Key(s) are no longer valid, then they can no longer harm you.