把Python从窝里引出来

Python的简洁语法和庞大生态让它成了开发者的心头好，也成了攻击者眼里的肥肉。恶意包不再需要你主动导入——安装那一刻就能拿下机器权限。这篇文章拆解了一个Python包从仓库到你硬盘的全过程，把攻击者能动手脚的七个关键点一个个摊开来看，最后给出几招用得上的防御思路。

Python的暗面

这几年Python的增长曲线几乎是指着天上去的。StackOverflow年度调查和PyPI官方下载数据都指向同一件事：从数据科学到后端服务，Python几乎无所不在。安装一个包有多简单？一行pip install命令。这个便利性背后，是社区多年来建立的信任机制。

问题在于，信任是可以被武器化的。

GitHub 2025年的安全数据摆在那里——恶意软件公告年增69%。更具体地说，GitHub安全公告库中17%的内容与Pip生态有关。这不是一个可以被忽视的数字。TeamPCP这类攻击组织把供应链攻击玩出了花，甚至摸到了微软GitHub子公司内部，Wired报道称他们搞了20波连环攻击。

很多开发者有个根深蒂固的错觉：恶意代码得靠“运行”才能生效。你得import它，调用它的函数，或者执行它的入口点。实际上完全不需要。一个包可以在安装的瞬间站稳脚跟，你连它长什么样都没见过，机器已经开始往外发数据了。

一个包是怎么到你机器上的

在深入聊攻击手法之前，有必要先把Python包的“旅行路线”捋清楚。整个过程可以拆成三层来看：

• 托管层：包从哪里来。PyPI、GitHub、自建服务器，都算。
• 分发层：包以什么格式给你。源码分发包（sdist）还是预编译的wheel，区别不小。
• 安装层：怎么部署到环境里。系统级安装还是虚拟环境，权限和作用范围完全不同。

▲ 图1：Python包安装的分层结构

托管：不只是PyPI

PyPI是默认仓库，pip原生指向它。包的JSON API在 pypi.org/pypi/包名/json ，实际文件托管在 files.pythonhosted.org 上，用blake2b_256哈希来校验。看起来规规矩矩。

但PyPI不是唯一的路。直接从GitHub或GitLab装包也是常规操作，用这种方式拿到的是源码，还得本地构建，这中间留了太多操作空间。更灵活的是自定义Web服务器，只要目录结构合规，pip就能认。

最关键的是pip本身支持多级配置——全局、用户级、环境级都能写死index URL。环境变量PIP_FIND_LINKS之类的参数也能悄悄把路指向别处。攻击者如果能动你的配置文件，后面的事就省心了。

分发：sdist和wheel，各有利弊

源码分发包（sdist）打包成.tar.gz，里面是纯源码加构建指令。装这种包的时候，代码要在你机器上跑一遍构建流程。wheel则反过来，已经是预编译的.zip格式，解压即用。

这里的关键风险点在构建指令。老式的setup.py和新式的pyproject.toml都能控制构建过程，但setup.py是自由脚本，安装时自动执行，没有任何沙箱隔离。pyproject.toml稍微规矩一点——它省不了多少事，但至少结构透明。

▲ 表1：setup.py和pyproject.toml的简要对比

安装：虚拟环境不解决安全问题

虚拟环境（venv）隔离的是依赖版本，帮你避免numpy 1.x和2.x打架的问题。但它隔离不了恶意代码。激活后的虚拟环境用的是同一套文件系统和网络接口，只是包目录和bin分开而已。这不是容器，别把它当沙箱用。

依赖声明散落在各处：setup.py里的install_requires，pyproject.toml里project.dependencies，requirements.txt，Pipfile……攻击者能往任何地方塞私货。现在流行的poetry、uv、hatch这些工具，又把构建任务的复杂度往上抬了一层，对应的攻击面也扩大了。

七个让你背脊发凉的手法

