TeamPCP strikes again - telnyx 4.87.1 and 4.87.2 on PyPI are malicious

[-]

sailing67@reddit

steganography inside wav files is actually kinda genius in a terrifying way. had to audit our entire pip install pipeline after the litellm thing last week and honestly it was a mess - half our devs were just running installs without pinning versions. the fact that payload hides in audio files means most network monitoring tools wont even flag it. definitely time to start treating pypi packages like untrusted binaries by default

Reply

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

Reply

[-]

Worth_Trust_3825@reddit

Do you terminate TLS when traffic enters your network? How do you expect network monitoring tools to help you here?

Reply

[-]

palecvstepler@reddit

This is the third time this year we've watched someone slip malicious code into a popular package like it's a well-dressed regular ordering a drink they've already poisoned. Supply chain attacks have officially moved past "theoretical risk" into "Tuesday afternoon at TeamPCP."

Reply

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

Reply

[-]

pip25hu@reddit

Perhaps it's time to overhaul the publish process of PyPI (and potentially other repos) after these recent incidents.

Reply

[-]

AlSweigart@reddit

How? > This tool mismatch is evidence that the attacker uploaded the malicious wheels manually using a stolen API token, not through the repository’s automated release process. > The publishing workflow uses a static PyPI API token stored as a GitHub Actions secret: [...] > No PyPI trusted publisher (OIDC) is configured. Trusted publishers bind PyPI uploads to a specific GitHub repository and workflow, making stolen tokens useless outside that context. Without this protection, anyone with the API token can upload any version from any machine. What can PyPI do about this? (Legit question.)

Reply

[-]

pip25hu@reddit

I am no expert on the topic, but at least for releases that are already initiated by a human (who triggers the publish workflow, for example), it could perhaps be useful to require some kind of 2FA confirmation before PyPI would publish the release. The API token, while constrained in scope, is essentially a password. So some of the mitigations against stolen passwords could apply here as well.

Reply

[-]

tedivm@reddit

This is exactly it. If the only way to publish a release (and thus trigger a release workflow) required MFA then this problem would be significantly smaller. A simple toggle in the settings that says "Release creation requires reauthentication" would go a long way towards making us all more secure.

Reply

[-]

tedivm@reddit

PyPI is in the process of doing so, pushing OIDC for credentials. The problem is GitHub Actions. The "package management" for GitHub actions is absolute garbage. You either have to hardcode to a sha, or pick a tag that hackers can change if they take over the repo. This round of supply chain attacks is caused completely by GitHub Actions failing to build proper security and allowed the Trivy action to be stolen. GitHub has known about this for years now and just hasn't cared to fix it.

Reply

[-]

dsffff22@reddit

Does OIDC really help here? Honestly I can only see that making the initial attacks slightly more difficult and leaving more traces, however the attackers very likely sit on millions of stolen credentials from developers now, which can be easily abused now for spreading more malware. So we are way past that point and need protections against the upcoming attack vectors.

Reply

[-]

tedivm@reddit

OIDC is a credentialess system. If the only way you can publish is via OIDC then you don't have credentials that can just be sat on, you have ephemeral tokens that only work from specific IP ranges. I am not trying to say that OIDC by itself solves this problem, but it does help a lot. If you also enforce MFA for publishing (tagging releases in GitHub) that further reduces the attack surface. If there's a bullet proof method for solving this I'd love to hear it.

Reply

[-]

dsffff22@reddit

I wouldn't really say It's 'credentialess', as signing keys are also credentials. Also, IP ranges can be spoofed and should be never used as an authorization mechanism either, even worse in this case I could just make my own GitHub Action Workflow and do the malicious actions from the same IP Range without any spoofing. The blog article clearly states they got their own code execution in the publishing workflow, OIDC won't help you here at all, you can just modify the execution to put your malware straight up in the published binary, the only downside is you may leave a bigger trace. Package registries need stricter guidelines and have to work under the assumption GitHub actions are an awful security nightmare. Which includes MFA for publishing on their site, limit the publish time window per accounts and much more. And the problem is quite big right now as plenty of developers got their keys/secrets stolen and are in the hand of this group right now. Which most likely allows them to publish code to plenty of libraries right now.

