加载失败
官方 Phabricator 工单显示，一名 WMF 员工在测试时用其高权限 staff 账号将大量用户脚本载入 MediaWiki:Common.js（MediaWiki 的全局 JS 页面），其中包含一段来自 ruWiki 的旧恶意脚本，该脚本以 XSS（跨站脚本）方式持久化并通过 userscripts 自传播，导致页面大规模涂改与删除（涉及 Special:Nuke）并触发临时只读与禁用用户脚本的应急响应。讨论基于对 MediaWiki（Wikipedia 使用的开源引擎）、interface‑admin（可编辑全站 JS/CSS 的权限）、2FA 与备份/快照策略的既有认知展开，争论重心在责任归属、权限设计缺陷与应急恢复方案。社群同时对代码风格（如使用 jQuery、可疑的 Number("20") 写法）、basemetrika.ru 域名为 NXDOMAIN 的发现、以及潜在的 LLM 训练数据污染与采用去中心化镜像（如 Kiwix/ZIM 或 IPFS）等更广泛议题表达关切。
Phabricator 工单（T419143）披露：一名 WMF 员工在做测试时用其高权限 staff 账号将大量用户脚本加载到 MediaWiki:Common.js（全站全局 JS），意外包含一段来自 ruWiki 的两年前恶意脚本并触发传播。该脚本能写入全局 JavaScript 并向访问者的 userscripts 传播，快速产生大量告警，WMF 因而将站点设为只读以阻断进一步扩散。评论分歧明显：部分人把责任归咎于执行测试的 Staff Security Engineer，称其是“明显失误／career‑limiting event”；另一部分人认为这是组织流程与权限配置的失败（把高风险操作放在易犯错的条件下），执行者只是“触发器”。讨论中还提到工单里点名了相关账号（例如 sbassett），同时有评论为在高流量服务上做生产测试并快速回滚这一做法辩护，但强调应有更严的控制与审批。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
多条技术分析指出这是一个典型的 XSS 蠕虫：它尝试把自身写入 MediaWiki:Common.js（优先）和 User:Common.js（回退），用 jQuery 隐藏会暴露感染的 UI，并在随机条目中注入 5000px 的大图与试图加载 basemetrika.ru 的脚本作为二次载荷。若管理员被感染，蠕虫会调用 Special:Nuke 批量删除条目，并通过 Special:Random?action=delete 进一步删除约 20 篇；报告还说 Special:Nuke 在实现上会把搜索结果作为默认删除列表并重复执行三次。社群发现 basemetrika.ru 在当时为 NXDOMAIN（有人尝试抢注）且部分注入实际上无效，因此外部 C2/载荷未必被成功拉起；代码风格（仍用 jQuery、像 Number("20") 之类的奇怪写法）被认为更偏向旧式人工或 AI 辅助而非完全由 LLM 生成。关于更复杂目标（比如通过浏览器 autofill 窃取凭证）也有讨论，但专家指出跨浏览器链条脆弱且低产出，盗取 session 或植入持久 XSS 更为实用。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
评论大量聚焦 MediaWiki 允许把界面 JS/CSS 存为页面（如 MediaWiki:Common.js），而编辑全站文件需要 interface‑admin 或更高权限：这意味着单个账户的滥用或被攻破会影响所有访客。许多人指出 userscripts 生态长期未受沙箱与强审计限制，很多“power user”脚本由弃用账号维护且可能未启用 2FA，本次事件中涉事账号为 WMF staff，跨项目高权限放大了影响。建议包括对每次修改全站 JS 强制二次认证或审批流程、引入代码签名/供应链防护、并限制谁可直接修改全站脚本；也有人提醒像 SRI 这类浏览器端校验对服务器端注入的脚本并不适用。讨论中还就 interface‑admin 的人数与 global 权限范围出现多次澄清与争议。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
在恢复策略上，技术评论提出以快照/备份回退到已知良好点并重放合法编辑为首选，但强调时效性和粒度很关键：英文维基的编辑频率高，回退会丢失数小时甚至数天的合法改动。有人建议短周期快照（例如每 15 分钟）并在恢复后对删除操作做特殊处理——恢复快照后重放编辑时忽略恶意删除可以最大化保留合法改动；另有观点强调应尽早回滚，拖延会增加人工调和成本。实践中有报告称这次主要用 wiki 内置的 revert 工具手动回退，且影响范围更偏向 meta/协调站点而非主站点，但为完整取证仍需从 diffs 与历史记录追踪传播链路。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
讨论延伸到若维基被破坏对公共事实认知的影响以及如何增强韧性：一方面有声音强调大量镜像与离线存档（例如 Kiwix 的 ZIM 存档约 43 GiB）能快速恢复文本数据；另一方面有人主张采用中心只读镜像并把编辑权下放到自治社区，或用 IPFS 等去中心化存储来降低单点故障。还有人担心被污染的数据是否已进入 LLM 训练流水线，以及谁从维基暂时不可用中受益（有评论指向大型 AI 公司或写手平台）。多数讨论认为本次更像是误操作或旧脚本触发，而非精心策划的长线攻击，但提出了对制度与基础设施的长期反思。
不少评论把事件当作讨论客户端 JavaScript 风险的契机：有人从电池、性能与攻击面角度主张默认禁用 JS，指出 Wikipedia 的经典编辑器在无 JS 下仍可用，从而降低暴露面；也有人反驳称现代功能和用户体验大量依赖 JS，完全去 JS 不现实。评论区还区分本地浏览器用户脚本（如 Tampermonkey/GreaseMonkey）与服务器端存储并注入到所有访问者页面的脚本风险，后者在被高权限修改时危害更大。总体上这是在权衡可用性与安全性的常见争论。
评论中还有一股元讨论在批评本论坛上的评论质量：多位用户识别出疑似 LLM 生成的“高能量但事实薄弱”的回复，并以用语风格（如过度的破折号、空泛表述）作为线索呼吁举报和加强审理。有人担心自动生成内容正在淹没真实讨论、使得判断信息源更困难；也有回击者主张以官方工单与代码为准，不应把一切可疑表述都归咎于 LLM。该话题反映出社群对信息来源与评论真实度的敏感性提升。
MediaWiki: MediaWiki（一个开源的 Wiki 引擎，Wikipedia 及其项目用于存储页面、模板、用户脚本和界面文件的底层软件）。
MediaWiki:Common.js: MediaWiki:Common.js（MediaWiki 的全站/global JavaScript 页面，服务器端存储并可注入到所有访客页面，编辑通常需 interface‑admin 或更高权限）。
XSS: XSS（cross‑site scripting，跨站脚本攻击）：通过注入可在其他用户浏览器上下文执行的 JavaScript，实现篡改页面、窃取会话或自我复制传播等恶意行为）。
interface-admin: interface‑admin（MediaWiki 的一种特殊用户权限，允许编辑站点级别的 JS/CSS 页面，如 MediaWiki:Common.js，因而能影响站点所有访客的前端行为）。
userscripts: userscripts（用户脚本）：维基内部或浏览器插件允许运行的自定义 JavaScript，维基有服务器端的用户脚本体系，可被存为页面并被其他用户加载执行，通常不在沙箱内运行）。
Phabricator: Phabricator（Wikimedia 使用的任务/问题跟踪与协作平台，事件细节和运维工单在上面公开记录）。
Special:Nuke: Special:Nuke（MediaWiki 的一个特殊工具/界面，用于由有权用户批量删除或“碾压”一组页面，常见于需要大规模清理时）。
Subresource Integrity (SRI): Subresource Integrity（SRI，浏览器端功能，用于通过哈希验证外部脚本/资源在传输过程中未被篡改；对服务器端直接提供的恶意脚本作用有限）。