Live data from Hacker News

Telnyx package compromised on PyPI

telnyx.com

51–60 of 153 posts

Re: Telnyx package compromised on PyPI

#51
post #29

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 like it so far. Did you call phone support at the time and ask about it? I find it's easy enough to get in a call with a human.

I did, they asked me to open a support ticket, which I did, and the last response I got was:

> We've reviewed the details you provided and updated your case with the necessary information. It is now being routed to the appropriate team for further support.

That was July 2025!

Re: Telnyx package compromised on PyPI

#52
post #23

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…

Love it! Let those pip users find the compromised packages for us uv users.

Re: Telnyx package compromised on PyPI

#53
post #23

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…

I am a slow adopter of uv. I'll be honest, its speed has never been a big deal to me and, in general, it is YAPT (yet another package tool), but this one feature may make me reconsider. Pinning versions is less than perfect but I would really like to be able to stay XXX days behind exactly for this reason.

I think the python community, and really all package managers, need to promote standard cache servers as first class citizens as a broader solution to supply chain issues. What I want is a server that presents pypi with safeguards I choose. For instance, add packages to the local index that are no less than xxx days old (this uv feature), but also freeze that unless an update is requested or required by a security concern, scan security blacklists to remove/block packages and versions that have been found to have issues. Update the cache to allow a specific version bump. That kind of thing. Basically, I have several projects and I just want to do a pip install but against my own curated pypi. I know this is the intent of virtual envs/lock files, etc, but coordinating across projects and having my own server to grab from when builds happen (guaranteeing builds won't fail) is import. At a minimum it would be good to have a 'curated.json' or something similar that I could point pip/other package managers to to enforce package policies across projects. These supply chain attacks show that all it takes is a single update and your are in big trouble so we, unfortunately, need more layers of defense.

Re: Telnyx package compromised on PyPI

#54
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?

Re: Telnyx package compromised on PyPI

#55

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.

In a lot of cases, it's not really clear whose second factor would authorize publishing a package that was uploaded from a CI/CD system. Is it any project owner? Anyone from the same GitHub organization? etc. > An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want. Agreed, that's why a lot of packaging ecosystems (including PyPI) have moved towards s…

The 2FA of whatever account is publishing the package. I'm pretty sure Pypi already has this figured out except they seem to allow you to make an API key which just bypasses checking a 2nd factor.

Re: Telnyx package compromised on PyPI

#56
post #23

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…

Love it! Let those pip users find the compromised packages for us uv users.

Until everyone waits 7 days to install everything so the compromise is discovered on the 8th day.

End result will be everyone runs COBOL only.

Re: Telnyx package compromised on PyPI

#57

Earlier quoted context omitted.

I really am not able to follow this line of reasoning, I am not sure if what you said makes sense and how it relates to uv having a security feature to be on average less safe :/

I believe they are saying that by the time you need something like uv, your project already has too many dependencies. Its the unnecessarily large supply chain that's the problem, and uv exists to solve a problem that you should try to avoid in the first place. I think uv is great, but I somewhat agree. We see this issue with node/npm. We need smaller supply chains/less dependencies overall, not just bandaiding over…

Ah this simplifies what they were saying.

I agree with it that dependency management should be made easier. To be honest, I really like how golang's dependency and how golang's community works around dependencies and how golang has a really great stdlib to work with and how the community really likes to rely on very little depenendencies for the most part as well.

Maybe second to that, Zig is interesting as although I see people using libraries, its on a much lower level compared to rust/node/python.

Sadly, rust suffers from the same dependency issue like node/python.

Re: Telnyx package compromised on PyPI

#58
post #2

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.

Re: Telnyx package compromised on PyPI

#59

Earlier quoted context omitted.

In a lot of cases, it's not really clear whose second factor would authorize publishing a package that was uploaded from a CI/CD system. Is it any project owner? Anyone from the same GitHub organization? etc. > An attacker compromising someone's CI should not give them free reign to publish malicious packages at any time they want. Agreed, that's why a lot of packaging ecosystems (including PyPI) have moved towards s…

The 2FA of whatever account is publishing the package. I'm pretty sure Pypi already has this figured out except they seem to allow you to make an API key which just bypasses checking a 2nd factor.

Which account is publishing the package, in a CI/CD context? It's not clear that any particular account is, since the set of people who can trigger a workflow in CI/CD aren't necessarily (and in fact aren't often) the same set of people who can create an API token on PyPI.

Re: Telnyx package compromised on PyPI

#60

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

Post reply on HN