Imagine you install a routine update to a Python library your team uses every week. No alerts fire. Your antivirus stays quiet. Your developers keep coding. Three days later, every OAuth token, API key, and stored credential in your environment has been silently harvested and sold on a dark web forum.
That is not a hypothetical. That is exactly what the TeamPCP supply chain campaign did — and if your team uses open source packages, SaaS integrations, or dev tooling, you need to understand how it works.
What Is a Supply Chain Attack, Really?
A supply chain attack does not break down your front door. It poisons the water supply.
Instead of attacking your network directly, threat actors compromise a trusted third-party tool — a software package, a plugin, a development extension — that you willingly install. Once that malicious code runs inside your environment, it has the same access you gave the legitimate tool.
For small business IT teams and MSPs, this is particularly dangerous because the attack surface is invisible. You are not clicking a phishing link. You are doing your job.
TeamPCP: A Real, Active Campaign That Hit Trusted Dev Tools
According to SANS ISC, the TeamPCP campaign entered a monetization phase after successfully compromising security scanners and popular open source packages — meaning attackers had already harvested what they came for and were cashing out.
The mechanics were brazen. According to The Hacker News, TeamPCP pushed malicious versions of the widely used telnyx Python package to PyPI — one of the most trusted open source repositories in the world — and hid a credential-harvesting stealer inside WAV audio files to evade detection. Developers who updated their dependencies pulled down malware without any warning.
This campaign was serious enough that, according to an earlier SANS ISC update, CISA added TeamPCP to its Known Exploited Vulnerabilities (KEV) catalog — elevating it from a community-level threat to a federally recognized active risk. If CISA is tracking it, your clients' environments are in scope.
The VS Code Problem: Even Your IDE Is an Attack Vector
It gets broader. According to The Hacker News, a vulnerability in Open VSX allowed malicious VS Code extensions to bypass pre-publish security checks entirely. Developers installing extensions from what appeared to be a legitimate, vetted registry could have been running attacker-controlled code inside their development environment.
Think about what a developer's IDE has access to: source code repositories, environment variables, .env files, SSH keys, cloud provider credentials, and OAuth tokens for every SaaS integration the project touches. A compromised extension is not a nuisance — it is a master key.
OAuth Tokens Are the Real Target
When attackers talk about supply chain campaigns, they are usually not after your data directly. They are after your tokens — because tokens are portable, persistent, and often have no expiration.
OAuth tokens are the credentials that let your CRM talk to your email platform, your project management tool talk to your Slack workspace, and your CI/CD pipeline push code to production. Steal one token, and you may inherit access to dozens of connected systems — silently, without triggering a password reset or MFA challenge.
The scale of this problem is staggering. According to The Hacker News, GitGuardian's State of Secrets Sprawl 2026 report found 29 million new hardcoded secrets — tokens, API keys, and credentials — exposed on public GitHub in 2025 alone, a 34% year-over-year increase. Developers are accidentally committing credentials to public repos at an accelerating rate, and attackers are scraping them in real time.
We covered a related credential exposure scenario in our post on API key exposure and credential leaks — the downstream damage from a single leaked key can cascade into unexpected cloud billing attacks and data loss.
What Small Business IT Teams Must Do Right Now
You do not need an enterprise security budget to reduce your exposure. You need a process.
1. Audit your open source dependencies today.
Run a software composition analysis (SCA) tool against every project and internal tool that pulls from PyPI, npm, or similar registries. Look for packages that were recently updated, have unusual maintainer changes, or have low download counts relative to their claimed popularity.
2. Lock your package versions.
Do not use floating version references like telnyx>=2.0. Pin exact versions (telnyx==2.0.1) and require explicit review before any dependency update gets merged. This does not prevent all supply chain attacks, but it eliminates the silent auto-update vector.
3. Rotate OAuth tokens and API keys on a schedule.
Tokens that never expire are a gift to attackers. Implement a quarterly rotation policy for all OAuth tokens, service account credentials, and API keys. If a token was compromised six months ago, rotation limits the blast radius.
4. Treat your dev environment like production.
Developers' machines have access to everything. Enforce the same endpoint protection, MFA requirements, and network monitoring on dev workstations that you apply to servers. The TeamPCP campaign and the Open VSX vulnerability both exploited the assumption that developer tooling is low-risk.
5. Monitor for secrets in your repositories.
Enable GitHub's secret scanning alerts if you use GitHub. For broader coverage, tools like GitGuardian can scan commits in real time. As we discussed in our guide to vibe coding and AI-generated code risks, AI-assisted development is accelerating the rate at which credentials accidentally end up in code.
6. Review third-party app permissions.
Audit every OAuth application connected to your Microsoft 365, Google Workspace, Salesforce, or other SaaS platforms. Revoke anything that is no longer actively used. Attackers love dormant, over-permissioned integrations — they are quiet and rarely reviewed.
For MSPs managing multiple clients, this audit process is also directly relevant to your own internal security posture. Our MSP internal security checklist covers the specific steps for protecting your toolchain from becoming a pivot point into client environments.
The Uncomfortable Truth About Open Source Risk
Open source is not inherently dangerous — it powers most of the modern internet. But the trust model that makes it powerful also makes it exploitable. When you pip install a package, you are trusting a maintainer you have never met, a registry that has been targeted by nation-state actors, and a build pipeline you cannot inspect.
The TeamPCP campaign did not find a zero-day in your firewall. It found a developer who ran pip install --upgrade on a Tuesday morning.
Your security posture is only as strong as the least-scrutinized package in your dependency tree.
Take Action
Supply chain attacks succeed because they hide inside trusted processes. The best defense is visibility — knowing what is running in your environment, what has changed, and what looks anomalous before an attacker monetizes their access.
Oscar Six Security's Radar ($99/scan) gives small business IT teams and MSPs an affordable way to run proactive vulnerability scans that surface exposed credentials, misconfigured integrations, and third-party risk indicators before they become breach notifications.
Don't wait for a CISA KEV alert to find out your environment was in scope.
Focus Forward. We've Got Your Six.
This article was originally published on Oscar Six Security Blog.
Top comments (0)