Reply

[-]

tedivm@reddit

Please explain how you spoof IP addresses in a TCP connection. You can fake the message in one direction, but the return message is never getting back to you.

Reply

[-]

dsffff22@reddit

Do you even know how TCP works? You can just guess the ISN in theory which is just 4 bytes, takes some time, but that's not secure enough, then you can just send data, and you can essentially ignore If you ever got anything back. There are also many possibilities to affect routing being able to inspect the traffic and other things. Of course with Encryption in the equation like TLS or Quic that becomes more difficult or impossible, but relying on IP as Authorization stays insufficient.

Reply

[-]

tedivm@reddit

Literally no one said anything about *relying* on it. I've said the word "layer" so many times now that I am beginning to wonder if you're just not capable of reading complete sentences. I understand networking just fine. The fact that you think you're going to IP spoof API interactions with publishing registries is something I'll believe when you show me a working POC.

Reply

[-]

dsffff22@reddit

Didn't you ask 'how you spoof IP addresses in a TCP connection'? If you'd understand networking you'd either ask differently or not at all. You can show the rest yourself with basic high school math, with the Info I've given you. And also to note again OIDC stays an irrelevant 'layer' against that exact attack here as shown earlier.

Reply

[-]

N1ghtCod3r@reddit

GitHub have immutable releases GA now. If used properly, tags pointing to a release cannot be mutated. Unfortunately most projects do not use it.

Reply

[-]

tedivm@reddit

This is not entirely accurate for GitHub actions though. GitHub releases make sure the artifacts associated with the releases themselves can not be changed. However, the attestation is applied to the release itself and not to the tag, and GitHub actions uses the Tag instead of the Release. From my understanding you can still force-push to override the Tag, which in turn will break the attestation (which GitHub doesn't look at). If you read [the official documentation from GitHub on how to publish immutable releases](https://docs.github.com/en/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases) for github actions you'll also notice something interesting. They recommend you tag the release with the full version (v1.8.2 for example) and then move the other tags to point to it (v1 -> v1.8.2, v1.8-> v1.8.2). This is because GitHub doesn't actually support semver, so they emulate it with tags. As a result the actual tag most people point to isn't the immutable release.

Reply

[-]

TOMZ_EXTRA@reddit

So just don't publish via Github actions?

Reply

[-]

tedivm@reddit

If you publish with GitHub Actions you should do two very important things: 1. Isolate your publish job from your other jobs (you can use multi-job workflows, but each job should stand alone). The idea here is that your Trivy security scan and linting should not have the elevated permissions that your publish job does. 2. Utilize the OIDC based permissions to log into the registry, but make sure *only* your publish job has these extra permissions. If you do those two things then you can reduce the blast radius of issues. The problem is that a lot of people don't do those things, for example they might run a trivy scan in the same job as publishing. Then when Trivy is exploited it has access to their publishing token. If the scan was a different job then the exploit would not have resulted in a supply chain attack. Additionally though, GitHub should also fix their shit and adopt the basic practices that other package managers have used for decades now.

Reply

[-]

BattleRemote3157@reddit

TeamPCP is having a field day. Trivy. litellm. Now telnyx.

Reply

[-]

edeltoaster@reddit

Trivy is what started it all. They will have gained access to plenty of pipelines.

Reply

[-]

BattleRemote3157@reddit

exactly, they got lucky and have plenty of credentials

Reply

[-]

GroundbreakingMall54@reddit

hiding the payload in WAV files using steganography is actually insane. and the fact they pushed a bugfix for a casing error in their own malware... these people have better release management than half the companies ive worked for

Reply

[-]

snotfart@reddit

It's not really steganography - they just replaced the wav file data with encrypted code. It would be obvious that it's not a proper .wav file as soon as you tried to play it.

Reply

[-]

ExF-Altrue@reddit

It's absolutely NOT stenography. However I feel like your comment misrepresents what's being done: They still need to read each audio frame one by one, and decode base64 data from them. What's funny is the website's own writeup, admitting that it's not stenography.. Yet doing nothing to change the misrepresentation in their own title x) >This is not true steganography in the traditional sense (hiding data in the least significant bits of audio). Instead, the attacker packs base64-encoded, XOR-encrypted payloads into a valid WAV container. The file has a legitimate WAV header and will pass basic file-type checks, but the audio frame data is entirely payload.

Reply

[-]

saynay@reddit

Strange definition they use. Steganography does not require using the least significant bits specifically, it just requires encoding the data into a different media in a way that is not readily apparent. In some ways, this does fit that definition since it can pass as a valid wav file to the computer.

Reply

[-]

QuickQuirk@reddit

I actually wrote a stegonagraphic system in 2000 that hid data in a WAV file. Fourier transform the wave, replace the high frequency bits with my data, transform back, output WAV file. Sounded like a high pitch hiss that was normal in audio back then. This was before I knew that there was a word for this kind of thing: steganography. Anyway, the important thing was is that I had an onion on my belt.

Reply

[-]

ExF-Altrue@reddit

That's sounds pretty cool, and that could definitely be some spy stuff

Reply

[-]

QuickQuirk@reddit

If I could do that with a (from memory) about a thousand lines of c code on my own at home, imagine what the experts are doing now. That brainless influencer streaming prancing around on camera could be broadcasting state secrets in plain view; those cell tower signal fluctuations carrying nuclear plans... All those unspoken secrets, shouted loudly all around you, unheard :)

