【实战审计】CVE-2026-77939：Flextype CMS 表达式注入与沙箱逃逸及条件性 RCE 深度剖析

第一章：引言与漏洞概述 在当今的 Web 生态中，轻量级、无数据库的 Flat-File CMS（如 Grav、Flextype、Kirby 等）因其部署简单、性能优异而受到大量中小型站点的青睐。然而，摆脱了关系型数据库的束缚，并不意味着摆脱了传统 Web 漏洞的阴影。相反，由于高度依赖文件系统进行数据存储与解析，此类系统在输入处理、模板渲染及数据反序列化层面的安全设计往往面临更为严峻的考验。 近期披露的 CVE-2026-77939 正是一个典型的架构级安全缺陷。该漏洞存在于 Flextype CMS 的 API 查询模块中，由于其未能对用户输入进行有效的边界隔离，直接将外部数据交由 Symfony ExpressionLanguage 引擎进行求值（Evaluate）。更为致命的是，底层框架在初始化引擎时，打破了 Symfony 原生的沙箱限制，向求值作用域（Context）内暴露了包含文件读写、数据序列化在内的高危应用对象。 攻击者只需获取低权限的 API Token，即可通过构造恶意的表达式 Payload，实现任意文件读取；若结合日志投毒等二级攻击向量，甚至可将漏洞武器化为远程代码执行（RCE）。 漏洞编号：CVE-2026-77939 漏洞类型：服务端表达式注入（CWE-94 / CWE-1336）、沙箱绕过 影响组件：Flextype CMS <= v1.0.0-alpha.3 (commit aea4ead) 利用前置条件：需持有合法的 API Token 与 Access Token CVSS 评分：6.5 (Medium) / 7.1 (High) 第二章：靶场环境搭建与排坑记录 为深入探究底层逻辑，我们放弃使用可能存在版本漂移的官方镜像，选择基于源码从零构建调试环境。 2.1 环境初始化 拉取源码并精准切换至漏洞所在的 Commit： git clone https://github.com/flextype/flextype cd flextype git checkout aea4ead8c449ea5517ed53b6dcbd28b0a528ad9d 2.2 Docker 容器化构建 编写 Dockerfile，基于 PHP 8.1 + Apache 环境构建： FROM docker.m.daocloud.io/library/php:8.1-apache COPY --from=docker.m.daocloud.io/library/composer:latest /usr/bin/composer /usr/local/bin/composer RUN apt-get update && apt-get install -y libpng-dev libjpeg-dev libfreetype6-dev unzip libzip-dev \ && docker-php-ext-configure gd --with-freetype --with-jpeg \ && docker-php-ext-install gd zip \ && a2enmod rewrite COPY . /var/www/html/ RUN chown -R www-data:www-data /var/www/html 2.3 实战避坑指南 在复现过程中，我们遇到了两个极具代表性的问题： 依赖拉取超时：容器内直连 GitHub 导致 Composer 安装中断。解决方式：配置国内镜像源 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。 PHP 8.1 致命类型错误：Flextype 早期依赖的 phpfastcache 库在 PHP 8.1 下存在类型声明兼容问题（Fatal error: Declaration of ... must be compatible with...）。解决方案：修改 src/flextype/core/Cache/Drivers/Phparray/Driver.php 第 109 行，调整 driverDelete 方法签名，或直接在 YAML 中将缓存驱动改为 files。 环境就绪后，通过 CLI 生成鉴权凭据： docker exec -it flextype-env php bin/flextype tokens:create 第三章：代码审计与沙箱逃逸原理解析 本漏洞的本质是数据流的失控与框架上下文防御的失效。我们通过源码理清攻击链。 3.1 漏洞入口：未受控的求值节点 (Source to Sink) 漏洞的触发点位于 src/flextype/core/Endpoints/Query.php。 [图 1：Query.php 代码截图] $data = []; // Get flat representation of queries $queries = collection($requestParsedBody['query'])->dot()->toArray(); // Evaluate the queries foreach ($queries as $key => $value) { $evaluatedValue = parsers()->expressions()->eval($value); if ($evaluatedValue instanceof \Glowy\Arrays\Arrays) { $evaluatedValue = $evaluatedValue->toArray(); } // ... 省略部分代码 ... $data[$key] = $evaluatedValue; } 【数据流向分析】 数据源 (Source)：第 56 行，$requestParsedBody['query'] 直接接收客户端 POST 的 JSON 数据。 结构处理：通过 collection()->dot()->toArray() 将嵌套 JSON 扁平化。此处未进行任何白名单过滤或特殊字符转义，如 {"a": {"b": "payload"}} 会被转化为 ["a.b" => "payload"]。 执行点 (Sink)：第 60 行，未过滤的 $value 被直接传入 parsers()->expressions()->eval($value)。eval() 作为表达式引擎的求值入口，会将字符串作为 PHP 代码逻辑进行解析。 结果回显：第 70 行将结果写入 $data 数组，最终通过 API 响应返回。这是一个完美回显的漏洞。 3.2 引擎初始化：黑名单防御的失效 许多开发者过度迷信 Symfony ExpressionLanguage 自带的沙箱。在 src/flextype/core/Parsers/Expressions/Expressions.php 中： [图 2：Expressions.php 代码截图] protected function __construct() { // Re