攻击者盯上Python开发者不是没道理的。这群人在公司里通常手握CI/CD流水线、云基础设施、代码仓库的权限。AI工具的兴起又把这个目标群扩了好几圈。

我们按攻击手法拆成两大类来看：构建钩子滥用和包内容滥用。每种手法后面跟着它的操作系统支持、持久性、构建方式、分发类型，方便对照。

手法一：在setup.py里埋雷

适用范围：Windows、Linux、macOS / 持久性：一次性 / 构建方式：setup.py / 分发类型：sdist

setup.py调用distutils的command class来执行预装和后装动作。你在pip install的那一下，攻击者的脚本已经跑完了。BeaconOnInstall这种恶意对象覆写安装行为，执行完就消失，连残留文件都找不到。

▲ 图2：setup.py中包含恶意command class

这个包一装完，后台就开始往外打电话。

手法二：路径配置文件 .pth 的后门

适用范围：Windows、Linux、macOS / 持久性：持久 / 构建方式：setup.py或pyproject.toml / 分发类型：sdist或wheel

.pth文件原本是给Python的sys.path加目录用的，但它有一个鲜为人知的特性——能执行Python单行代码。只要把这个文件丢进site-packages目录，每次Python启动都会执行。

每次。

TeamPCP在对litellm包的供应链攻击中就用了这一招。通过setup.py里command class或者pyproject.toml配合Hatchling的force-include选项，都能把恶意.pth文件写入目标目录。做完后，系统里每次调Python——无论成功还是报错——都会触发载荷。

▲ 图3：setup.py利用command class写入.pth文件

▲ 图4：pyproject.toml写入.pth文件

手法三：劫持站点钩子模块

适用范围：Windows、Linux、macOS / 持久性：持久 / 构建方式：setup.py或pyproject.toml / 分发类型：sdist或wheel

Python的site模块提供了sitecustomize.py和usercustomize.py两个钩子，原本是给企业定制Python环境用的。它们位于sys.path下的目录中，包目录也在搜索范围之内。攻击者把自己的sitecustomize.py丢进去，下次Python启动就会加载。

VIPERTUNNEL后门报告里用过这招，用来加载DLL。实测中装完恶意包后跑个pip freeze，curl就开始往外连了——因为pip本身也是在Python环境里跑的。

手法四：篡改PYTHONPATH环境变量

适用范围：Windows、Linux、macOS / 持久性：持久 / 构建方式：setup.py / 分发类型：sdist

sys.path的生成会合并PYTHONPATH的值。如果能改用户的这个环境变量，攻击者就能把模块搜索路径指到任意地方。跟站点钩子配合起来用威力更大——sitecustomize.py不用放在包目录下也能被找到。setup.py通过distutils command class修改用户profile就行，新shell会话一开就生效。

▲ 图5：setup.py篡改PYTHONPATH环境变量

不过有个局限：当前shell不受影响，得等下次开终端。对于很多开发者来说，这可能就是几分钟后的事。

手法五：藏在__init__.py里的定时炸弹

适用范围：Windows、Linux、macOS / 持久性：有条件的持久 / 构建方式：setup.py或pyproject.toml / 分发类型：sdist或wheel

__init__.py的作用是标识包目录，同时控制模块导入行为。它里面写的代码，每次有人从同目录下导入模块就会执行。攻击者利用这一点，把恶意逻辑藏在开发者很少去翻的__init__.py里。

lightning供应链事件就是典型例子——凭证窃取器就埋在init文件里。触发条件是受害者导入这个包里的某个函数，属于“有条件的持久”。

▲ 图6：从被感染的包导入函数

手法六：执行入口里的李代桃僵

适用范围：Windows、Linux、macOS / 持久性：有条件的持久 / 构建方式：setup.py或pyproject.toml / 分发类型：sdist或wheel

用python -m执行包的时候，入口点是__main__.py。pip自己就是个典型例子。攻击者在__main__.py里塞代码，每次你用-m参数跑这个包就触发。