Reply

[-]

ExF-Altrue@reddit

Yeah.. But I'm not sure that it's actually required. Exfiltrating information is pretty easy if you already have it in your hands.

Reply

[-]

QuickQuirk@reddit

USB flash drive is boring. Waves upon the ether is much more fun.

Reply

[-]

axonxorz@reddit

The WAV header passes muster, but not the rest of the content. It's still steganography, but I'd argue it's not "true" steganography, the payload cannot be passed "as the original" audio data. Steganography does not require bit-exactness, but at the bare minimum a heavy perceptual similarity should be present.

Reply

[-]

Enerbane@reddit

Right but arguing about what is and isn't "true" steganography isn't especially useful. That's more of a scholarly debate that veers into semantics and linguistics. If we're trying to convey that an attacker hid malicious data inside what at a glance looks like a harmless file, well that's the root of the issue that people should be aware of, and it sure sounds like a kind of steganography. I think a decent analogy would be hiding a secure message on a physical check. If you need to pass a message to somebody and the check helps you avoid the message being obviously detected, it doesn't really matter if the check document itself is malformed. If it looks like a check to an outside observer when you pass it to the recipient, it doesn't matter if the check could ever be deposited at the bank. That only thing that matters is the appearance of a normal exchange, and the anybody that looks at it, but doesn't examine for correctness, will probably be fooled.

Reply

[-]

ivosaurus@reddit

> it just requires encoding the data into a different media in a way that is not readily apparent. Isn't it incredibly apparent as soon as you try to play the audio?

Reply

[-]

saynay@reddit

For sure, so it definitely doesn't fit what would normally be considered 'steganography'. Staganography is classically about hiding data from _people_. Increasingly, people are not the primary entity that is evaluating if data passes the sniff test. If data is disguised as other types of media to get past an automated system, by looking to the scanning tools like valid media, that is certainly something that is at least analogous to steganography.

Reply

[-]

drislands@reddit

Stenography is taking notes, steganography is writing in code. Your autocorrect probably doesn't have it in its dictionary so changed to the former (I just had to add it to mine)

Reply

[-]

