A widely used Python SDK was quarantined on PyPI to limit the supply chain damage. That’s not the surprising part anymore with this being a second noteworthy Python package victim to TeamPCP this week with a malicious dependency.
The Telnyx Python SDK, used for voice and messaging infrastructure, was found to contain malicious behavior embedded into a media file to escape detection when it executes on import. No obvious dependency anomaly or install hooks this time, but simply importing the library is enough to trigger execution whether you use it or not. This varies a bit from the typical reachability analysis scenario because the vulnerable codepath happens at initialization. It also is an adjustment by attackers to adapt with how malware is detected.
With ~742k downloads last month, a compromise like this has the potential to spread across a customer base pretty rapidly if it had not been detected.
This incident tells us a bit more than just being a supply chain problem like LiteLLM, it's an ownership and responsibility problem for building and using Client SDKs.
Summary For Semgrep Customers
The open source and security community across organizations quickly rallied to quarantine the telnyx PyPI package. We have a supply chain rule in place and while we do not have any evidence that any Semgrep customers are affected we will be reviewing this regularly and reaching out. You can check the Advisories to scan and verify you have not pulled any of the compromised versions.
The tl;dr on the Telnyx Package
The compromised package introduced malicious logic directly into the SDK code path. The behavior triggered at import time, meaning developers didn’t need to call a specific function or enable a feature. The act of using the SDK was sufficient.
The payload delivery mechanism was intentionally disguised. Instead of obvious code or executable scripts, it leveraged .wav files as a transport layer. That choice matters less for the specifics and more for what it signals. The attacker assumed the SDK would be trusted enough that its internal handling of external data wouldn’t be closely scrutinized.
This becomes an example of an insecure deserialization security bug of an otherwise trusted audio file.
Client SDKs Role in Software Adoption
Client SDKs occupy an unusual position in many organizations and is an active area for security research.
SDKs break the normal trust model.
Trusted like internal code because they are provided as integration code samples.
Distributed like third-party dependencies by organizations trying to speed up adoption.
Maintained outside core product engineering because they are typically thin clients with little business logic.
In many companies, the client SDKs are owned by developer experience or customer success teams to speed up time to value. The goal is fast adoption and onboarding with clean abstractions that minimize support tickets and time to hello world.
Security review is rarely the primary constraint in releasing a client SDK.
That doesn’t make these teams are careless but highlights a structural expectation gap. The issue isn’t who builds SDKs. It’s often how they’re reviewed.
Customers assume the SDK has been vetted like any other production dependency.
Software vendors assume the SDK is just a thin wrapper over an API and customers will vet their application overall.
As this issue demonstrates, it may be neither. The incentive for teams that build SDKs is time to ‘hello world’, it isn’t shipping secure code, so often they aren't trained on secure coding practices or given adequate tools and time to identify vulnerabilities. This may not be the case for large cloud companies, but for software teams that don’t have the same resources trade-offs may have been made.
The Client SDK Blind Spot
Client SDKs sit in a critical path, running inside your environment, with access to secure credentials, network paths, and sensitive data. We’ve spent years getting better at dependency scanning (SBOMs, Lockfiles, Signature verification, Reachability analysis, etc) but often dismiss the glue code as trivial even though this is where third-party manipulation of data is possible.
SDKs are “known” code from reputable companies with large install bases. Unfortunately, they often bypass the same scrutiny applied to less familiar open source packages because any corporate logo is trusted as doing due diligence.
The attack surface isn’t just within open source supply chain but what vendor libraries you might trust without question.
Why this Pattern Will Repeat
This incident isn’t unique. It’s a natural outcome of how modern software is built.
APIs and Services are product surfaces core to product engineering
SDKs are growth channels and not always considered core product
Adoption speed is prioritized, so security review is uneven
As companies expose APIs as their primary interface to more agentic tools and integration patterns, SDKs become critical distribution mechanisms. The ownership model hasn’t caught up to the risk profile, so it's important for these polyglot deliveries to have a robust security tool to review the code and help prioritize vulnerable code paths.
.jpg)
