讨论下XXL-JOB GLUE模式的安全问题

XXL-JOB这个大家应该都不陌生，鼎鼎大名的一个分布式任务调度平台。XXL-JOB有一个任务执行模式叫GLUE模式，GLUE模式本质是调度中心把一段源码下发给执行器，执行器动态编译 / 直接执行（Groovy/Shell/Python 等）；和BEAN模式的区别是BEAN模式只是调用执行器本地预先写好的Handler。

GLUE模式有个核心风险，就是一旦攻击者能下发 GLUE 代码，就能在执行器服务器上执行任意代码（RCE）。其实GLUE本身是 “允许远程下发代码执行” 的能力，不是 bug；但一旦鉴权、权限、网络配置失守，直接变成高危RCE入口。

一、GLUE模式原理

• GLUE(Java/Groovy)：执行器收到调度请求，使用GroovyClassLoader动态编译调度中心下发的源码，实例化IJobHandler并执行，可以直接访问执行器JVM里的Spring Bean、类、文件系统。
• GLUE_SHELL/Python/Node等脚本：执行器直接调用系统解释器执行下发的脚本，可直接执行系统命令。
• 源码保存在xxl-job-admin数据库，每次调度会把glueSource下发给executor。

二、主要安全风险

1. 远程代码执行（最核心风险）

只要攻击者可以控制GLUE代码内容，就能在执行器机器执行任意代码：

• GLUE Groovy：可读写本地文件、调用系统命令、访问内网资源、操作Spring上下文、窃取数据库配置。
• GLUE Shell：直接反弹shell、下载木马、执行系统命令。

利用前提：拿到admin控制台账号 或 拿到executor的accessToken，直接调用executor的/run接口下发恶意GLUE任务。

常见踩坑场景：

1. admin使用默认账号密码admin/123456，公网可访问，被爆破登录，新建GLUE任务写入恶意代码。
2. executor未配置accessToken（默认default_token不改），攻击者直接调用执行器HTTP接口下发恶意GLUE任务。
3. admin存在越权/未授权漏洞，攻击者无需登录即可创建/修改GLUE任务。

2. 权限横向扩散风险

执行器通常部署在内网业务服务器上：

• GLUE代码以执行器进程身份运行；若执行器进程是root/高权限账号，攻击者直接拿到高权限。

• 执行器可访问内网数据库、Redis、中间件、其他内网服务，可作为内网横向移动跳板。

3. Groovy类加载带来的额外风险

GroovyClassLoader动态加载类：

• 可绕过部分Java沙箱，反射调用危险类；

• 类缓存泄漏：多次修改GLUE代码会生成大量class，存在内存泄漏、类污染风险；

• CVE-2026-90488：GroovyClassLoader.parseClass存在代码注入风险，低权限用户可注入恶意代码。

4. 审计与溯源困难

• GLUE代码存在数据库，不是项目源码，版本管理缺失；

• 在线编辑，代码变更日志仅依赖xxl-job自带日志，容易被删除；

• 恶意代码执行后，可在执行器本地不留痕迹，排查难度大。

5. 其他衍生风险

• 命令注入：GLUE脚本如果拼接参数不当，存在二次注入；

• 信息泄露：GLUE代码可读取本地配置文件、环境变量，窃取数据库密码、accessKey；

• SSRF：GLUE代码可发起内网请求，扫描内网服务。

三、典型攻击链路

1. 公网xxl-job-admin弱口令被攻破 → 登录后台
2. 新建GLUE_SHELL / GLUE_GROOVY任务，写入反弹Shell代码
3. 手动触发任务 → 调度中心下发恶意脚本到executor
4. executor执行恶意代码，服务器被拿下

不需要入侵调度中心服务器，只需要拿到admin控制台的任务编辑权限，就能控制所有执行器。

四、安全加固方案

方案1：禁用GLUE，使用BEAN模式

绝大多数业务场景完全不需要GLUE。

• 执行器侧关闭脚本能力：修改代码，只允许BEAN模式，拒绝所有GLUE类型；
• 后台隐藏GLUE选项，限制新增任务只能选BEAN；
• 业务任务代码写在执行器本地，通过@XxlJob定义Handler，代码纳入Git版本管理、代码评审。

方案2：如果必须保留GLUE，强化多层防护

1. 执行器accessToken必须修改，禁止默认值
   每个执行器配置独立强随机accessToken，不要所有执行器共用同一个token。
2. 网络层面隔离
   • xxl-job-admin不要直接暴露公网；放内网，通过VPN/堡垒机访问；
   • executor的服务端口（默认9999）禁止对公网开放；配置IP白名单，只允许admin节点IP访问executor。
3. admin控制台账号安全
   • 修改默认密码，强密码策略；开启MFA；最小权限：区分任务查看、任务编辑、管理员角色，普通用户禁止创建/修改GLUE任务。
4. GLUE代码变更审批与审计
   • GLUE代码修改必须人工审批；
   • 开启完整日志：GLUE源码变更记录、任务触发日志、执行器stdout/stderr日志，日志不可删，长期留存。
5. 执行器进程最小权限
   执行器进程不要用root/管理员账号，使用低权限账号运行；容器化部署，限制容器权限、挂载、网络访问。
6. 版本升级
   升级xxl-job到最新稳定版，修复历史越权、命令注入等漏洞。

方案3：GLUE代码沙箱限制（有限缓解，不能完全信任）

Groovy沙箱有绕过案例，不能作为唯一防护手段：

• 限制危险类：禁止java.lang.Runtime、ProcessBuilder、文件读写、反射等；
• Shell类GLUE增加命令白名单，禁止任意命令。

GLUE模式的本质就是远程下发代码执行能力，它不是一个远程代码漏洞，但是一个高危功能。所以业务环境尽量禁用GLUE，统一使用BEAN模式；确需GLUE时，必须严格控制admin访问权限、执行器token、网络白名单，并且最小化执行器进程权限。

近些年来由于AI的大力发展，很多应用程序隐藏多年的漏洞也随之爆炸式的被人发现，同时衍生出来大量安全问题，大家还是要提高安全意识比较好。