Enerbane@reddit

Typically, simple coded messages wouldn't fall under the umbrella of steganography. That is to say, something that is obviously a coded message, and makes no attempt to hide that fact, isn't usually considered steganography. A perfect example is computer programming languages. Instructions are written in a coded language, but nothing is hidden or obfuscated. The message you see is written exactly as intended to convey information. Simple coded messages are simple cryptographic messages. Steganographic coded messages are messages hidden *within* the presentation of the text. The line is absolutely blurry, however. Lots of overlap and no clear line. A good example: Simple code: The eagle has landed. Osprey moves at dawn. Anybody reading that can intuit that the message itself is coded. One needs to know what those terms refer to in order to crack the message. Steganography: The head eagle comes out during evening. Perhaps nearly as obvious that it is a cryptic message, I thought of it on the fly (pun absolutely intended), but the actual message in this case depends on knowing the simple cypher, which is dead simple. The first letter of each word. "The code" Here the message is hidden "within" the text.

Reply

[-]

drislands@reddit

Neat! So that's like Thieves' Cant in Dungeons and Dragons, where otherwise-normal conversation is hiding meaning. Though I should note that my comment you replied to was correcting a typo more than addressing the validity of what they said.

Reply

[-]

drumallnight@reddit

Maybe their message is so long and replies to another topic because there's a hidden message inside it just for you to decode. The rest of us are none the wiser! But you know and Enerbane knows. Fascinating.

Reply

[-]

Enerbane@reddit

Yeah I get that, I was just adding on to the convo! I'm very, very bored today.

Reply

[-]

f311a@reddit

It's not a big deal, honestly. The part that executes the code is very easy to spot. Security vendors always check for \`exec(base64.b64decode\`. It's rarely used for legitimate use cases. hexora audit 4.87.1/2026-03-27-telnyx-v4.87.1.zip --min-confidence high --exclude HX4000 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.

Reply

[-]

cinyar@reddit

"find the hidden payload in innocuous looking data" is like mid-level CTF challenge.

Reply

[-]

wRAR_@reddit

It's a bot.

Reply

[-]

-Nyarlabrotep-@reddit

WAV is an easy target since it's uncompressed lossless data, so if you hide inside the lower bits it likely goes unnoticed, like say hiding inside the case bit of ASCII text. Quick and dirty, and they're not the first to do it.

Reply

[-]

spareminuteforworms@reddit

What's so smart about it. Why would WAV files even exist in the repo?

Reply

[-]

AbrahelOne@reddit

Yeah this WAV stuf made me laugh a little bit, it's crazy lol

Reply

[-]

ExF-Altrue@reddit

What's most shocking to me, is all this work going into making sure that the payload passes automated inspection by encoding it, XORing it, and inserting into into the audio frames of wav files... But the presence of **audio** files in a headless API library during the automated install process? Nah, fam, it's all good. Package managers with their automatic code execution at install are a litteral cancer for devs all around the world, for the libraries they maintain, and therefore for all the users that depend on applications & services that use those libraries.

Reply

[-]

Worth_Trust_3825@reddit

Not very shocking. There just isn't any check for that, nor you could implement such check properly. Where do you draw a line in what can be present in the tarball that you publish? files ending with .py? okay, that breaks any binaries that ship with their own pinned certificates in files, models, and etc. Any checks that you implement will be circumvented, while it will only hamper the users that have no malicious intent. Moreover, how do you define a "headless api library"? Please implement the check in your favorite programming language. Running code on import (not on install, like you rave about) is expected behavior. Java, C sharp and other languages have similar mechanisms (see java's static class level block and c#'s static constructor block).

Reply

[-]

ExF-Altrue@reddit

