Telnyx被塞了2个毒版本，黑客把木马藏进WAV文件

3月27日，PyPI仓库里两个看似平常的版本号——4.87.1和4.87.2——让数千个Python项目踩了雷。攻击者TeamPCP把窃密代码塞进音频文件，用"音乐"做掩护完成了供应链投毒。

这不是他们第一次得手。过去几个月，Trivy、KICS、litellm都栽在同一伙人手里。这次的目标是telnyx，一个用于云通信的Python库。开发者如果在这两天升级了依赖，等于亲手把钥匙交给了小偷。

音频文件成了特洛伊木马

TeamPCP的玩法比常见的base64编码隐蔽得多。他们在C2服务器上放了两个WAV文件：Windows用户收到"hangup.wav"，Linux和macOS用户收到"ringtone.wav"。

Socket的分析还原了完整攻击链：第一阶段，恶意代码藏在telnyx/_client.py里，包一导入就触发；第二阶段，从WAV音频数据中提取载荷；第三阶段，内存中执行数据收集器，最后加密外传。整个过程在自毁型临时目录里完成，几乎不留痕迹。

Ossprey Security点破了这层设计的心思："直接把可执行文件或base64块扔在C2上，网络检测和EDR秒级拦截。包进WAV里，流量看起来就像有人在下载铃声。"

Windows版的后续尤其阴损。提取出的程序被丢进Startup文件夹，伪装成"msbuild.exe"——这是Visual Studio的正经组件名，系统每次启动自动运行，用户很难察觉。

Linux和macOS版反而"克制"一些：没有持久化机制，干完活就删干净。Endor Labs的Kiran Raj和Rachana Misal认为这种分化是刻意为之——类Unix系统的防御工具更敏感，不留痕迹比长期潜伏更安全。

PyPI令牌从哪泄露的

攻击者怎么拿到telnyx的发布权限？目前没实锤，但最可能的答案藏在之前的litellm事件里。

「我们认为最可能的途径就是litellm那次入侵本身，」Endor Labs的研究人员说，「TeamPCP的收集器扫遍了所有导入litellm的系统——环境变量、.env文件、shell历史。如果有开发者的机器同时装了litellm，又能访问telnyx的PyPI令牌，那个令牌早就在TeamPCP手里了。」

这种"滚雪球"式的权限扩散，是供应链攻击最头疼的地方。一个库的沦陷，可能连带拖垮几十个有发布权限的关联项目。PyPI目前把telnyx项目隔离了，但 damage 已经造成。

被窃取的数据打包成"tpcp.tar.gz"，通过HTTP POST发往83.142.209[.]203:8080。收集范围相当广：凭证、配置文件、环境变量，开发者日常接触的核心资产几乎全在清单上。

开发者现在该做什么

如果你或你的CI管道在3月27日之后升级过telnyx，立即回退到4.87.0。检查依赖锁定文件，确认没有夹带这两个版本。

更麻烦的是溯源。攻击链的自毁设计让取证极难——临时目录递归删除，内存执行不留文件，WAV文件本身看起来人畜无害。企业安全团队可能需要从网络流量或DNS日志里找线索，看有没有设备连接过那个C2地址。

这次事件暴露了一个长期被忽视的盲区：PyPI令牌的保管。很多小团队把发布权限绑在个人开发者账号上，而个人机器的安全水位参差不齐。litellm的教训表明，一个被入侵的开发者环境，足以让攻击者获得通往其他项目的跳板。

TeamPCP的命名规律也值得关注——"tpcp.tar.gz"里的缩写，和攻击者代号一致。这种签名式的傲慢，说明他们并不担心被追踪，或者对自身的反溯源能力足够自信。

PyPI的隔离机制这次反应算快，但"事后灭火"的模式终究被动。当攻击者开始用音频隐写术绕过检测，防御方需要重新评估：那些看起来正常的文件下载，到底在传输什么？

截至发稿，telnyx的维护者尚未公开说明令牌泄露的具体环节。如果你是该项目的用户，最后一个值得问自己的问题是：你的环境里，还有多少PyPI令牌是从未被轮换过的？