Malicious SDK packages pass tests and import checks while stealing credentials

The pattern: a working SDK with a hidden side channel

Malicious SDK packages are increasingly built to keep applications behaving normally while siphoning secrets, according to a dev.to analysis of recent supply-chain incidents. The piece describes two variants: one where the package performs the genuine API request, hands the correct response back to the application, and ships credentials to an attacker-controlled server in parallel; and one where it never contacts the real API at all and fabricates a plausible response. The article labels these the "interception proxy" and the "fake-response facade." Either way, integration tests stay green, because the application sees exactly what it expects.

SDKs are attractive targets because of where they sit. An API client library mediates between application code and the API server, so credentials such as STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY and GITHUB_TOKEN are visible to the package before any application code runs. Installation is usually a one-line command that nobody audits first, resting on an implicit assumption that npm and PyPI vet what they host. The numbers say otherwise: the analysis cites Sonatype figures of 17,954 malicious packages tracked in Q1 2025, 56% of them classified as data exfiltration. In Q2 2025, more than 4,400 packages specifically went after API tokens, and overall malicious package volume grew 188% year over year.

Dependency confusion widens the surface. Both npm and PyPI resolve the higher version number, so publishing a public package with a bumped version can reach pipelines that depend on an internal name without a registry lock.

Four campaigns, 2018 to 2026

The analysis walks through incidents that show the pattern is established:

• July 2026, Paysafe: Socket.dev documented 17 packages on npm and PyPI impersonating PaysafeCard, Skrill and Neteller clients. Each returned fabricated 200 OK responses matching the real API structure while routing credentials to a domain on ngrok-free.dev. Socket.dev flagged the campaign within six minutes, but versions 1.0.0 through 1.0.3 had already been distributed. The packages skipped machines with fewer than two CPU cores or VM-like usernames, and no two files shared a hash, blunting signature-based blocklists.
• March 2026, LiteLLM: a group the piece names TeamPCP compromised Trivy's CI credentials to gain publish access to LiteLLM's PyPI account. The backdoor used a .pth file in site-packages, which Python executes at interpreter startup before any import. The package, with 95 million monthly downloads, reached roughly 119,000 downloads before PyPI quarantined it about 40 minutes after publication. The attacker's archive reportedly held credentials from an estimated 434,000 CI/CD pipeline runs.
• 2023, PyPI: 27 packages targeted IT professionals, harvesting AWS, Azure AD, GitHub OAuth, Dropbox, MongoDB and Twilio credentials across 56,866 occurrences, per The Hacker News.
• 2018, event-stream: a poisoned transitive dependency riding 2 million weekly npm downloads. The injected flatmap-stream package carried an encrypted payload that overrode Credentials.getKeys() to steal Copay Bitcoin wallets, and it only activated in Bitpay's production environment.

A separate Solana campaign documented by JFrog, dubbed FakeFix, used postinstall lifecycle hooks to run code during installation.

Why standard defenses miss it

Each conventional layer has a structural blind spot. Integration tests assert on responses, and a malicious SDK returning correct data passes every assertion; no mainstream test framework records the TCP connections a process opens during execution. SAST scanners exclude node_modules/ and .venv/ by default, which is precisely where this code lives. Registry integrity hashes confirm a package was not tampered with in transit, and a malicious package published with correct hashes satisfies that check. API gateways watch inbound traffic, while exfiltration leaves through the same egress path but toward a different domain outside monitoring scope. The .pth vector runs before application instrumentation even exists. Lockfiles pin direct dependencies, yet event-stream arrived as a transitive one.

Runtime signals that expose the exfiltration

The piece identifies three observable indicators. First, dual egress: a legitimate SDK opens one connection per API call, so a second outbound connection to a domain outside the declared API surface signals compromise. Second, zero traffic to the declared domain, which definitively unmasks fake-response packages. Third, any .pth file in site-packages containing executable code rather than paths. These can be captured with strace or dtruss, eBPF, and mitmproxy respectively.

The analysis also points to MAGO Intel, a tool that maps expected API call graphs per service and flags cases where a request to a known API domain co-occurs with traffic to an unrelated domain, with added round-trip latency showing up as P99 drift. Recommended hardening combines runtime detection with per-service egress allowlists, provenance verification via npm audit signatures and PyPI Trusted Publishers, and exact version pinning in lockfiles.

Why it matters

Package installation is a trust decision executed millions of times a day, and the incident data shows credential-targeting packages growing fast. This attack class is invisible to the exact checks teams rely on, because nothing about the application's observable behavior changes. Detection has to shift to runtime network behavior and provenance, and the timelines here, roughly 40 minutes to quarantine LiteLLM and four Paysafe versions shipped before takedown, mean reactive responses will always trail the first wave of victims.