Guy Korolevski, JFrog Security Researcher | 27 Mar, 2026 The JFrog security research team has identified a compromise in the widely usedtelnyxPyPI package (~3.8M downloads). As of now, the package has been quarantined by PyPI. This ongoing compromise is also being tracked by theopen source community. The compromised package was identified independently by JFrog’s security scanners and other security researchers such as@CharlieEriksenand@ramimacisabird. TheTelnyx Python library(telnyxon PyPI) is a carrier-grade SDK for integrating global voice, messaging, and AI services into Python 3.9+ applications. Its popularity has surged to over670,000 monthly downloads(as of March 2026), driven by its performance in low-latencyAI Voice Agentworkflows and its modern, type-safe architecture generated via Stainless. It is a leading enterprise alternative to Twilio, favored for its asynchronoushttpxsupport and cost-efficiency in high-concurrency environments. On March 27th, new versions oftelnyxwere uploaded to PyPI -4.87.1and4.87.2, containing malicious code similar to the previous attacks we've seen by TeamPCP. The payload was inserted in thetelnyx/_client.pyfile. In order to masquerade as legitimate activity of the package, the payload is delivered inside a valid WAV (audio) file, which matches the purpose of the library, as an AI voice agent. The malicious package downloads the valid WAV file, extracts a malicious encoded payload from its “audio” frames, and executes it. It is unknown at this point how the library was compromised, but it is likely a direct result of each of TeamPCP's recent attacks on the open source ecosystems, hitting NPM, PyPI (like this week’slitellmcompromise), Go, OpenVSX and GitHub repositories. The malicious code is injected inline. A base64-encoded blob (_p) holds the Linux-specific second stage. The obfuscated strings in the Windows path are decoded at runtime via a simplebase64.b64decodehelper. ForWindows machines, the script builds the path which persistence will be created in -%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exeand creates a .lock file (msbuild.exe.lock) to prevent re-execution within 12 hours.It then proceeds to download a “wav” file viahxxp[:]//83[.]142[.]209[.]203:8080/hangup.wav. The downloaded wav file containswithin its framesan executable encrypted by base64 and XOR operations. The file is decoded by using the first 8 bytes of it as the key. The decoded binary is written into the persistence path and then immediately launched silently usingCREATE_NO_WINDOW. The “hangup.wav” payload file is currently unavailable for download, so the malware’s second stage Windows payload is currently unknown. For non-Windows machines, the payload is downloaded viahxxp[://]83[.]142[.]209[.]203[:]8080/ringtone[.]wav, which also contains within its frames a base64-encoded and XORed payload. Once again the script decodes it using the first 8 bytes of the payload, then proceeds to execute it immediately using the python process, capturing the output into a temp file. All the data gathered by the downloaded payload is encrypted (AES-256-CBC + RSA-4096 envelope) and POSTed tohxxp[://]83[.]142[.]209[.]203[:]8080/with the headerX-Filename: tpcp.tar.gz. The use of asymmetric encryption (RSA) makes sure the payload can only be decrypted by TeamPCP. This method looks exactly like the one we've seen in recent attacks, with the same exact exfiltration code, but with a different C2 URL. Theencoded public keyused in previous attacks to encrypt the data isexactly the sameas this compromise, linking this attack directly to the recentlitellmPyPI package compromise: Analysis of the Linux WAV payload indicates an exact match to the payload of litellm compromise, with the only difference being the service names (sysmonin litellm vsaudiomonin telnyx), for the full analysis of the payload, read thelitellm analysiswe published earlier this week. As of now, the WAV payload has been taken offline. Similarly to the Windows payload (hangup.wav) - the payload URL seems to be inactive (times out). This means that currently TeamPCP’s payload does not work as they intended,However,we still recommend for the following remediation steps to be taken immediately. As we've seen in thelitellmattack a few days ago, a similar payload managed to exfiltrate a lot of credentials from infected systems. Looking at the telnyx malicious payload, we can observe a few important facts - This unfortunately means that man in the middle (MitM) attackers, in the local network or otherwise, can essentially piggyback on these requests. Any MitM attacker, even outside of TeamPCP, could respond with their ownringtone.wavwith the proper formatting, containing any arbitrary payload, and that payload would be happily executed by the malicious versions of Telnyx.