xxl-job: 3,350 application matches against 148 page titles
xxl-job: 3,350 application matches against 148 page titles
Schedulers are the component that makes a system act without a person. xxl-job is a distributed task scheduling platform with an admin console and executor nodes, widely used for batch jobs, data synchronisation and periodic maintenance. Measuring it online produces a large discrepancy that explains a common inventory mistake.
The measurement
ZoomEye queries executed on 23 October 2026, sub_type=all, page size one, matched totals:
- app="xxl-job": 3,350
- title="xxl-job": 148
- title="xxl-job" && port="8080": 17
- title="xxl-job" && ssl="xxl-job": 0
The application fingerprint finds more than twenty times as many assets as the title. A fingerprint matches protocol-level evidence the product emits, not the string on its HTML page.
Which number describes exposure
Neither, on its own.
The 3,350 figure includes everything the fingerprint can recognise, and recognition can come from a response pattern rather than from a reachable management interface. A host that answers on a service port with a characteristic signal is counted whether or not an administrator can log in from outside.
The 148 figure describes pages whose title contains the product name. On a real deployment, the admin console's title is often customised by a deployment template, translated, or prefixed with an organisation name. Seventeen of those also answered on port 8080, which is the conventional console port in the project's documentation.
The honest reading: 3,350 assets expose something identifiable, at least 148 expose a recognisable console page, and 17 expose that page on the default port. All three numbers are lower bounds for different questions.
What an admin console can do
xxl-job's console is a management interface. It lists executors and their registered addresses, displays job definitions and their schedules, and lets an operator trigger a job immediately, edit its parameters, or view the execution log.
A job parameter is where the operational risk concentrates. Jobs frequently call scripts, invoke HTTP endpoints, or run SQL. Editing a parameter on an existing job is a smaller action than deploying new code and achieves a comparable effect: the next scheduled run executes different logic.
That does not require a software vulnerability. It requires access to the console.
The executor side has its own surface. Executors register with the admin and accept trigger requests. Their registration endpoint is how the admin learns where to send work. A network path that lets anything register as an executor, or lets anything send a trigger to an executor, is a control-plane exposure independent of the console's authentication.
Why schedulers drift outward
Three operational patterns push these consoles to reachable addresses.
First, executors in different network zones need to reach the admin, and opening the path for the executor is easier than segmenting it. The console then shares that path.
Second, an operator on a laptop outside the office wants the interface. A VPN is slower to arrange than a firewall rule.
Third, monitoring. An uptime check or a screenshot dashboard needs an HTTP endpoint that responds without a session.
None of those are unreasonable on their own. Together they produce the population that a fingerprint query can see.
The internal check
- Enumerate admin consoles and executor nodes separately. They have different exposure requirements and different credentials.
- Ask whether the console needs a public listener at all. Where remote access is required, a bastion or an authenticated proxy is the usual answer, and it also produces a useful audit trail.
- Review the authentication setting. The admin's login is a configuration option in many deployments; verify it is enabled rather than assumed.
- Check job parameters for anything that executes along a path an unauthorised editor could influence. A job that reads a parameter and interpolates it into a command is an execution primitive with a scheduler attached.
- Restrict executor registration to known addresses. This is a network control, and it holds whether or not the console is exposed.
Detection notes
The admin's own access log is the primary record. Configuration changes, manual triggers, and executor registrations are all discrete actions with an actor. Alerting on a manual trigger outside the normal schedule is a low-noise rule with a high payoff.
On the executor side, child processes spawned by the executor service that do not match the job's declared script are worth an alert. That is the point where a benign-looking parameter edit becomes visible as behaviour.
Where the index helps
Fingerprint counts are useful for the question an organisation cannot answer from its own records: how common is this configuration in the wild. When 3,350 assets are identifiable and only 148 present a titled console, the lesson is that the visible surface understates the population, and an inventory built from page titles alone will miss most of the estate.
References
- xxl-job project documentation: xuxueli.com
- xxl-job source repository: xuxueli/xxl-job
- ZoomEye queries executed 23 October 2026 with sub_type=all: app="xxl-job" 3,350; title="xxl-job" 148; title="xxl-job" && port="8080" 17; title="xxl-job" && ssl="xxl-job" 0
Mentions
xxl-job: 3,350 application matches against 148 page titles xxl-job: 3,350 application matches against 148 page titles Schedulers are the component that makes a system act without a person. xxl-job is a distributed task scheduling platform with an admin console and executor nodes, widely used for batch jobs, data synchronisation and periodic maintenance. Measuring it online produces a large discrepancy that explains a common inventory mistake. The measurement ZoomEye queries executed on 23 October 2026, sub_type=all, page size one, matched totals: - app="xxl-job": 3,350 - title="xxl-job": 148 - title="xxl-job" && port="8080": 17 - title="xxl-job" && ssl="xxl-job": 0 The application fingerprint finds more than twenty times as many assets as the title. A fingerprint matches protocol-level evidence the product emits, not the string on its HTML page. Which number describes exposure Neither, on its own. The 3,350 figure includes everything the fingerprint can recognise, and recognition can come from a response pattern rather than from a reachable management interface. A host that answers on a service port with a characteristic signal is counted whether or not an administrator can log in from outside. The 148 figure describes pages whose title contains the product name. On a real deployment, the admin console's title is often customised by a deployment template, translated, or prefixed with an organisation name. Seventeen of those also answered on port 8080, which is the conventional console port in the project's documentation. The honest reading: 3,350 assets expose something identifiable, at least 148 expose a recognisable console page, and 17 expose that page on the default port. All three numbers are lower bounds for different questions. What an admin console can do xxl-job's console is a management interface. It lists executors and their registered addresses, displays job definitions and their schedules, and lets an operator trigger a job immediately, edit its parameters, or view the execution log. A job parameter is where the operational risk concentrates. Jobs frequently call scripts, invoke HTTP endpoints, or run SQL. Editing a parameter on an existing job is a smaller action than deploying new code and achieves a comparable effect: the next scheduled run executes different logic. That does not require a software vulnerability. It requires access to the console. The executor side has its own surface. Executors register with the admin and accept trigger requests. Their registration endpoint is how the admin learns where to send work. A network path that lets anything register as an executor, or lets anything send a trigger to an executor, is a control-plane exposure independent of the console's authentication. Why schedulers drift outward Three operational patterns push these consoles to reachable addresses. First, executors in different network zones need to reach the admin, and opening the path for the executor is easier than segmenting it. The console then shares that path. Second, an operator on a laptop outside the office wants the interface. A VPN is slower to arrange than a firewall rule. Third, monitoring. An uptime check or a screenshot dashboard needs an HTTP endpoint that responds without a session. None of those are unreasonable on their own. Together they produce the population that a fingerprint query can see. The internal check - Enumerate admin consoles and executor nodes separately. They have different exposure requirements and different credentials. - Ask whether the console needs a public listener at all. Where remote access is required, a bastion or an authenticated proxy is the usual answer, and it also produces a useful audit trail. - Review the authentication setting. The admin's login is a configuration option in many deployments; verify it is enabled rather than assumed. - Check job parameters for anything that executes along a path an unauthorised editor could influence. A job that reads a parameter and interpolates it into a command is an execution primitive with a scheduler attached. - Restrict executor registration to known addresses. This is a network control, and it holds whether or not the console is exposed. Detection notes The admin's own access log is the primary record. Configuration changes, manual triggers, and executor registrations are all discrete actions with an actor. Alerting on a manual trigger outside the normal schedule is a low-noise rule with a high payoff. On the executor side, child processes spawned by the executor service that do not match the job's declared script are worth an alert. That is the point where a benign-looking parameter edit becomes visible as behaviour. Where the index helps Fingerprint counts are useful for the question an organisation cannot answer from its own records: how common is this configuration in the wild. When 3,350 assets are identifiable and only 148 present a titled console, the lesson is that the visible surface understates the population, and an inventory built from page titles alone will miss most of the estate. References - xxl-job project documentation: xuxueli.com - xxl-job source repository: xuxueli/xxl-job - ZoomEye queries executed 23 October 2026 with sub_type=all: app="xxl-job" 3,350; title="xxl-job" 148; title="xxl-job" && port="8080" 17; title="xxl-job" && ssl="xxl-job" 0
XXL-AI v1.1.1 发布｜ Desk 桌面客户端正式上线，云本结合再进一步 Release Notes [云版（ Web 服务端）] - 1 、 [优化] 项目合并部署：研发环节前后端分离，部署期前端产物内嵌进后端 Jar ，单进程单端口对外； - 2 、 [新增] I18N 模块重构：前后端国际化逻辑优化，统一后端控制；标准化国际化资源文件结构，支持多语言配置，并优化前端国际化加载逻辑； - 3 、 [优化] 模型 API 请求通参调整，设置 User-Agent: XXL-AI 便于供应商识别； - 4 、 [优化] 供应商模型请求参数属性优化，支持格式检测与合法性检测； - 5 、 [升级] 项目依赖升级最新版本； [本地版（ Desk 桌面端）] > 本地版（ Desk 桌面端）以·与云版零依赖、独立构建发布；详细安装与操作见官方文档。 - 1 、 [重点] Desk/客户端上线：基于 Electron + Vue3 + TypeScript 构建跨平台桌面客户端，支持 mac / win / linux 一键安装及应用，本地优先、开箱即用； - 2 、 [新增] 多供应商模型接入：兼容 OpenAI 协议，供应商 + 模型本地配置；首次启动自动预置 OpenCodeGo / Ollama / Deepseek / 智谱 GLM ； - 3 、 [架构] Agent 运行时进程隔离：Pi （pi-ai + pi-agent-core）运行于独立 utilityProcess，主进程仅做 IPC 网关与越界审批，长会话与工具重活不阻塞 UI ； - 4 、 [新增] Plan / Build 模式：Plan 只读（仅只读文件与检索工具）、Build 全量读写，随会话持久化，默认 Build ；文件操作限定当前项目目录，越界弹原生对话框「允许本次 / 本会话允许 / 拒绝」； - 5 、 [新增] 流式对话与执行过程可视化：流式输出思考过程 / 工具调用 / 回复内容；助手消息按片段发生顺序渲染时间线（思考 → 工具 → 正文交错），思考折叠、工具调用状态与耗时展示、Markdown 实时渲染与代码高亮； - 6 、 [新增] 项目与会话管理：项目绑定本地磁盘目录，会话归属项目，支持搜索 / 重命名 / 删除 / 排序；会话与消息落本地 SQLite 单文件，运行时数据目录可自定义； - 7 、 [新增] 本地系统能力：终端命令行（ node-pty + xterm ）；侧边任务面板含文件（目录树 + 编辑保存 + 预览 + 跟随本地变更）与浏览器（多标签 webview）； - 8 、 [新增] 个性化设置：应用名称 / Slogan / 自定义指令，浅色（默认）/ 深色主题，中 / 英双语； - 9 、 [优化] 性能与体验：会话落库增量 + 单事务、运行时增量合批、渲染端按需滚动；生成中切换会话不丢内容；退出时回收运行时与终端进程。 - 10 、 [强化] Desk 命令运行环境（ Node/Python ）支持自定义 PATH 设置，提升本地环境兼容性； Node 默认使用内置版本，降低本地环境依赖； - 11 、 [强化] Desk 终端 locale 显示设置 UTF-8 ，解决中文乱码问题； - 12 、 [新增] 客户端支持自动检测新版本，并引导升级； 一、简介 XXL-AI 是一个「云本结合」的 AI Agent 开发平台，提供两种同源同品牌、能力互补的交付形态，可按团队规模与使用场景独立选用，也可组合使用： > * 云版：以 Agent 编排为中枢，标准化扩展「 MCP + SKILL + RAG 」，配套多供应商、空间隔离、RBAC 权限与流式对话等工程化底座，可快速构建并一键发布 Agent 。开源、开箱即用，支持集群部署与生产落地。 > * 本地版：跨平台桌面客户端：面向个人的本地工作台，围绕本机项目目录提供对话、文件读写、终端命令、文件 / 浏览器侧边任务等能力；安装即用、离线可用，数据仅落本地 SQLite 。 | 项 | 云版（ Web 服务端） | 本地版（ Desk 桌面端） | | -- | --------------------------------------------- | --------------------------------- | | 形态 | B/S Web 应用，浏览器访问 | C/S 桌面应用，一键安装（ mac / win / linux ） | | 面向 | 团队——多用户、多业务空间（ Tenant ） | 个人——单用户本地工作台 | | 定位 | Agent 编排、一键发布、权限治理 | 本地优先，直接操作本机项目与系统能力 | | 扩展 | MCP + SKILL + RAG ，多供应商，流式对话 | 本地文件 / 终端 / 浏览器面板，Plan / Build 模式 | | 模块 | xxl-ai-api + xxl-ai-ui（+ xxl-ai-sample） | xxl-ai-desk | | 依赖 | MySQL + Redis + Milvus | 零依赖（仅本地 SQLite ） | 二、文档地址 - 中文文档：<xuxueli.com> - Github 地址：<xuxueli/xxl-ai> 三、架构设计 XXL-AI 采用「云本结合」：云版（ Web / 服务端）与本地版（ Desk 桌面端）同源互补。整体自上而下分为入口、前端、应用、运行时、支撑、外部六层： ┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ 入口层 管理端 admin （浏览器） · 公开端访客 /#/chat/{uuid} · Desk 桌面客户端（ mac / win / linux ） │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 前端层 云版 xxl-ai-ui —— Vue3 + Vite + Element Plus + TS ；开发 :3000 ，生产内嵌进 API （ Hash 路由）│ │ 本地版 Desk Renderer —— Vue3 + Element Plus ； contextBridge → window.desk.* │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 应用层 云版 xxl-ai-api —— SpringBoot + MyBatis + XXL-SSO ，:8080 │ │ framework：登录鉴权 · RBAC 菜单/按钮 · 系统管理 · 审计日志 │ │ business：空间 · 供应商 · 知识库 · MCP · SKILL · Agent · Chat │ │ 本地版 Desk Main —— IPC 网关 · SQLite(Drizzle) 持久化 · Agent 托管 · 越界审批 │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 运行时层 云版 harness —— llm · chat · rag · mcp · skill · supplier （运行时支撑，无 Controller ） │ │ 本地版 Pi 运行时 —— pi-ai + pi-agent-core ，独立 utilityProcess │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 支撑层 云版 MySQL （业务/平台） · Redis （登录态 + 对话流） · Milvus （向量库） │ │ 本地版 SQLite 单文件（零依赖） · 本地文件 / 终端 / 浏览器 │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 外部层 OpenAI 兼容供应商（对话/嵌入） · 远程/本地 MCP 服务 · 示例 xxl-ai-sample （可选） │ └──────────────────────────────────────────────────────────────────────────────────────────────────────┘ 四、安装部署 XXL-AI 是一个「云本结合」的 AI Agent 开发平台，提供两种同源同品牌、能力互补的交付形态，可按团队规模与使用场景选用合适版本安装和部署。 4.1 [云版（ Web 服务端）] XXL-AI 云版项目，支持 Docker Compose 一键部署，部署脚本如下： # 第一步：代码 clone 本部 + 前往仓库目录 git clone https://github.com/xuxueli/xxl-ai.git cd ./xxl-ai # 第二步：构建前端并同步产物（ npm run build 构建 dist ，npm run sync:dist 复制到 xxl-ai-api 静态资源目录） cd xxl-ai-ui && npm install && npm run build && npm run sync:dist && cd .. # 第三步：构建后端 mvn clean package # 第四步：进入 docker 目录（支持自定义 .env 配置，如修改 MYSQL_PATH 配置设置 Mysql 数据持久化目录） cd ./docker/ cat .env # 第五步：启动/停止项目 docker compose up -d docker compose down 4.2 [本地版（ Desk 桌面端）] XXL-AI 本地版项目，支持跨平台客户端一键安装，下载对应版本（如 mac/win ）安装程序即可。 - 下载地址：<github.com/xuxueli/xxl-ai/releases> 五、核心功能操作指南 5.1 [本地版（ Desk 桌面端）] - 安装并打开 Desk 客户端  - 配置供应商模型  - 使用示例：Desk 客户端/Agent 通过 本地系统能力（ Node/Python ）进行文件操作。  5.2 [云版（ Web 服务端）] - 登录工作台  - 编排 Agent  - 发布 Agent  - 使用示例：Agent 调用 MCP 工具（网页抓取）汇总「今日热点社会新闻」 