In my opinion: Whitelist, whitelist, whitelist. Don't define what's not allowed, define what is. If a plugin needs more? I would be very strict and say "send a request to the package manager admins to get an exemption", but people are going to yell at me, so instead I'm going to say: If you need more, the user needs to give its approval. And if an update introduces something new outside of the whitelist? Also approval. Every. Time. (By the way, such user friction will naturally encourage users to use leaner libraries who manage their dependencies carefully, and don't need to install 999 dependencies themselves to determine if a number is odd, or how to add red to their console output... It would make for a more performant & more robust ecosystem all around) Subdependencies? Their version sould always be fixed. As a library manager, you don't tell your users to install "the latest of X", you make them install one *specific* version, and *you* have to manually publish a new version if you want to update your dependencies (= the users subdependencies). Security issues? Well, as a user, you *are* allowed to override the minimum version of something, so that you can take action without having to wait. I've been saying it for years, people don't realize the flimsy house of cards that the current ecosystem is. Although with so many shai huluds and wav stenographies, then maybe people will start to notice...

Reply

[-]

Worth_Trust_3825@reddit

Congratulations. You described maven central.

Reply

[-]

ExF-Altrue@reddit

And there's nothing wrong with that!

Reply

[-]

axkotti@reddit

>the attacker publishes a trojaned version directly to PyPI using stolen credentials while the source repository remains clean. The GitHub source is not a typosquat: package metadata (author, homepage, dependencies) is identical to the legitimate project. Does this mean they also gained access to the keys used to sign the release? My thought would be that just owning credentials to publish things is not enough, and you also need the trusted signature.

Reply

[-]

tedivm@reddit

PyPI doesn't have a concept of signed releases.

Reply

[-]

coderanger@reddit

They have been available since 2024 https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/

Reply

[-]

tedivm@reddit

A digital attestation is not the same as a signed release and would not have solved this problem. > Attestations are signed by an identity, not a key pair: Similar to our recent support for Trusted Publishing, PyPI's support for digital attestations relies upon Open ID Connect (OIDC) identities. By signing attestations with identities, and not a public/private key pair, we mitigate the potential for an individual's key loss or compromise, one of the most common failure cases for PGP signing. This means the same attack vector, stealing a github action, would work because the same thing (the GitHub OIDC Token) being used to log into the server is being used to sign the attestation.

Reply

[-]

coderanger@reddit

If you are comparing apples to apples, attesting your release with the Github identity is equivalent to having your package signing (and thus keys) done in GHA. But you can use other identities (such as a Google Cloud service account) for attestations in the same way that you could (and in your example you seem to be suggesting) doing packaging signing out of band, presumably on a maintainers workstation.

Reply

[-]

Acrobatic_Camp_2758@reddit

Update: Our Engineers found/solved the root cause early this morning!

Reply

[-]

Mooshux@reddit

TeamPCP is getting systematic. Same RSA key, same exfiltration header, same .pth-style injection pattern as the litellm attack. They're working through popular Python packages that show up in AI and telecom workflows. Rotation scope if telnyx ran in any environment during the affected window: SSH keys, cloud credentials, K8s service account tokens, any API keys that were in your shell env or .env files at the time. The trigger is just import telnyx on the affected version, so you don't need to have called any telnyx function for the exfiltration to fire. The structural problem: long-lived credentials sitting in env files are exactly what this attack pattern is designed to grab. Short-lived scoped tokens per session expire before anyone can use what was exfiltrated. Wrote about this after the litellm incident with a breakdown of the rotation surface: [https://www.apistronghold.com/blog/litellm-supply-chain-attack-env-file-phantom-tokens](https://www.apistronghold.com/blog/litellm-supply-chain-attack-env-file-phantom-tokens)

Reply

[-]

BlueGoliath@reddit

Jia Tan please stop.

Reply

[-]

ExF-Altrue@reddit

Right.. ""Stenography"" Payload.txt => Rename => Payload.wav Boom. Stenography!

Reply

[-]

UnbeliebteMeinung@reddit

And still the affected people of this hack doesnt properly care, thats why the worm is still running after a whole month

Reply

Reply to Post

63 Comments