问题——核心仓库遭“投毒”，隐蔽性强、波及面广。 据项目维护方披露，3月初，Neutralinojs组织名下4个核心代码仓库出现异常变更：攻击者通过强制推送将恶意JavaScript植入关键位置，并采用重度混淆与“空格、换行隐匿”等手法降低可读性，常规浏览界面难以第一时间察觉。恶意代码与外部指挥控制（C2）基础设施相连，涉及的服务部署在云平台上，安全组织OpenSourceMalware（OSM）发现后协助处置并推动下线。初步判断，3月2日至5日期间获取受影响版本代码的用户，存在被后门影响的风险。 原因——“人”的环节与“插件”的漏洞叠加，权限链被悄然打开。 复盘显示，此次事件并非维护者个人令牌泄露所致，而是攻击者利用一名早期贡献者账号作为跳板进入组织仓库。该账号疑因安装含恶意载荷的扩展插件而失守，随后其写入权限被滥用，对组织内多仓库同时实施篡改。在该贡献者个人分叉仓库中亦发现相似恶意内容，表明攻击并非偶发，而是围绕插件生态与开发者常用工具链进行的定向渗透。值得警惕的是，部分插件具备读取内容、执行命令、调用外部服务等能力，一旦存在“Markdown命令执行”等缺陷或被植入木马，便可能绕过传统边界，将风险延伸至代码托管、持续集成、发布流程等关键环节。 影响——从单点入侵扩散为供应链风险，伤害信任与生态。 Neutralinojs定位为轻量跨平台应用框架，长期由维护者与社区协作迭代，曾多次入选国际开源人才培养项目，拥有一定规模的开发者与下游应用。此类项目一旦在源代码环节被篡改，下游开发者在不知情情况下拉取、构建、集成，风险将沿依赖链条传导：轻则导致构建环境被污染、敏感信息被窃取，重则形成对终端用户的广泛投放。此外，攻击者对恶意脚本进行高度混淆并选择短窗口作案，说明其目标不仅在于植入，更在于“潜伏”与“扩大接触面”。供应链攻击近年来高发，开源仓库、包管理生态、自动化构建与发布渠道已成为黑灰产重点觊觎对象，事件对开源社区信任体系构成直接冲击。 对策——“黄金处置期”压缩传播半径，多层加固提升韧性。 项目维护方在接到安全组织提示后，采取了多项紧急与长期措施：一是快速合并清理补丁，删除恶意载荷并对比历史提交恢复主分支可信状态；二是暂停或禁用nightly等自动构建工作流，全面排查Actions、CI/CD配置，防止自动化链路继续分发风险；三是吊销可疑令牌与访问凭证，收紧组织成员权限，阻断异常账号深入操作；四是启用分支保护规则，禁止默认分支直接推送，要求评审、状态检查与线性历史等约束落地；五是面向社区发布高优先级通告，提示用户核验拉取版本并开展本地环境检查，推动分叉仓库同步审计。 从经验看，处置的关键在于“快”和“全”：既要尽快切断传播渠道，也要覆盖代码、权限、构建、依赖、成员管理等全链条，避免攻击者在其他入口“二次进入”。 前景——开源安全需要制度化治理，向“可验证”与“可追溯”升级。 业内人士指出，随着开发流程高度自动化、插件与工具深度嵌入日常工作，单靠个人经验难以应对体系化攻击。下一步应推动开源项目在组织层面建立常态化安全机制：其一，落实最小权限与成员生命周期管理，人员变动及时回收写入权限；其二，敏感令牌不落磁盘，使用系统级安全存储，并定期轮换；其三，对依赖与插件建立准入与复核机制，安装前检索漏洞信息，避免“随手安装、默认授权”；其四，引入发布签名、可复现构建、软件物料清单（SBOM）等手段，提高下游对版本来源与构建过程的验证能力；其五，强化多因素认证覆盖至代码托管、包管理与构建平台，减少账号被盗后的横向移动空间。安全组织同时提示，相关恶意脚本已出现多种变体，仍可能在其他项目中传播，开发者需提高对异常提交、构建脚本变更与外联请求的敏感度。
此次事件既暴露了开源生态的安全隐患，也展现了开发者快速响应的协作精神。在数字化时代，安全不仅是技术问题，更是对生态治理能力的考验。只有将安全意识融入开发流程的每个环节，才能守护好开源创新的基石。