> If the version shown is 4.87.1 or 4.87.2, treat the environment as compromised.
More generally speaking one would have to treat the computer/container/VM as compromised. User-level malware still sucks. We've seen just the other day that Python code can run at startup time with .pth files (and probably many other ways). With a source distribution, it can run at install time, too (see e.g. https://zahlman.github.io/posts/python-packaging-3/).
> What to Do If Affected
> Downgrade immediately:
> pip install telnyx==4.87.0
Even if only the "environment" were compromised, that includes pip in the standard workflow. You can use an external copy of pip instead, via the `--python` option (and also avoid duplicating pip in each venv, wasting 10-15MB each time, by passing `--without-pip` at creation). I touch on both of these in https://zahlman.github.io/posts/python-packaging-2/ (specifically, showing how to do it with Pipx's vendored copy of pip). Note that `--python` is a hack that re-launches pip using the target environment; pip won't try to import things from that environment, but you'd still be exposed to .pth file risks.
I'm working on a multi signature system for file authentication that can detect unauthorized file publications. It is self-funded, open source, auditable, self hostable, accountless. I'm looking for testers and feedback, don't hesitate to contact me if interested.
More info at https://asfaload.com/
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.
So both this and litellm went straight to PyPI without going to GitHub first.
Is there any way to setup PyPI to only publish packages that come from a certain pattern of tag that exists in GH? Would such a measure help at all here?
Yes: if you use a Trusted Publisher with PyPI, you can constrain it to an environment. Then, on GitHub, you can configure that environment with a tag or branch protection rule that only allows the environment to be activated if the ref matches. You can also configure required approvers on the environment, to prevent anyone except your account (and potentially other maintainers you’d like) from activating the environment.
If they have compromised the token wouldn't that mean the developer is compromised and such access can be used to just put "curl whatever" into the build and publish that payload on pypi?
Don't have the token on your hands. Use OICD ideally, or make sure to setup carefully as a repository secret. Ensure the workflow runs in a well permission read, minimal dependency environment.
The issue with OICD is that it does not work with nested workflows because github does not propagate the claims.
PyPI only supports 2FA for sign-in. 2FA is not a factor at all with publishing. To top it off, the PyPA's recommended solution, the half-assed trusted publishing, does nothing to prevent publishing compromised repos either.
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.
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 Guix PM in this context can create an isolated environment and import PyPI packages for you adapted into Guix Scheme manifest files. Not just Python, Perl, Ruby, Node... if you have to use dangerous our propietary environments for the enterprise, (not for personal computing), at least isolate them so the malware doesn't spread over.
> If the version shown is 4.87.1 or 4.87.2, treat the environment as compromised.
More generally speaking one would have to treat the computer/container/VM as compromised. User-level malware still sucks. We've seen just the other day that Python code can run at startup time with .pth files (and probably many other ways). With a source distribution, it can run at install time, too (see e.g. https://zahlman.github.io/posts/python-packaging-3/).
> What to Do If Affected
> Downgrade immediately:
> pip install telnyx==4.87.0
Even if only the "environment" were compromised, that includes pip in the standard workflow. You can use an external copy of pip instead, via the `--python` option (and also avoid duplicating pip in each venv, wasting 10-15MB each time, by passing `--without-pip` at creation). I touch on both of these in https://zahlman.github.io/posts/python-packaging-2/ (specifically, showing how to do it with Pipx's vendored copy of pip). Note that `--python` is a hack that re-launches pip using the target environment; pip won't try to import things from that environment, but you'd still be exposed to .pth file risks.
Nice thing about VMs is that it's easy to have a daily snapshot, and roll it back to before compromise event.
I'm working on a multi signature system for file authentication that can detect unauthorized file publications. It is self-funded, open source, auditable, self hostable, accountless. I'm looking for testers and feedback, don't hesitate to contact me if interested. More info at https://asfaload.com/
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
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.
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...
So both this and litellm went straight to PyPI without going to GitHub first.
Is there any way to setup PyPI to only publish packages that come from a certain pattern of tag that exists in GH? Would such a measure help at all here?
Yes: if you use a Trusted Publisher with PyPI, you can constrain it to an environment. Then, on GitHub, you can configure that environment with a tag or branch protection rule that only allows the environment to be activated if the ref matches. You can also configure required approvers on the environment, to prevent anyone except your account (and potentially other maintainers you’d like) from activating the environment.
If they have compromised the token wouldn't that mean the developer is compromised and such access can be used to just put "curl whatever" into the build and publish that payload on pypi?
Don't have the token on your hands. Use OICD ideally, or make sure to setup carefully as a repository secret. Ensure the workflow runs in a well permission read, minimal dependency environment. The issue with OICD is that it does not work with nested workflows because github does not propagate the claims.
*OIDC
How can we get the wav ? `curl -A "Mozilla/5.0" "http://<C2C_EndPoint>/hangup.wav"` does hang.
No ... I tried hard. But still get a timeout.
> 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?
PyPI only supports 2FA for sign-in. 2FA is not a factor at all with publishing. To top it off, the PyPA's recommended solution, the half-assed trusted publishing, does nothing to prevent publishing compromised repos either.
Yeah at this point I’d really like for pypi to insist on 2FA and email workflows for approving a release.
Yeah it means you don’t get zero click releases. Maybe boto gets special treatment
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.
Wonder if publishing keys were compromised in one of the previous PyPI incidents...
I received an email from them about the vulnerability but I don't remember ever using them
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?
> I see their repo's Initial Commit was on Jan 2026... quite a new package!
That's incorrect, the repo and package date back to 2019
The Guix PM in this context can create an isolated environment and import PyPI packages for you adapted into Guix Scheme manifest files. Not just Python, Perl, Ruby, Node... if you have to use dangerous our propietary environments for the enterprise, (not for personal computing), at least isolate them so the malware doesn't spread over.