In Q1 2025, Sonatype tracked 17,954 malicious packages, with 56% classified as data exfiltration. Most installed cleanly, passed import checks, and returned the expected API responses. The theft happened between the call and the response. The SDK Gets the Keys Before Your Code Does An API client SDK sits between application code and the API server. Every credential the application sends passes through the SDK first. STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY, and GITHUB_TOKEN live in environment variables the entire process inherits, accessible to the SDK before any application code runs. Installing an SDK is a one-line decision: npm install paysafe-client. No one audits the code before executing it. The tacit assumption is that public registries like npm and PyPI guarantee package integrity, an assumption the numbers directly contradict. Dependency confusion adds another surface: npm and PyPI prefer the public version when its version number exceeds the internal private registry. An attacker publishing paysafe-client@2.0.0 to npm reaches any pipeline depending on the name without a registry lock. In Q2 2025, over 4,400 packages specifically targeted API tokens. Total malicious package volume grew 188% year-over-year in the same period. The Interception Proxy: A Working SDK That Also Exfiltrates The most dangerous variant does not break the application. The malicious SDK makes the real API call, returns the legitimate response, and sends credentials to the attacker's server in parallel. Integration tests pass because responses are correct. The exfiltration is a side channel invisible to every observability layer in the application. Two attack subtypes operate under this threat class. The interception proxy makes the real API call and exfiltrates in parallel. The fake-response facade returns a fabricated response with no actual API call. The Socket.dev-documented July 2026 campaign against PaysafeCard, Skrill, and Neteller published 17 packages on npm and PyPI. Each returned fabricated 200 OK responses mimicking the real API structure. The actual payment APIs were never contacted. Credentials went to an ngrok-free.dev domain controlled by the attacker. Socket.dev flagged it in 6 minutes, but 4 versions (1.0.0 through 1.0.3) had already been distributed. The packages included anti-sandbox checks: they skipped machines with fewer than 2 CPU cores or VM-indicative usernames. The working-SDK cover makes integration tests completely useless as a detector: the test passes precisely because the SDK is functioning. The Solana FakeFix (JFrog) used postinstall lifecycle hooks as the execution primitive. The hooks ran during npm install or pip install, before any application code ran. Four Campaigns Prove This Is a Pattern, Not an Anomaly In 2018, the event-stream attack (poisoned transitive dependency, conditional payload) exploited 2 million weekly npm downloads. The original maintainer transferred ownership. The new maintainer added flatmap-stream with an encrypted payload that overrode Credentials.getKeys() to steal Copay Bitcoin wallets. The payload only activated in Bitpay's production environment, making test environments useless for detection. In 2023, 27 PyPI packages targeted IT professionals, exfiltrating AWS, Azure AD, GitHub OAuth, Dropbox, MongoDB, and Twilio credentials across 56,866 occurrences (THN reporting). The targets were engineers with multi-cloud access, not end users. In March 2026, LiteLLM suffered the most industrialized attack of the period (code injection + .pth persistence). The TeamPCP group compromised Trivy's CI credentials, gained publish access to LiteLLM's PyPI account, and published a backdoored package. The vector was a .pth file in site-packages: Python executes .pth files at interpreter startup, before any application import. The package had 95 million monthly downloads, reached approximately 119,000 downloads before PyPI quarantined the package roughly 40 minutes after publication, and the attacker's archive contained credentials from an estimated 434,000 CI/CD pipeline runs. In July 2026, the Paysafe campaign (fake-response facade, zero traffic to declared API) rotated obfuscation per package. None of the 17 files shared the same hash, making signature-based blocklists useless. Four versions distributed before detection shows that reactive detection is not a viable defense. Why Integration Tests, SAST, and API Monitoring All Miss This Integration tests validate API responses. A malicious SDK returning correct responses passes every assertion. No test checks outbound traffic during SDK calls because no standard test framework captures TCP connections opened by the process during execution. SAST scanners analyze application source code. node_modules/ and .venv/ are excluded by default in every major scanner, and the attack lives exactly in that excluded layer. npm integrity checks confirm the package was not tampered with in transit; malicious packages published with correct hashes pass this check without alerts. The correct hash of a malicious package is as valid as the correct hash of a legitimate one. API gateways monitor inbound requests from your IP. The exfiltration uses the same egress path as legitimate calls, but to a different domain, outside monitoring scope. The LiteLLM .pth mechanism runs before any application instrumentation, making the exfiltration invisible to application logs, APM, and distributed tracing. Lockfiles protect direct dependencies; the event-stream attack hit a transitive dependency that never appeared in the final application's lockfile. Three Observable Signals That Expose SDK-Level Interception Dual egress: Legitimate SDKs make 1 connection per API call. Interception proxies make 2. Any additional outbound connection opening during an SDK call to a domain outside the declared API surface is a compromise indicator. Zero traffic to the declared domain: An SDK presenting itself as a Stripe client but never calling api.stripe.com is definitively malicious. The Paysafe packages are the canonical fake-response facade: 17 packages returned fabricated responses with zero traffic to the declared payment APIs. Fake-response SDKs are detectable because the expected domain never appears in outbound traffic, an obvious deviation from any historical baseline. .pth file with code in site-packages: In Python, any .pth file containing execution code rather than paths is a compromise indicator. The LiteLLM attack used exactly this vector. Capture Signal 1 with strace/dtruss or eBPF: trace outbound network syscalls during SDK initialization. Signal 2 is visible in mitmproxy: zero TLS handshakes to the declared API domain. Signal 3: scan site-packages/ for any .pth file containing executable code. The MAGO Intel Signal MAGO Intel (intel.mago.team) maps expected API call graphs per service. The tool tracks each destination domain per API operation. When a credential-bearing request to a known API domain co-occurs with an outbound call to an unrelated domain, that pattern is anomalous. MAGO Intel surfaces it as a topology difference in the request graph. True proxy SDKs produce 2 TLS sessions per SDK call. The ratio of unique destination IPs per API operation shifts from 1:1 to 2:1, a detectable signal without prior knowledge of the specific attack. Fake-response SDKs show zero traffic to the declared domain, a detectable deviation from any baseline. The proxy adds C2 round-trip latency to API response time; P99 drift on the affected endpoint class is a secondary signal that confirms the first. Runtime detection is the only layer that sees both the legitimate response and the exfiltration call simultaneously. Pairing this with strict per-service egress allowlists and SLSA/Sigstore provenance via npm audit signatures and PyPI Trusted Publishers closes most active vectors today. Pin exact versions in lockfiles. Restrict network access in dependency installation environments. The attacker does not need your code to trust the wrong server. The attacker needs your SDK to call an extra one.