2026-08-11 05:09:35 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： JeecgBoot3.9.2及更早版本Airag匿名接口存在SSRF漏洞（CVE-2026-19000，CVSS7.3），因@IgnoreAuth注解免认证且SSRF过滤器仅拦截回环与链路本地地址，遗漏私网段，攻击者可构造请求使服务器读取内网配置及云元数据凭据并通过AI回复泄露。建议立即在Nginx层封禁airag路径或移除该模块，长期应完善地址校验并收紧安全组端口。 综合评分： 92 文章分类： 漏洞分析,WEB安全,漏洞预警,应用安全,供应链安全

cover_image

4.7万星JeecgBoot匿名接口SSRF：一个请求打穿你的企业内网

原创

龙虾池子龙虾池子

龙虾池子

2026年8月9日 15:59 山东

在小说阅读器读本章

去阅读

4.7万星JeecgBoot匿名接口SSRF：一个请求打穿你的企业内网

2026年8月6日，NVD披露了国产企业级低代码平台 JeecgBoot 的一个服务端请求伪造漏洞，编号 CVE-2026-19000，CVSS评分 7.3分（高危）。该漏洞存在于 JeecgBoot 的 Airag（AI对话）匿名聊天接口中，攻击者无需任何登录凭证，只需向 /airag/chat/send 接口发送一个精心构造的请求，就能让服务器主动去访问内网资源，并将敏感文档内容通过AI模型的回复原样泄露出来。

JeecgBoot 是 GitHub 上 4.7万星的国产低代码平台，主打”一句话生成整个系统”，被大量国内企业用于快速搭建ERP、CRM、OA等管理系统。一旦攻击者利用此漏洞，可以直接读取企业内网的配置文件、数据库连接信息、甚至是云环境的元数据接口凭据。更严重的是，CISA 已经将该漏洞标记为可自动化利用（Automatable: Yes），这意味着攻击脚本可以批量扫描互联网上暴露的 JeecgBoot 实例。

如果你正在使用 JeecgBoot 3.9.2 或更早版本，并且开启了 Airag（AI对话）功能，请立即按照本文的修复指南进行排查。

快速自查（2分钟速查）

以下三步帮助你快速判断系统是否存在风险。

第一步：确认 JeecgBoot 版本

查看你部署的 JeecgBoot 版本号。如果你使用的是 3.9.2 及更早版本，则可能受此漏洞影响。

