文章总结： 本文详述了2026年维基百科因安全工程师误激活沉睡两年的JS蠕虫而瘫痪的事件。该蠕虫通过全局脚本注入在23分钟内篡改数千页面。文章深入分析了特权账号违规操作、脚本审查缺失等根因，并提出实施CSP、建立沙箱测试及强化权限分离等改进建议，警示开放协作平台的安全隐患。 综合评分： 86 文章分类： 应急响应,恶意软件,安全大事件,漏洞分析,安全建设

• 批量删除：若当前会话具有管理员权限，脚本会调用 Special:Nuke 及 Special:Random 配合 action=delete 参数，随机删除数篇文章。每次删除均留下同一行俄语编辑摘要：「Закрываем проект」（「关闭项目」）。
• UI隐藏：利用jQuery隐藏可能暴露感染迹象的界面元素，增加检测难度。

basemetrika.ru：一个未竟的外控节点

值得注意的是，事发当时，脚本所引用的 basemetrika.ru 域名实际上并不存在（未注册或已过期）。这引发了安全研究者的诸多猜测：该域名究竟是攻击者预留的后门节点，还是脚本在转移过程中留下的残迹？事件发生后，社区成员迅速抢注了该域名，以防止其被恶意利用，但由于维基媒体的应急响应已率先完成，这一措施未来得及发挥实际防御作用。

四、灾情评估：23分钟造成的广泛破坏

根据维基媒体基金会官方事件日志及安全研究机构BleepingComputer的独立分析，此次事件的直接损失如下：

| 指标 | 数据 | | — | — | | 恶意代码活跃时长 | 约23分钟 | | 被篡改/删除的页面数 | 约3,996页 | | 被替换的用户common.js文件 | 约85个 | | 平台进入只读模式时长 | 约2小时 | | 全用户JavaScript被禁用时长 | 约一整天 | | 主要受影响范围 | Meta-Wiki |

维基媒体基金会在事后声明中确认，此次事件的恶意代码仅在Meta-Wiki范围内造成内容变动，没有证据显示维基百科正文站遭到攻击，也没有用户个人信息泄露。所有被删除或篡改的内容均已恢复。

五、应急响应：一场与时间赛跑的止血行动

事件的发现速度出奇地快。大规模的异常编辑在页面历史中几乎是实时可见的，村泵（Village Pump）技术讨论区的编辑们几乎立刻注意到了大量可疑的自动化编辑行为。

维基媒体的事件响应流程随即启动：

1. 立即锁定：将所有维基媒体项目切换为只读模式，阻断蠕虫的继续传播。

2. 溯源定位：通过编辑历史追溯到感染源——SBassett账号加载的那个外部脚本。
3. 代码清除：从全局 MediaWiki:Common.js 及各受感染用户的个人脚本中移除恶意注入。
4. 历史压制：将被篡改页面的恶意版本从公开编辑历史中隐藏，防止后续用户意外触发。
5. 内容回滚：逐一恢复被删除和篡改的页面至事发前状态。
6. 脚本重启：在确认安全后，于当日稍晚重新开放用户JavaScript功能。

整个响应流程的执行速度，充分体现了维基媒体社区长期积累的协同应急能力。

六、根因分析：多层失效的系统性问题

这次事件并非简单的技术漏洞，其背后是若干安全原则的叠加失效。

失效一：特权账号执行不受信任的代码

这是本次事件最核心的致命错误。一位安全工程师使用拥有全局管理员权限的账号，直接在生产环境中加载来源不明的用户脚本——这与「最小权限原则」（Principle of Least Privilege）背道而驰。安全审查本应在隔离的沙箱环境中进行，而非直接在实时系统中操作。

失效二：缺乏有效的脚本审查机制

一段具有明显攻击性的恶意代码，在俄语维基百科用户页上公开存放了近两年，既未被自动安全扫描发现，也未经人工审查标记。MediaWiki平台的用户脚本生态庞大且几乎无审查，为潜在的恶意代码提供了天然的隐匿空间。

失效三：职责分离的缺失

从技术架构上看，系统本不应允许一位工程师在同一会话中既执行「加载外部脚本」的操作，又能触达「修改全局JavaScript」的权限。这种高度集中的权限模型，使得单点失误的代价极为高昂。

失效四：生产环境即测试环境

维基媒体基金会显然缺乏一套能够完整模拟生产行为的隔离测试环境。这迫使工程师不得不在真实系统中开展带有风险的测试工作——这不仅是维基媒体的问题，也是很多资源有限的非营利性技术组织的普遍困境。

七、深层背景：MediaWiki用户脚本架构的先天隐患

这次事件之所以能够发生，与MediaWiki平台的脚本架构有着根本性的关联。

MediaWiki允许用户创建自定义的JavaScript和CSS文件，这些文件会在用户登录状态下的每个页面加载时自动执行。这一设计是维基百科社区文化的重要组成部分——它使得经验丰富的编辑者能够在不等待官方开发的前提下，自主扩展和优化平台功能。

然而，这种架构内嵌了几个无法回避的安全风险：

