CVE-2026-52614 - RuoYi v4.8.3 filterKeyword Bypass de Injeção SQL

中文 | Inglês

Autorização necessária / 仅限授权测试
Este repositório destina-se apenas a pesquisa de segurança e testes autorizados. Não o utilize contra sistemas sem permissão explícita.
本仓库仅用于安全研究与已获明确授权的测试。请勿对未授权系统使用。

中文说明

漏洞简介

RuoYi v4.8.3 代码生成模块的 /tool/gen/createTable 接口允许后台用户提交建表 SQL。接口调用 SqlUtil.filterKeyword() 进行关键字黑名单过滤，但实现中先删除输入里的全部空白字符，再匹配包含尾随空格的关键字（例如 select 、insert 、drop ），导致相关规则无法命中。

通过 CREATE TABLE ... AS SELECT ...（CTAS）语句，可在通过 Druid MySqlCreateTableStatement 类型检查的同时执行 SELECT。具有有效后台会话的攻击者可据此构造布尔盲注，读取数据库中的敏感信息并创建数据表。

影响条件

• 目标为 RuoYi v4.8.3。
• 攻击者已登录后台并持有有效的 JSESSIONID。
• 当前账号可以访问代码生成模块相关接口。
• 数据库及当前数据库账号允许执行 CTAS 建表操作。

漏洞原理

验证脚本使用以下逻辑提取 sys_user 表中 admin 用户的密码哈希和 salt：

1. 通过 CTAS 创建中间表，复制 login_name、password 和 salt 字段。
2. 为每一个待判断字符创建测试表，并在 WHERE 中加入 SUBSTRING() 条件。
3. 条件为真时，CTAS 返回数据，测试表不会被自动导入代码生成表列表。
4. 条件为假时，CTAS 返回零行，测试表会被自动导入，可通过 /tool/gen/list 查询到。
5. 根据测试表是否出现在列表中，逐字符恢复密码哈希和 salt。

环境要求

• Python 3.8+
• 有效且已授权的 RuoYi 后台会话
• Python 依赖：requests、urllib3

安装依赖：

python -m pip install requests urllib3

使用方法

打开 exp.py，修改顶部配置区中的以下两行：

TARGET = "http://127.0.0.1:8080"
COOKIE = "JSESSIONID=your_session_id"

其中：

• TARGET：替换为待测试的 RuoYi URL，例如 http://127.0.0.1:8080。
• COOKIE：替换为登录后台后获得的有效 JSESSIONID session。

修改完成后直接运行：

python exp.py

脚本会在目标数据库中创建中间表和大量布尔判断测试表。请仅在隔离或授权环境中使用，并在测试完成后由数据库管理员清理相关表。

验证截图

exp.png 为本地授权环境中的成功验证截图：

修复建议

• 不要使用字符串黑名单判断 SQL 安全性，更不要直接执行用户提交的 SQL。
• 修正 filterKeyword() 的规范化与匹配逻辑，但不要将其作为唯一防护。
• 对代码生成接口实施严格的权限控制、操作审计和 CSRF 防护。
• 禁止或移除任意 SQL 建表能力；如业务确有需要，应使用结构化参数构造固定语句。
• 使用最小权限数据库账号，限制读取敏感表以及执行 CTAS/DDL 的权限。
• 升级到官方已修复版本或应用官方安全补丁。

Inglês

Resumo

O endpoint /tool/gen/createTable no módulo de geração de código do RuoYi v4.8.3 aceita SQL de criação de tabela de usuários autenticados do backend. O endpoint chama SqlUtil.filterKeyword() para bloquear palavras-chave SQL perigosas. No entanto, a implementação remove todos os espaços em branco da entrada antes de verificar as entradas da lista negra que contêm espaços à direita, como select , insert e drop . Essas entradas, portanto, não conseguem corresponder à entrada normalizada.

Uma instrução CREATE TABLE ... AS SELECT ... (CTAS) pode passar na verificação de tipo MySqlCreateTableStatement do Druid enquanto ainda executa um SELECT. Um atacante com uma sessão válida de backend pode usar esse comportamento para injeção SQL cega baseada em booleanos, extração de dados sensíveis e criação de tabelas.

Pré-condições

• O alvo executa RuoYi v4.8.3.
• O testador possui um JSESSIONID de backend autenticado válido.
• A conta autenticada pode acessar os endpoints de geração de código.
• O banco de dados e sua conta configurada permitem operações CTAS.

Como o PoC Funciona

O script recupera o hash da senha e o salt do usuário admin da tabela sys_user usando o seguinte oráculo:

1. Crie uma tabela intermediária contendo login_name, password e salt.
2. Crie uma tabela de teste por caractere candidato com uma condição SUBSTRING().
3. Quando a condição é verdadeira, o CTAS retorna uma linha e a tabela de teste não é importada automaticamente para a lista de tabelas do gerador.
4. Quando a condição é falsa, o CTAS retorna zero linhas e a tabela é importada automaticamente, tornando-a visível através de /tool/gen/list.
5. Use essa diferença para recuperar o hash da senha e o salt, um caractere de cada vez.

Requisitos

• Python 3.8+
• Uma sessão de backend RuoYi válida e autorizada
• Pacotes Python: requests, urllib3

Instale as dependências:

python -m pip install requests urllib3

Uso

Abra exp.py e substitua as duas linhas a seguir na seção de configuração perto do topo do arquivo:

TARGET = "http://127.0.0.1:8080"
COOKIE = "JSESSIONID=your_session_id"

Onde:

• TARGET é a URL base do RuoYi a ser testada, por exemplo http://127.0.0.1:8080.
• COOKIE é uma sessão JSESSIONID de backend autenticada válida.

Após substituir a URL e a sessão, execute:

python exp.py

O script cria uma tabela intermediária e muitas tabelas de teste booleano no banco de dados alvo. Use-o apenas em um ambiente isolado ou explicitamente autorizado, e peça ao administrador do banco de dados para remover as tabelas geradas após o teste.

Captura de tela

exp.png mostra uma verificação bem-sucedida em um ambiente local autorizado:

Mitigação

• Não confie em listas negras de palavras-chave SQL nem execute SQL fornecido pelo usuário diretamente.
• Corrija a lógica de normalização e correspondência em filterKeyword(), mas não a trate como o único controle de segurança.
• Aplique autorização rigorosa, auditoria e proteção CSRF aos endpoints de geração de código.
• Remova a criação arbitrária de tabelas SQL; se necessário, construa instruções fixas a partir de parâmetros estruturados e validados.
• Use uma conta de banco de dados com privilégios mínimos que não possa ler tabelas sensíveis ou realizar operações CTAS/DDL desnecessárias.
• Atualize para uma versão oficial corrigida ou aplique o patch de segurança do fornecedor.

Arquivos

• exp.py - script de verificação / 验证脚本
• exp.png - captura de tela de verificação bem-sucedida / 验证成功截图
• README.md - documentação de vulnerabilidade bilíngue / 中英双语漏洞说明