▲ 图7：__main__.py通过cmd.exe执行命令

另一个更隐蔽的玩法是entry points。包可以声明命令行别名，在bin目录生成可执行文件。如果恶意包的alias跟系统命令重名（比如netstat），环境变量PATH的搜索顺序就成了帮凶。checkmarx之前专门报过这个技巧，能把所有CLI命令都劫持掉。你敲netstat的时候跑的是正常的程序，但恶意代码也同时在后台跑。

▲ 图8：setup.py劫持netstat二进制

▲ 图9：pyproject.toml劫持netstat二进制

手法七：覆盖正规包的函数

适用范围：Windows、Linux、macOS / 持久性：有条件的持久 / 构建方式：setup.py或pyproject.toml / 分发类型：sdist或wheel

这一个招数很聪明。Python允许一个分发包里包含多个包目录，而且项目名和包目录名可以不同。如果两个不同的分发包用了同一个包目录名，内容会合并，目录覆盖文件。攻击者可以建一个看似无害的包，里面重写了pandas的read_json函数，把自己的逻辑嵌进去。

▲ 图10：篡改pandas.read_json的执行流程

▲ 图11：调用被注入的read_json函数

受害者调用这个函数的时候，正常结果照常返回，恶意行为也在暗处执行。排查起来很费劲——你看到的pandas似乎一切正常。

该做些什么

说句实话，没有哪一项防御措施能一劳永逸。恶意包的投放窗口可能只有几小时，但Payload执行只要几分钟，数据外传可以在一小时内完成。根据Mandiant的M-Trends报告，入侵后的驻留时间中位数是九天——足够攻击者把内网摸个遍。

下面这几项建议，对上面七种手法全部适用。

扫描，但要扫对地方

定期审计装好的包是基础操作。pip-audit（pypi.org/project/pip-audit/）用Python Packaging Advisory Database来匹配已知漏洞，可以集成进CI/CD，一有漏洞就断构建。配合Yara规则做已知恶意包的指纹检测，再加一层AST扫描去抓代码里的可疑函数和导入行为。没有一个银弹，但组合起来能拦住大部分常见攻击。

锁住依赖版本

依赖漂移是供应链里最让人头疼的问题之一。用uv.lock、poetry.lock或Pipfile.lock把传递依赖的版本钉死，不只是为了部署稳定，更关键的是防止恶意新版本悄悄滑进来。密码学哈希校验一定要加上，确保从仓库下载到的内容跟当初验证过的版本一致。

装包之前先冷静一下

uv工具的exclude-newer功能值得大力推广——可以设定忽略最近N天内发布的所有包版本。这个“冷却期”给安全社区留出了识别和移除恶意上传的时间。另外，永远别在带敏感权限的本机上编译或安装不信任的包。用临时容器或隔离runner，哪怕出了事，攻击者也拿不到持久立足点。

把家底摸清楚

生成SBOM（软件物料清单），用CycloneDX这类标准把每个组件列清楚。当流行库爆出安全事件时，安全团队能在几分钟内定位受影响范围，而不是花几天去翻代码。维护者那边，PyPI的Trusted Publishing配合OIDC能消除长期API Token的需求，降低凭证泄露后账号被接管的风险。

最后的判断

Python供应连的安全问题不会自己消失。攻击面随着工具链的复杂化还在扩大，用AI辅助开发的趋势又让高价值目标变得更多。上面拆解的七种手法，从最粗暴的setup.py代码执行到最隐蔽的包名混淆，都说明一件事：信任机制本身就是攻击向量。

真正有效的防御不是靠一两项技术，而是把审计、锁定、隔离、可视化拧成一股绳。每个环节都做到位不一定难，难的是意识到每个环节都需要做到位。

参考资料

[1] https://blog.talosintelligence.com/the-serpents-tongue-luring-the-python-out-of-its-den/