Flowise预认证任意文件上传漏洞CVE-2025-26319深度分析

2026-06-20阅读 0热度 0

文件上传

漏洞总览

Flowise 是一款开源低代码/无代码平台，GitHub 星标超过 35K，Docker 拉取量突破 100 万，用户覆盖中小型企业到大型机构。其核心卖点是可视化拖拽界面，非技术人员也能快速搭建 AI 聊天机器人，灵活配置知识库、工具链与模型。

然而，实际使用中我们发现一个严重漏洞（CVE-2025-26319）。问题出在“知识上传”功能：未经验证的攻击者能够向服务器任意写入文件。恶意脚本、配置文件乃至 SSH 密钥均可通过此入口注入，直接导致服务器完全沦陷。

技术剖析

Flowise 系统内部定义了一组无需认证即可访问的 API 白名单，名为 WHITELIST_URLS。

export const WHITELIST_URLS = ['/api/v1/verify/apikey/','/api/v1/chatflows/apikey/','/api/v1/public-chatflows','/api/v1/public-chatbotConfig','/api/v1/prediction/','/api/v1/vector/upsert/','/api/v1/node-icon/','/api/v1/components-credentials-icon/','/api/v1/chatflows-streaming','/api/v1/chatflows-uploads','/api/v1/openai-assistants-file/download','/api/v1/feedback','/api/v1/leads','/api/v1/get-upload-file','/api/v1/ip','/api/v1/ping','/api/v1/version','/api/v1/attachments','/api/v1/metrics']

服务器收到请求后，先判断路径是否属于白名单。若匹配则直接放行，否则走身份验证流程。核心逻辑如下：

// @ /packages/server/src/index.tsthis.app.use(async (req, res, next) => {// Step 1: Check if the req path contains /api/v1 regardless of caseif (URL_CASE_INSENSITIVE_REGEX.test(req.path)) {// Step 2: Check if the req path is case sensitiveif (URL_CASE_SENSITIVE_REGEX.test(req.path)) {// Step 3: Check if the req path is in the whitelistconst isWhitelisted = whitelistURLs.some((url) => req.path.startsWith(url))if (isWhitelisted) {next() // continue} else if (req.headers['x-request-from'] === 'internal') {basicAuthMiddleware(req, res, next)} else {const isKeyValidated = await validateAPIKey(req)if (!isKeyValidated) {return res.status(401).json({ error: 'Unauthorized Access' })}next()}} else {return res.status(401).json({ error: 'Unauthorized Access' })}} else {// If the req path does not contain /api/v1, then allow the request to pass through, example: /assets, /canvasnext()}})

重点关注路由 /api/v1/attachments。该接口原本用于终端用户上传附件（如图片供聊天机器人识别），逻辑本身合理。致命之处在于它被列入白名单，彻底绕过了身份验证。

// @ /packages/server/src/routes/attachments/index.tsconst router = express.Router()// CREATErouter.post('/:chatflowId/:chatId', getMulterStorage().array('files'), attachmentsController.createAttachment)export default router

请求进入 createFileAttachment 函数后，仅校验了 chatflowId 和 chatId 参数是否存在，未做格式或权限检查。换言之，只要传值即通过。

// @ /packages/server/src/utils/createAttachment.ts// @ createFileAttachment functionconst chatflowid = req.params.chatflowIdif (!chatflowid) {throw new Error('Params chatflowId is required! Please provide chatflowId and chatId in the URL: /api/v1/attachments/:chatflowId/:chatId')}const chatId = req.params.chatIdif (!chatId) {throw new Error('Params chatId is required! Please provide chatflowId and chatId in the URL: /api/v1/attachments/:chatflowId/:chatId')}

拿到参数后，函数读取上传文件并调用 addArrayFilesToStorage 写存储。核心代码如下：

// @ /packages/components/src/storageUtils.ts// @ addArrayFilesToStorage functionexport const addArrayFilesToStorage = async (mime: string,bf: Buffer,fileName: string,fileNames: string[],...paths: string[]) => {const storageType = getStorageType()const sanitizedFilename = _sanitizeFilename(fileName)if (storageType === 's3') {// ...} else {const dir = path.join(getStoragePath(), ...paths) // PATH TRA VERSAL.if (!fs.existsSync(dir)) {fs.mkdirSync(dir, { recursive: true })}const filePath = path.join(dir, sanitizedFilename)fs.writeFileSync(filePath, bf)fileNames.push(sanitizedFilename)return 'FILE-STORAGE::' + JSON.stringify(fileNames)}}

注意代码注释中明确标注的“PATH TRA VERSAL”——path.join 将存储根路径与 ...paths（即用户传入的 chatflowId、chatId）直接拼接。这两个参数完全由用户控制，且未校验是否为 UUID 或整数。结合用户可控的文件名，攻击者可通过路径遍历将文件写入任意目录。

漏洞利用演示（POC）

以下是一个未携带任何认证信息的 HTTP 请求示例。攻击者仅需操控 chatId 参数插入 ../ 实现路径穿越，即可覆盖敏感文件。例如覆盖存储 API 密钥的 api.json：

dir 会解析为类似 /root/.flowise/storage/test/../../../../../root/.flowise/，文件名设为 api.json。上传完成后返回管理界面查看 API 密钥，发现已被篡改。

漏洞影响

未认证的任意文件上传远不止修改 API 密钥：

整个聊天机器人框架被彻底控制
攻击者直接获取服务器远程执行权限
数据泄露、横向渗透，后续操作几乎无限制

披露时间线

2025年1月20日 — 首次通过官方渠道联系供应商。
2025年2月2日 — 通过 GitHub 私有安全报告功能提交漏洞详情。
2025年2月11日 — 通过 Flowise Discord 服务器第二次尝试联系。
2025年2月17日 — 通过 Flowise 官方邮箱第三次尝试。
2025年2月28日 — 第四次尝试，并通知即将公开发布。
2025年3月6日 — 发布此博客。

重要说明

遗憾的是，Flowise 团队在整个过程中未给予任何回应。45 天内我们尝试所有渠道希望协同修复，但始终未获确认。鉴于该漏洞已被积极利用，我们不得不做出艰难决定——公开披露，以便社区尽早防范。修复方案并不复杂，我们已准备好补丁代码，有需求者可参考。

补救措施

两种方式可缓解此漏洞：

迁移存储类型至 S3：默认本地存储放大了攻击面。使用 S3 后此类路径穿越攻击将无效。
应用附带的补丁：补丁代码极小，逻辑清晰，经审查后即可放心部署。