全局安装Composer包存在权限提升、代码执行和依赖污染风险，恶意包可通过软链接执行任意代码，尤其以高权限账户安装时危害更大；全局插件可持久化驻留并跨项目自动运行，易被用于供应链攻击；缓存目录若权限配置不当（如777），可能被篡改导致恶意代码执行；因此应避免全局安装不可信包，并确保~/.composer目录权限为700且归属正确用户。
Composer的全局安装功能虽然方便，但也引入了不容忽视的安全风险，主要集中在权限提升、代码执行和依赖污染三个方面。
全局二进制文件可能被滥用
使用composer global require安装的包，其提供的可执行脚本会被软链接到系统的~/.composer/vendor/bin目录。如果这个目录被加入用户的PATH环境变量，任何用户都能直接运行这些命令。
关键风险在于，如果攻击者诱导你全局安装了一个恶意包，该包的二进制文件就能在你的用户上下文中任意执行代码。更危险的是，如果以root或高权限用户进行全局安装，恶意脚本将获得系统级控制权，可以读取敏感文件、修改系统配置或植入后门。
插件和脚本拥有过高权限
Composer的设计允许包注册插件和脚本，这些代码会在特定事件（如install、update）触发时自动执行。当你全局安装一个包含插件的包时，这个插件会“永久”驻留在你的Composer环境中。
这意味着，未来无论你在哪个项目中运行composer install，这个全局插件都会被激活并执行。如果该插件有恶意逻辑，它就能监控你的所有项目操作、窃取凭证，甚至修改其他项目的依赖关系。这种持久化的、跨项目的执行能力，使得全局插件成为供应链攻击的理想载体。
缓存和数据目录的权限隐患
全局安装会频繁读写~/.composer目录下的缓存、配置和已安装包。如果这个目录的权限设置不当（例如被设为777），其他本地用户可能篡改缓存内容或注入恶意代码。
一个典型的场景是：攻击者修改了某个已缓存包的元数据或源码，当下次你运行composer global update时，Composer可能会“正常”地从看似可信的缓存中拉取并执行被篡改的代码，导致权限被劫持。因此，确保~/.composer目录权限为700，并由正确的用户拥有至关重要。
基本上就这些，核心是别轻易全局安装来源不明的包，尤其避免用高权限账户操作。
