2026 年 3 月，PyPI 生态圈再次遭受供应链攻击。知名通信服务提供商 Telnyx 的 Python SDK 包被植入恶意代码，版本 4.87.1 和 4.87.2 成为攻击入口。这一事件与同一时期发生的 LiteLLM 包被黑事件均出自同一个威胁组织 TeamPCP 之手，但两者在攻击目标、Payload 特征和影响面上存在显著差异。本文将从攻击链分析入手，对比两次事件的异同，并给出可操作的防御与检测建议。

攻击链路剖析

Telnyx 事件的核心在于攻击者获取了包的发布凭据后，直接向 PyPI 推送了包含恶意代码的版本。根据安全研究团队的溯源，攻击者的攻击路径大致可分为四个阶段。首先是凭据窃取阶段，攻击者通过何种渠道获取 Telnyx 包的发布令牌目前尚未完全公开，但安全社区普遍认为与此前 TeamPCP 针对 CI/CD 工具的攻击有关，该组织此前曾通过窃取 Trivy 的 CI/CD 令牌来下发恶意 npm 包。其次是版本投毒阶段，攻击者在 2026 年 3 月上旬同时发布了 4.87.1 和 4.87.2 两个版本，这两个版本在官方更新日志中没有任何预告，制造了版本跳跃的异常。第三是 Payload 执行，与传统依赖混淆攻击不同，Telnyx 的恶意代码被设计为在 import 时立即执行，无需等待显式的函数调用。安全研究人员发现，恶意代码利用 WAV 文件隐写技术编码敏感信息，这是该攻击区别于其他供应链事件的显著特征。最后是数据外传，Payload 会收集受害环境的凭据信息并通过隐蔽渠道发送。

值得注意的是，Telnyx 攻击的 Payload 设计比典型的凭据窃取更为精细。研究显示，攻击者使用了多阶段的恶意软件架构，首阶段用于环境探测，次阶段根据目标环境特征选择合适的凭据收集策略。这种差异化 Payload 表明攻击者对目标生态系统有较深的理解。

与 LiteLLM 事件的对比分析

将 Telnyx 事件与同期的 LiteLLM 事件进行对比，可以更清晰地理解供应链攻击的多样性。LiteLLM 是一个被广泛使用的 LLM 代理库，月下载量达数百万次，主要服务于 AI 应用开发者。攻击者针对 LiteLLM 的策略与 Telnyx 有所不同。

在攻击目标层面，LiteLLM 作为 AI 基础设施的关键组件，其被黑直接影响大量 LLM 调用的代理层，理论上可以窃取用户的 API 密钥和模型调用日志。Telnyx 作为通信 SDK，影响的是 VoIP 和短信业务相关的应用，受害者更偏向通信行业和客服系统集成商。

在 Payload 投递机制层面，LiteLLM 攻击使用了经典的 .pth 文件注入技术。恶意代码被写入 site-packages 目录下的 .pth 文件，这会导致每次 Python 解释器启动时自动执行，影响范围覆盖全局 Python 环境。Telnyx 则采用了更隐蔽的隐写术手段，通过 WAV 文件传递指令，增加了静态分析的难度。

在影响层面，LiteLLM 事件由于涉及 AI 代理层，理论上可影响所有通过该库调用大模型的用户，包括 OpenAI、Anthropic、Azure OpenAI 等多种后端。Telnyx 事件则主要影响使用该 SDK 进行电话、短信通信的企业，其泄露的凭据可能包括 SIP 认证信息、API 密钥等通信特有的敏感数据。

从防御角度看，两次事件都揭示了同一个根本问题：Python 生态对包发布流程的信任链过于脆弱。攻击者只需要获得 PyPI 账号或发布令牌，即可向所有下游用户投毒，而终端用户几乎无法在安装前识别恶意包。

可落地的检测清单

针对类似 Telnyx 和 LiteLLM 的供应链攻击，安全团队应当建立多层检测机制。以下清单可直接用于日常安全运维和事件响应。

第一，版本异常检测。监控 PyPI 包的版本发布行为，对短时间内的大版本跳跃保持警惕。Telnyx 从 4.87.0 直接跳至 4.87.1 和 4.87.2，缺少中间版本且无官方公告，这是明显的异常信号。建议在 CI/CD 流水线中加入版本比对步骤，对比 PyPI 官方最新版本与项目锁定版本是否一致。

第二，安装行为监控。在安装依赖时启用详细日志模式，捕获 install 过程中的网络请求和文件系统操作。恶意包常在 setup.py 或 init.py 中植入隐藏的网络请求，监控这些行为可以及时发现异常。建议使用 pip install --verbose 并对日志进行自动化审计。

第三，依赖锁定与哈希校验。在项目中启用 pip-compile 或 poetry lock 生成依赖锁定文件，确保所有依赖包版本固定不变。同时，通过 pip hash 命令计算包的实际哈希值并与官方发布校验，可以有效防止篡改。最佳实践是搭建私有的 PyPI 镜像，仅同步经过安全扫描的包版本。

第四，运行时行为审计。在测试环境或沙箱中执行包导入操作，监控网络流量和进程行为。Telnyx 恶意版本在 import 时会尝试连接外部 C2 服务器，通过网络流量分析可以快速定位。建议将此类检测集成到 SIEM 或自动化安全测试流程中。

第五，CI/CD 令牌轮换。供应链攻击的根本入口通常是 CI/CD 系统中的泄露凭据。建议对所有 PyPI、npm、Docker Hub 等生态的发布令牌实施最小权限原则，并定期轮换。TeamPCP 组织的多次攻击均以窃取的 CI/CD 令牌为起点，这一点尤为关键。

防御架构建议

仅依赖检测不足以应对高危供应链攻击，需要从架构层面建立纵深防御。首先，实施依赖安全扫描，在 CI 流水线中加入 Safety、PyUp 或 SNYK 等 SCA 工具，对依赖漏洞和恶意包进行自动化检测，并将扫描结果纳入部署卡点条件。其次，推行内部镜像策略，对于生产环境使用的依赖，搭建私有 PyPI 镜像并通过安全团队审核后再同步到内部仓库，可以有效阻断直接安装官方恶意包的攻击路径。第三，建立包签名验证机制，尽管 PyPI 目前尚未强制包签名，但可以使用 pip 的 --require-hashes 模式强制校验每个包的 SHA256 哈希，将信任链从「发布即可信」转变为「显式验证才可信」。第四，引入运行时保护，在应用启动时通过探针检测异常的包加载行为，一旦发现可疑的 import 或网络外传行为立即告警并阻断。

Telnyx 和 LiteLLM 事件提醒我们，供应链安全不是单一环节的责任，而是需要从包维护者、平台运营者到最终用户全链路共同参与。随着 AI 和通信基础设施日益依赖开源生态，这类攻击的破坏力将持续增强。安全团队应当将供应链安全视为与边界安全同等重要的防御阵地，建立常态化的监控、检测和响应机制。

资料来源：The CyberSec Guru 报道 PyPI telnyx Package Compromised: TeamPCP Supply Chain Attack；SafeDep 安全分析 Compromised telnyx on PyPI: WAV Steganography and Credential Exfiltration；DataDog Security Labs LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP Campaign。