- 准备环境: 确保你安装了异步网络库：
pip install aiohttp- 启动测试: 在终端进入 sglang_fuzzer_framework/ 根目录，执行以下命令：
python main.py --module regex- 你会看到控制台输出引擎启动信息。如果 SGLang 底层的 FSM 解析器存在漏洞，几分钟内你的 logs/crash_report.json 里就会捕获到能够让服务卡死或崩溃的特定正则表达式。
SGLang 的一大卖点是利用压缩有限状态机（Compressed FSM）来强制约束输出格式。这个机制需要在底层实时解析正则表达式或 JSON Schema，并在词表空间（Vocabulary Space）中进行 Mask 操作。这是一个极其复杂的计算过程，非常容易触发 C++ 底层的段错误（Segfault）或内存泄漏。
攻击思路： 专门向 SGLang 发送包含边缘情况的正则表达式或 JSON Schema约束，测试其 FSM 编译器和生成器的鲁棒性。
Fuzzing 变异策略：
-
灾难性回溯 (ReDoS) 注入： 传入类似
^(a+)+$的复杂正则。 -
极端词表对齐： 强制要求输出极其罕见的 Unicode 字符或未登录词（Out-of-Vocabulary）。
-
超深层嵌套结构： 传入层级极深（例如嵌套 1000 层字典）的 JSON Schema。
实现方式： 极其简单。直接编写一个 Python 脚本，通过 HTTP API 调用 /v1/chat/completions，在请求体中不断随机变异 regex 字段或 json_schema 字段的值。
预期漏洞： 服务端 SRT (SGLang Runtime) 进程因 FSM 编译超时而阻塞，或者底层 C++ 解析器因栈溢出直接 Crash。
SGLang 的灵魂是 RadixAttention，它通过基数树（Radix Tree）在 GPU 显存中动态复用前缀 KV Cache。管理这棵树的节点分裂、合并、驱逐（Eviction）是非常棘手的并发问题。
攻击思路： 构造特定模式的并发请求，故意在 Token 的非自然边界制造分叉，或者频繁触发 Cache 驱逐逻辑，测试 Radix 树的指针管理是否存在竞态条件（Race Condition）或悬空指针（Dangling Pointer）。
Fuzzing 变异策略：
-
错位分叉 (Misaligned Forks)： 发送 100 个请求，它们的前 100 个 Token 完全一样，但在第 101 个 Token 时出现 100 种不同的分支。
-
高频短命请求 (Hit and Run)： 使用 SGLang 的 s.fork() 快速生成大量分支，但在模型刚开始生成第一个 Token 时，立刻发送断开连接信号（Client Abort）。
-
缓存颠簸 (Cache Thrashing)： 交替发送超长上下文（占满显存）和极短上下文，强迫 Radix 树频繁执行驱逐和重建。
实现方式： 使用 Python 的 asyncio 和 aiohttp，结合长短不一的字符串拼接，高并发地向服务端发送前缀高度重合、但尾部随机变异的 Prompt。
预期漏洞： GPU 显存泄漏（OOM），或者在处理高并发断连时调度器崩溃，输出错误串话（某个请求收到了另一个请求的上下文）。
由于 SGLang 原生支持视觉语言模型（如 LLaVA, Qwen-VL），它需要在后端将图像字节流解码，并映射到与文本 Token 相同的张量空间中。这个跨模态对齐的过程非常脆弱。
攻击思路： 不 Fuzz 文本，专门 Fuzz 图片输入。利用畸形的图像元数据或非标准的图像张量尺寸来破坏底层的内存分配。
Fuzzing 变异策略：
-
0x0 或极端高宽比： 传入尺寸为 1×10000 或 0×0 的图片，测试其卷积层或 Patch 划分逻辑是否会抛出除零错误。
-
被截断的字节流： 故意将 Base64 编码的图片截断一半，或者修改 JPEG 头部但破坏后续数据块。
-
超量图片拼接： 在一段 Prompt 中连续插入几百个 sgl.image() 标签，塞爆多模态编码器的 Context Window。
实现方式： 用 Python 脚本生成上述损坏或极端的图像文件，转成 Base64 后，插入到标准的 SGLang OpenAI 兼容 API 的 image_url 字段中发送。
预期漏洞： 绕过 Python 层的异常捕获，直接引发底层 CUDA Kernel 执行错误（如非法内存访问），导致整个推理节点掉线。