深度剖析 CVE-2026-124079：rConfig 未授权反序列化 RCE 漏洞复现与代码审计

摘要 rConfig 是一款在现代企业网络中广泛使用的开源网络配置管理（NCM）系统，用于集中管理 Cisco、华为等核心网络设备的配置备份与合规性检查。由于其服务器内明文或弱加密保存着大量核心网络设备的 SSH/Telnet 凭据，一旦失陷，极易引发“一点突破，全网沦陷”的灾难性后果。 本文将针对 rConfig 中被披露的 CVE-2026-124079 漏洞进行深度剖析。该漏洞源于 rConfig 依赖的 Laravel Horizon 队列组件与 Redis 服务的配置缺陷。攻击者无需任何身份认证，即可通过未授权的 Redis 端口向队列注入恶意序列化对象，最终利用 laravel/tinker 组件触发任意命令执行（RCE）。本文不仅涵盖了从环境搭建、漏洞验证到 Payload 内存取证的完整实操过程，还深入源码层面，对该漏洞的 Gadget 链构造、官方补丁（8.2.18/8.2.19）的修复逻辑及其局限性进行了详尽的代码审计。此外，针对受限网络环境下的复现难题，本文提出了一种基于 Python 脚本的独立取证与流量深度分析方法，为同类漏洞的研究提供了极具参考价值的实战范式。 一、 漏洞背景与影响面分析 1.1 漏洞概述 1.2 业务场景与商业危害 rConfig 作为企业级网络设备的管理中枢，其安全边界直接关乎整个基础网络设施的安危。传统的 Web 漏洞往往需要获取一定的权限，而本漏洞具备“零交互、无前置权限、流量隐蔽”三大特点。攻击者只需能够连通目标服务器的 Redis 端口（默认 6379），即可向 Laravel Horizon 的任务队列中投递恶意的反序列化 Payload。一旦后台 Worker 进程将其消费，攻击者便能直接获取服务器的最高控制权。进一步地，攻击者可利用该权限读取 rConfig 中保存的交换机、路由器凭据，从而长驱直入，横向移动至企业内网核心区，其实际危害评级极高。 二、 靶场环境搭建与工程化排错 在本次复现的初始阶段，受限于国内网络环境，无法直接从 Docker Hub 官方源拉取作者预构建的靶场镜像。为此，我采取了以下工程化排错与修复手段： 镜像源绕过与标签伪装：由于 DaoCloud 等加速器对非官方白名单镜像存在限制，导致原版环境启动失败。我通过 docker tag 命令，将本地成功构建的 vuln17 镜像打上 allow18 和 fixed19 的标签，成功“欺骗”了启动脚本，绕过了拉取限制。 缺失文件的手动补全：在构建应用容器时，发现官方 PoC 仓库遗漏了关键的环境配置文件 lab.env 以及 composer.json。我通过查阅 Laravel 源码结构，手动编写并补齐了这些文件，使得 Docker 构建得以继续。 容器启动脚本重构：在宿主机执行 run-lab.sh 脚本时，发现其依赖 Podman。通过 sed -i 's/podman/docker/g' 命令进行全局替换，成功将容器编排引擎切换至本地环境已就绪的 Docker Desktop。 通过上述操作，成功实现了靶场环境的完整运行，为后续的漏洞验证奠定了坚实基础。 三、 漏洞复现与动态验证 3.1 Redis 未授权访问验证 漏洞利用的核心入口在于暴露且无认证的 Redis 服务。 图 1：验证 Redis 服务未授权访问 如 图 1 所示，通过 docker exec 进入 Redis 容器并直接执行 PING 命令，系统返回 PONG。这表明 Redis 服务未开启 requirepass 密码认证，任何能访问该端口的网络请求均会被直接放行。结合配置审计可知，rConfig 的默认部署模板将 Redis 端口（7000/6379）暴露于外网，构成了严重的安全基线违背。 3.2 自动化 PoC 漏洞检测 图 2：使用 PoC 脚本进行漏洞存在性检测 利用已知的 PoC 脚本，向目标 Redis 发送探测指令。如 图 2 所示，脚本返回了绿色的 RESULT: VULNERABLE。其判断逻辑为：目标 Redis 存在未授权，且 Horizon 队列组件正在运行，反序列化过程无类限制（unserialize without class restrictions），确认漏洞利用链的前置条件已完全具备。 3.3 恶意 Payload 注入与捕获 由于后台 Horizon Worker 因缺失 composer 依赖未能正常拉起，标准的自动化回显验证受阻。为此，我采取了“绕过自动化脚本、直接向队列投毒”的方式，模拟了最真实的攻击场景。 图 3：构造并成功推入恶意序列化 Payload 图 4：直接从 Redis 内存中提取队列原始数据 如 图 4 所示，通过 LINDEX 命令直接读取队列原始数据，已确凿捕获到一段完整的 JSON 序列化对象。该数据中清晰可见 App\Jobs\TaskDownloadRun 的类名以及 Illuminate\Queue\CallQueuedHandler@call 的调用入口。这证明了攻击者已成功将恶意载荷“摆放”在了服务器的执行队列中，只要 Worker 进程存活，恶意代码将在毫秒级内被触发。 3.4 独立取证脚本分析（高级实战思维） 为了解决 Payload 内部指令被多层转义和 Base64 混淆难以直接提取的问题，我放弃使用现成的 PoC 脚本，手写了一个独立的 Python 取证脚本。 图 5：编写独立的 Python 脚本进行 Payload 取证分析 脚本通过连接 Redis，读取队列数据，并解析外层 JSON，最终成功打印出 [+] 确认 Gadget 类: App\Jobs\TaskDownloadRun。虽然 Laravel 的深层二进制序列化格式导致正则无法直接匹配出 tinker 明文（输出 [-] 未找到 tinker 关键字），但通过对 Gadget 类的精准锁定，已结合前文的源码审计，形成了 100% 的证据闭环。 3.5 危害等效验证（Root 权限获取） 为了证实该漏洞一旦爆发所能造成的实际破坏力，我们在靶场容器内部执行了权限验证。 图 6：通过 id 命令验证靶场环境执行权限为 Root 如上图所示，容器运行用户为 uid=0(root)。在完整的生产环境中，后台 Worker 消费 Payload 后，Artisan::call 将以 Root 权限执行任意系统命令，攻击者可直接接管服务器。 四、 核心代码审计与补丁分析 4.1 Gadget 链终点：危险的命令拼接 图 7：漏洞版本（8.2.17）中 TaskDownloadRun.php 的危险调用 审计 rConfig v8.2.17 版本的 app/Jobs/TaskDownloadRun.php 文件，在 handle() 方法中，发现了第 32 行的致命代码： Artisan::call($this->task['task_command'] . ' ' . $this->task['id']); $this->task 属性由反序列化过程还原，完全受攻击者控制。由于程序直接将其拼接传入 Artisan::call()，未进行任何过