# 方法1：查看后端启动日志中的版本号
grep -i "jeecg" /path/to/jeecg-boot/logs/*.log | head -5

# 方法2：查看 pom.xml 中的版本
grep "<version>" /path/to/JeecgBoot/pom.xml | head -3

# 方法3：API 接口探测（访问系统首页）
curl -s http://your-server:8080/jeecg-boot/sys/getCheckCode | head -20

第二步：检查 Airag 模块是否启用

漏洞仅影响启用了 Airag（AI对话）模块的实例。检查你的后端模块配置：

# 检查是否引入了 airag 模块依赖
grep -r "airag" /path/to/JeecgBoot/jeecg-module-system/pom.xml

# 检查 AiragChatController 是否存在于编译产物中
find /path/to/jeecg-boot -name "AiragChatController.class" 2>/dev/null

# 检查 airag 接口是否可达（无认证访问）
curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://your-server:8080/jeecg-boot/airag/chat/send \
  -H "Content-Type: application/json" \
  -d '{}'

如果返回的不是 401/403（未授权），说明 匿名接口确实对外开放，风险等级极高。

第三步：检查接口是否暴露到公网

# 检查 Nginx/Apache 反向代理是否直接转发 /airag/ 路径
grep -r "airag" /etc/nginx/conf.d/ /etc/nginx/sites-enabled/ 2>/dev/null

# 用 nmap 从外网扫描你的服务器
nmap -p 8080,80,443 your-server-ip

# 检查云服务器安全组是否放行 8080 端口到 0.0.0.0/0
# (阿里云/腾讯云控制台 → 安全组规则)

如果 /airag/ 路径可以从公网直接访问，且无需登录，你的系统面临被利用的真实风险。

影响范围（风险确认表）

受影响条件

不受影响情况

| 情况 | 说明 | | — | — | | 未集成 Airag 模块 | pom.xml 中未引入 jeecg-boot-module-airag 依赖，不包含漏洞接口 | | 严格内网隔离部署 | JeecgBoot 后端仅在内网 VLAN 中运行，外部无法触达 8080 端口 | | Nginx 层已封禁 /airag/ 路径 | 反向代理层配置了 location /airag/ { deny all; } 规则 | | 版本早于 v3.8.1 | Airag 模块在 v3.8.1（2025年7月）才引入，更早版本不含此模块 |

常见误区提醒

误区一：@IgnoreAuth 是设计如此，不是漏洞。很多开发者看到 Airag 聊天接口标注了 @IgnoreAuth，会以为这是”匿名聊天”的正常设计——但问题在于，这个接口不仅接收聊天消息，还允许传入远程文件 URL 让服务器去下载。将”远程文件抓取”功能放在一个无需认证的接口上，等于给任意网络访问者提供了一个免费的内网代理跳板。

误区二：有 SSRF 校验就安全了。JeecgBoot 确实实现了 SsrfFileTypeFilter，但它只拦截了 loopback（127.0.0.0/8）和 link-local（169.254.0.0/16）地址。私网段 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 全部被放行。这意味着攻击者仍然可以访问企业内网中绝大多数的服务器——而内网服务器通常恰恰处于这些私网段。

误区三：文件类型限制能防止信息泄露。后端会校验文件扩展名，只允许 txt、pdf、docx、doc、pptx、xlsx、md 等文档类型。但攻击者完全可以在内网搭建一个返回伪装成 txt 的 HTTP 服务，或者在文件名上做文章——更关键的是，云环境的元数据接口（如阿里云 100.100.100.200）返回的也是文本格式内容，包含临时 AccessKey 等高价值凭据。

误区四：升级到最新版就安全了。需要特别注意的是，截至发稿时 JeecgBoot 最新发布版本仍然是 3.9.2，该漏洞尚未在正式版本中修复。GitHub Issue #9672 虽然已标记为 Closed，但官方仅表示”修复计划在即将发布的版本中”。在补丁正式发布前，所有 3.9.2 用户都需要采取临时缓解措施。

技术分析

漏洞原理：为什么可利用？

这个漏洞的核心在于一个设计缺陷：将高危的远程文件抓取功能暴露在了无需认证的接口上。让我们逐步拆解整个攻击链。

JeecgBoot 的 Airag 模块提供了一个 AI 对话功能，用户可以在聊天中附带文件，让 AI 帮助分析文档内容。入口控制器代码如下：

// org.jeecg.modules.airag.app.controller.AiragChatController
@IgnoreAuth   // ← 关键：跳过认证检查
@PostMapping(value = "/send")
public SseEmitter send(@RequestBody ChatSendParams chatSendParams) {
    return chatService.send(chatSendParams);
}

@IgnoreAuth 注解让这个接口完全绕过了 JeecgBoot 的 Sa-Token 认证框架。任何能访问到该接口的人，不需要 X-Access-Token，不需要任何登录态，就能调用这个聊天接口。

接下来看附件处理逻辑。当用户在请求中传入 files 参数时，服务层会将这些文件内容拼接到 AI 模型的上下文中：

// org.jeecg.modules.airag.app.service.impl.AiragChatServiceImpl
if(!CollectionUtils.isEmpty(sendParams.getFiles())){
    content = buildContentWithFiles(content, sendParams.getFiles());
}

在 buildContentWithFiles 方法中，当检测到文件引用是一个 HTTP/HTTPS 网址时，服务端会主动去下载这个文件：

if (LLMConsts.WEB_PATTERN.matcher(fileRef).matches()) {
    SsrfFileTypeFilter.checkSsrfHttpUrl(fileRef);  // SSRF校验（有缺陷）
    FileDownloadUtils.download2DiskFromNet(fileRef, tempFilePath);  // 下载文件
    return new File(tempFilePath);
}

这里的 SSRF 校验就是整个漏洞的关键所在。来看 SsrfFileTypeFilter 的实现：

// org.jeecg.common.util.filter.SsrfFileTypeFilter
for (InetAddress addr : InetAddress.getAllByName(host)) {
    if (addr.isLoopbackAddress() || addr.isLinkLocalAddress()) {
        throw new JeecgBootException(
            "非法URL：禁止访问本机或链路本地地址 " + addr.getHostAddress());
    }
}

这段代码只检查了两类地址：isLoopbackAddress()（127.0.0.0/8 回环地址）和 isLinkLocalAddress()（169.254.0.0/16 链路本地地址，也覆盖了大部分云元数据接口）。但 Java 的 InetAddress 类还提供了另外两个关键方法：isSiteLocalAddress()（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 私网地址）和 isAnyLocalAddress()（0.0.0.0/8）——这两个检查完全缺失。

攻击者利用这个缺陷，可以在 files 参数中传入内网地址（如 http://10.0.0.5:3306/conf/database.yml 或 http://192.168.1.100:8500/config），服务器会下载该文件，用 Apache Tika 解析文本内容，然后将解析结果拼接进 AI 模型的上下文——最终，敏感文档的内容会通过 AI 的回复返回给攻击者。

CVSS向量逐项解读

完整向量字符串：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L。虽然各维度影响都是 Low，但 无需认证 + 网络可达 + 攻击复杂度低这三个因素组合在一起，使得实际危害远超评分所反映的程度——攻击者可以轻松实现批量扫描和自动化利用。CISA 的 SSVC 评估也确认了这一点：exploitation 为”poc”（已有公开 PoC），automatable 为”yes”（可自动化）。

与同类漏洞对比

| 漏洞 | 产品 | CVSS | 根因相似度 | | — | — | — | — | | CVE-2026-19000 | JeecgBoot Airag | 7.3 | — | | CVE-2026-67620 | Flowise SSRF | 7.7 | 高：同样遗漏Oracle Cloud元数据端点 | | CVE-2026-61808 | LightRAG 默认无认证 | 9.8 | 中：同为AI/RAG工具，默认安全配置缺失 | | CVE-2026-10595 | lollms 路径穿越 | 7.5 | 中：同为AI工具，输入校验不完整 |

可以看到，近期 AI/RAG 相关工具频繁出现 SSRF 和认证缺失类漏洞。这是因为大量 AI 应用在集成”联网搜索””文档解析””知识库构建”等功能时，引入了服务端发起外部请求的能力，但安全校验往往不到位。JeecgBoot 的案例尤其典型——它不是没有做 SSRF 防护，而是防护遗漏了私网段地址，属于典型的”做了但不充分”的半吊子防护。

中国用户相关性分析

JeecgBoot 是中国开发团队 JEECG 开源社区维护的企业级低代码平台，GitHub 4.7万星，在国内 Java 开发圈拥有极高的知名度。它被广泛应用于政务系统、企业ERP、CRM、项目管理系统、数据可视化大屏等场景。根据社区公开数据，JeecgBoot 的码云（Gitee）镜像也有大量关注，国内使用量保守估计在数千家企业级别。

典型的国内使用场景包括：中小企业用 JeecgBoot 快速搭建内部管理系统并直接部署在阿里云/腾讯云的 ECS 上（8080端口直接对公网开放）、开发团队用它做原型验证并临时挂载在测试服务器上、或者政企单位在内网部署但通过 VPN 暴露到办公网络。这些场景中，只要 Airag 模块被启用且接口可达，就存在被利用的风险。

尤其需要注意的是，国内很多企业在云服务器上部署 JeecgBoot 时，习惯将安全组的 8080 端口设为 0.0.0.0/0（全部放行），理由是”方便调试”。这种做法会让 Airag 接口直接暴露在公网，任何扫描器都能发现并利用这个漏洞。

修复指南（分优先级）

P0紧急操作（立即执行）

方案一：Nginx 反向代理层封禁（最快生效，推荐）

如果你使用 Nginx 作为反向代理，最快的方式是在代理层直接封禁 airag 匿名接口：

# 在 nginx.conf 的 server 块中添加
location ~* ^/jeecg-boot/airag/ {
    deny all;
    return 403;
}

# 或仅允许内网IP访问
location ~* ^/jeecg-boot/airag/ {
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://backend;
}

# 重载配置
nginx -t && nginx -s reload

方案二：移除 @IgnoreAuth 注解（需改源码）

如果你有源码修改能力，找到 AiragChatController 类，移除 @IgnoreAuth 注解，强制要求登录：

// 修改前
@IgnoreAuth
@PostMapping(value = "/send")
public SseEmitter send(@RequestBody ChatSendParams chatSendParams) {

// 修改后（移除@IgnoreAuth，启用Sa-Token认证）
@PostMapping(value = "/send")
public SseEmitter send(@RequestBody ChatSendParams chatSendParams) {

// 重新编译部署
mvn clean package -DskipTests
# 替换部署的 jar 包后重启服务

方案三：直接移除 Airag 模块（如果不需要AI功能）

# 在 jeecg-module-system/pom.xml 中注释或删除 airag 依赖
<!--
<dependency>
    <groupId>org.jeecgframework.boot</groupId>
    <artifactId>jeecg-boot-module-airag</artifactId>
    <version>${jeecgboot.version}</version>
</dependency>
-->

# 重新编译
mvn clean package -DskipTests

P1长期方案（架构级修复）

完善 SsrfFileTypeFilter 的地址校验

在源码层面修复 SsrfFileTypeFilter，补充缺失的私网地址检查。这是根治漏洞的正确方式：

// org.jeecg.common.util.filter.SsrfFileTypeFilter
// 修复后的校验逻辑
for (InetAddress addr : InetAddress.getAllByName(host)) {
    if (addr.isLoopbackAddress()       // 127.0.0.0/8
        || addr.isLinkLocalAddress()   // 169.254.0.0/16
        || addr.isSiteLocalAddress()   // 10/172.16/192.168 私网 ← 新增
        || addr.isAnyLocalAddress()    // 0.0.0.0/8 ← 新增
        || addr.isMulticastAddress()   // 224.0.0.0/4 ← 新增
    ) {
        throw new JeecgBootException(
            "非法URL：禁止访问内网或保留地址 " + addr.getHostAddress());
    }
}

// 额外：显式拦截云元数据端点
// 阿里云: 100.100.100.200
// 腾讯云: metadata.tencentyun.com (169.254.0.23, 已被link-local覆盖)
// AWS:   169.254.169.254 (已被link-local覆盖)
if (host.equals("100.100.100.200")) {
    throw new JeecgBootException("非法URL：禁止访问云元数据接口");
}

关注官方版本更新

持续关注 JeecgBoot 的 GitHub Release 页面（github.com/jeecgboot/JeecgBoot/releases）。Issue #9672 已标记为 Closed，官方表示修复会在即将发布的版本中上线。一旦新版本发布，应尽快升级。当前最新版本为 3.9.2（2026年5月发布），预计修复版本可能是 3.9.3 或 3.10.0。

额外防护建议

1. 云安全组收紧端口暴露。立即检查阿里云/腾讯云/华为云的安全组规则，确保 8080 端口（JeecgBoot默认端口）不对 0.0.0.0/0 开放。正确做法是仅允许 Nginx 所在服务器或办公网络 IP 访问后端端口。

# 阿里云 CLI 修改安全组（示例）
aliyun ecs ModifySecurityGroupAttribute \
  --SecurityGroupId sg-xxxxx \
  --Description "Restrict 8080 to internal only"

# 或用内网IP白名单
aliyun ecs AuthorizeSecurityGroup \
  --SecurityGroupId sg-xxxxx \
  --IpProtocol tcp \
  --PortRange 8080/8080 \
  --SourceCidrIp 10.0.0.0/8

2. WAF 规则拦截异常请求。如果你使用云 WAF（如阿里云 WAF、长亭雷池），添加自定义规则拦截包含内网 IP 模式的 airag 请求：

# WAF规则：拦截 airag 接口中的内网地址
匹配URI: /airag/chat/send
匹配Body正则: (10\.\d+\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+|192\.168\.\d+\.\d+|100\.100\.100\.200)
动作: 拦截 + 告警

3. 监控异常出站请求。在 JeecgBoot 服务器上部署出站流量监控，及时发现 SSRF 探测行为：

# 使用 iptables 日志记录 JeecgBoot 进程的出站连接
iptables -A OUTPUT -m owner --uid-owner tomcat -d 10.0.0.0/8 -j LOG --log-prefix "SSRF_ALERT: "
iptables -A OUTPUT -m owner --uid-owner tomcat -d 172.16.0.0/12 -j LOG --log-prefix "SSRF_ALERT: "
iptables -A OUTPUT -m owner --uid-owner tomcat -d 192.168.0.0/16 -j LOG --log-prefix "SSRF_ALERT: "

# 检查日志
grep "SSRF_ALERT" /var/log/syslog | tail -20

4. 审计是否已被利用。如果你发现系统此前就已暴露在公网，建议检查服务器日志中是否存在可疑的 airag 请求：

# 检查 Nginx 访问日志中的可疑 airag 请求
grep "airag/chat/send" /var/log/nginx/access.log | grep -v "200"
grep "airag/chat/send" /var/log/nginx/access.log | grep -E "(10\.|172\.16|192\.168)"

# 检查后端日志中的文件下载记录
grep "download2DiskFromNet\|FileDownloadUtils" /path/to/jeecg-boot/logs/*.log

# 检查临时目录是否有异常下载文件
ls -la /tmp/*.txt /tmp/*.pdf /tmp/*.docx 2>/dev/null

安全工程教训

从这次漏洞中，有几个深层次的安全工程教训值得所有 Java 开发者深思。

教训一：安全注解不能替代安全设计。@IgnoreAuth 的存在本身不是错误——产品确实需要一个匿名可访问的 AI 聊天入口。但问题在于，这个入口暴露了不该暴露的能力（远程文件抓取）。正确的做法是将”需要认证的高危操作”和”匿名可用的基础功能”分离到不同的接口，而不是用一个 @IgnoreAuth 注解一刀切地放开整个接口的所有功能。在设计 API 时，每一个”注解”背后都应该有对应的安全分析：移除认证后，这个接口还剩哪些操作？这些操作是否有足够的输入校验？

教训二：SSRF 校验必须覆盖全部保留地址段。Java 的 InetAddress 类提供了丰富的地址类型判断方法：isLoopbackAddress、isLinkLocalAddress、isSiteLocalAddress、isAnyLocalAddress、isMulticastAddress。一个完整的 SSRF 防护必须检查全部五种。只检查其中一两种，就像锁了前门却开着后窗——攻击者总会找到你没堵的那个口子。此外，云环境的元数据端点（阿里云 100.100.100.200、AWS 169.254.169.254）必须额外显式拦截，因为它们的 IP 不一定落入标准的保留地址段。

教训三：AI 功能引入需评估安全债务。JeecgBoot 在 v3.8.1 引入 Airag 模块时，将”远程文档解析”能力集成进了一个匿名接口。这是典型的”功能优先、安全后补”思维。在 AI 应用爆发的当下，越来越多的传统应用都在集成”联网搜索””文档解析””知识库构建”等功能。每增加一个服务端发起外部请求的能力，就增加了一分 SSRF 风险。开发团队在引入这类功能时，应当同步进行安全威胁建模，而不是等漏洞被披露后再来补锅。

教训四：低代码平台的安全责任。低代码平台的核心理念是”让非专业开发者也能快速搭建系统”。这意味着使用者往往缺乏安全意识，默认配置就是最终配置。JeecgBoot 作为 4.7万星的成熟平台，有责任确保开箱即用的默认配置是安全的——至少不应将高危接口默认设为无认证。每一个默认开放的高风险功能，都可能影响数千家使用该平台的企业。

总结 + 参考信息

行动清单

如果你是 JeecgBoot 用户，请按以下优先级执行：

立即检查版本：确认是否使用 3.9.2 或更早版本，以及是否集成了 Airag 模块。
立即封堵接口：在 Nginx 层封禁 /airag/chat/send 路径，或移除 @IgnoreAuth 注解，或直接移除 airag 模块依赖。
收紧网络暴露：检查云安全组，确保 8080 端口不对公网开放，仅允许必要 IP 访问。
审计历史日志：检查服务器日志中是否存在可疑的 airag 请求和异常的文件下载行为。
关注版本更新：订阅 JeecgBoot Release 通知，修复版本发布后立即升级。
部署 WAF 规则：添加针对 airag 接口的内网地址模式拦截规则。

参考信息

这个漏洞再次提醒我们：AI 功能的集成不能只顾功能酷炫，安全防护必须同步跟上。JeecgBoot 作为一个成熟的低代码平台，其 SSRF 校验只覆盖了 loopback 和 link-local 两个地址段，遗漏了最核心的私网段——这种”半吊子”防护比完全不防护更具迷惑性，因为它给人一种”已经有防护了”的虚假安全感。如果你正在使用 JeecgBoot，请立即按照上述行动清单排查和修复，不要等到成为攻击目标才行动。

龙虾池子

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：龙虾池子龙虾池子龙虾池子《4.7万星JeecgBoot匿名接口SSRF：一个请求打穿你的企业内网》