代码无需审查即可上线：任何注册用户都可以在自己的用户页上传并保存任意JavaScript代码。维基媒体平台不对用户脚本进行强制性安全审计。

管理员脚本拥有更高权限：当拥有管理员权限的用户执行脚本时，该脚本继承管理员的操作能力，可以进行普通编辑者无法完成的操作。

跨用户感染路径天然存在：一旦恶意脚本进入全局文件，其传播路径便完全打通，每一位登录用户都成为潜在的「宿主」与「传播者」。

供应链风险类比：这与软件生态系统中的供应链攻击（如npm或PyPI中的恶意包）如出一辙。维基媒体的用户脚本生态，本质上就是一个缺乏包安全审核的脚本包管理系统。

八、事件的历史坐标：与Samy蠕虫的比较

安全研究者将此次事件与2005年的「Samy蠕虫」相提并论——后者是互联网历史上传播最快的蠕虫病毒之一，在不到20小时内感染了MySpace超过100万个账户。

两者的技术原理惊人地相似：都完全在浏览器层面运行，依赖会话Cookie和DOM操作，无需感染用户的操作系统；都通过被感染用户的操作进一步传播；都利用了平台对用户行为监控的疏漏。

区别在于，此次维基百科事件的传播窗口仅有23分钟便被中断，而蠕虫本身的破坏目标也更侧重于内容破坏而非账号劫持或数据窃取。从技术成熟度上看，这枚蠕虫脚本在设计层面颇为老道，但在部署层面（如外控域名的失效）存在明显的不完整性。

九、争议与猜测：攻击的幕后逻辑

攻击者的动机是什么？

这是目前仍无定论的核心问题。综合现有信息，可以梳理出几种可能的解读：

纯粹的破坏与宣示：从攻击载荷（篡改页面、留下「关闭项目」的删除摘要）来看，攻击者的主要动机可能是制造混乱和施加心理压力，而非窃取数据或经济利益。

沿用自既有工具：该脚本最初用于2023年对Wikireality和Cyclopedia的攻击。将同一工具移植到俄语维基百科，可能是一种「存而不用」的策略——在俄语维基百科的用户页上留存武器库，等待合适的机会或合适的账号来激活它。

意外触发的被动攻击：维基媒体基金会的官方声明明确表示，「没有理由认为维基百科正在遭受蓄意攻击」。从时间线来看，脚本的激活完全是工程师无意操作的结果，并不符合典型主动攻击的行为特征。

这更像是一枚遗忘在地下室的地雷，在多年之后被不知情的人踩响，而非一次精密计划的定点打击。

谁是 Ololoshka562？

这一用户账号目前尚无公开身份信息。据Wikireality平台的资料显示，2023年针对其与Cyclopedia的攻击背后存在有组织的破坏活动。Ololoshka562是否与这一群体有关联，目前尚无确切证据。

十、后续应对与改进方向

维基媒体基金会在事后声明中表示，将开发额外的安全措施以防止类似事件再次发生。结合安全社区的分析建议，较为具体的改进方向包括：

技术层面：

• 实施内容安全策略（Content Security Policy，CSP）头部，限制外部脚本的加载域名白名单
• 对用户脚本进行静态安全扫描，标记可疑的敏感操作模式（如自我注入全局文件、调用批量删除命令等）
• 强制要求全局界面管理员账号执行多因素认证（MFA）
• 建立专用的隔离测试环境，禁止在生产账号上直接执行来源不明的脚本

流程层面：

• 明确「禁止在特权账号上加载未经审查的第三方脚本」的操作规范
• 引入职责分离机制，使「脚本执行」与「全局文件修改」的权限不能同时存在于同一会话中
• 完善自动化告警系统，对MediaWiki:Common.js等核心文件的异常修改实施实时监控

社区层面：

• 探索建立用户脚本「安全标签」或「社区审核」机制，对高度传播的脚本进行额外审查
• 鼓励安全意识较强的编辑者对用户脚本库进行定期巡查

开放性与安全性的永恒张力

这次「沉睡者事件」留下的教训，远不止于一次操作失误的复盘。

它揭示的是一个更深层的悖论：开放协作平台的生命力恰恰来源于它的开放性，而这种开放性本身就是攻击面的一部分。维基百科之所以成为互联网上最宝贵的知识公地，依赖的正是社区成员自由创作、自由扩展的文化基因。用户脚本生态是这种文化的直接产物，它在赋予社区极大灵活性的同时，也埋下了难以彻底消除的安全隐患。

真正令人警醒的，或许不是一个工程师的操作失误，而是一段恶意代码能够在全球最大的开放知识平台上静默潜伏近两年，毫无察觉。在那段时间里，它只是等待——等待一个恰当的账号，一次疏忽的操作，然后在23分钟内震动全球基础设施。

好在，这一次代价可控，损失可复。但下一次，未必还有这样的运气。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：独眼情报 🅼🅰🆈 🅼🅰🆈《一段休眠两年的恶意脚本如何瘫痪维基百科全球基础设施》