CVE-2026-26980 permite obter a chave da API administrativa do Ghost CMS por injeção SQL e foi usada para adulterar artigos, carregar scripts externos e direcionar visitantes a falsas verificações CAPTCHA.
| Componente | Ghost CMS, especificamente a Content API e o uso posterior da Admin API por meio da chave administrativa obtida sem autorização. |
| Vetor | Exploração não autenticada de injeção SQL em CVE-2026-26980 para ler dados do banco, recuperar a chave da API administrativa e modificar artigos publicados em massa. |
| Impacto | Mais de 700 sites foram contaminados com carregadores JavaScript usados para ataques ClickFix, falsas verificações CAPTCHA, distribuição de payloads Windows e persistência em endpoints de visitantes. |
| Prioridade | Atualizar o Ghost CMS para versão corrigida, no mínimo 6.19.1 ou posterior, rotacionar credenciais, remover código injetado e revisar logs de acesso e alterações em conteúdo. |
| Versões | A correção foi disponibilizada em fevereiro de 2026 na versão 6.19.1; instâncias não corrigidas ficam no escopo de risco descrito. |
| Artefatos | Carregador JavaScript no rodapé de artigos, iframe de falsa verificação CAPTCHA, uso de serviço de cloaking Adspect, DLL ou payload JavaScript intermediário e executável Windows final. |
| IoCs | Exemplos defangados citados no contexto incluem clo4shara[.]xyz com o caminho 11z77u3[.]php e comunicação periódica com web-telegram[.]ug. |
Uma campanha ativa está explorando CVE-2026-26980, falha crítica de injeção SQL no Ghost CMS, para transformar sites legítimos em pontos de distribuição de ataques ClickFix. A vulnerabilidade afeta a Content API e permite que um atacante não autenticado leia dados arbitrários do banco de dados. O ponto decisivo da cadeia é a obtenção indevida da chave da API administrativa do site, porque essa credencial permite acionar a Admin API e alterar conteúdo publicado no CMS sem passar por um fluxo legítimo de administração.
A correção para a falha foi disponibilizada em fevereiro de 2026 na versão 6.19.1, e a exploração em larga escala foi observada a partir de 7 de maio de 2026. A campanha comprometeu mais de 700 sites em setores variados, incluindo universidades, blockchain, inteligência artificial, SaaS, pesquisa de segurança, mídia e tecnologia financeira. O uso de sites reais aumenta a credibilidade do fluxo de engenharia social: o visitante acessa uma página que pertence a uma organização legítima, mas o artigo foi adulterado para carregar JavaScript malicioso no navegador.
O ataque não depende apenas da vulnerabilidade no servidor. A exploração do Ghost CMS prepara o terreno para uma segunda fase voltada ao visitante. O código injetado adiciona um carregador JavaScript ao fim das páginas afetadas, busca um payload externo em tempo de execução e decide, com base em características do navegador, se deve apresentar uma falsa verificação CAPTCHA. Essa etapa tenta induzir o usuário a executar uma ação local no Windows por meio de um comando codificado; o conteúdo operacional do comando é omitido aqui, mas sua função é atuar como dropper para componentes posteriores.
A cadeia começa no lado do CMS. A injeção SQL em CVE-2026-26980 permite leitura não autorizada de dados do banco por meio da Content API. Com esse acesso, o operador da campanha recupera a chave da API administrativa associada ao site. Essa chave é então usada contra a Admin API para modificar artigos em lote. O resultado observado é a inserção de código JavaScript no rodapé de páginas já publicadas, sem depender de uma conta administrativa válida no fluxo normal de login.
O JavaScript implantado funciona como um carregador em dois estágios. Em vez de embutir todo o comportamento malicioso diretamente no artigo, o script recupera o conteúdo principal a partir de infraestrutura externa, com exemplo defangado em clo4shara[.]xyz e caminho 11z77u3[.]php. Esse desenho reduz a necessidade de alterar novamente todos os sites comprometidos quando o operador decide trocar a lógica de entrega, testar variações ou filtrar vítimas. Para a defesa, isso significa que a simples remoção de um payload visível pode ser insuficiente se o carregador persistir nos artigos.
O componente remoto atua como script de distribuição de tráfego e usa cloaking comercial baseado no Adspect. A lógica coleta informações de fingerprint do navegador, envia essas características ao servidor e recebe instruções para redirecionamentos, janelas, downloads ou execução de JavaScript no contexto do navegador. O objetivo defensivo importante é que scanners, crawlers e ambientes de análise podem receber conteúdo aparentemente benigno, enquanto usuários avaliados como alvos recebem a etapa de falsa verificação CAPTCHA. O contexto também descreve suporte a 19 comandos diferentes para controle do comportamento no navegador, mas não fornece a lista completa como material necessário para reprodução.
Quando o visitante é selecionado, a página contaminada apresenta um iframe com aparência de verificação humana. A etapa ClickFix tenta convencer a vítima a copiar e colar um comando codificado em Base64 na caixa Executar do Windows. Esse comando operacional é omitido, mas sua função descrita é baixar um arquivo ZIP, extrair um script batch e acionar PowerShell para obter uma DLL remota, executada via comando operacional omitido, enquanto uma página falsa é aberta como distração. Em iterações posteriores, a DLL foi substituída por payload JavaScript, mantendo o objetivo de entregar um executável Windows.
Os executáveis finais variam. No fluxo com DLL, o binário entregue é descrito como um cliente PuTTY com certificado de assinatura de código válido. No fluxo via JavaScript, o artefato final é um instalador Inno Setup de uma aplicação Electron. Essa aplicação é uma versão modificada do cliente desktop Grape e busca persistência, além de consultar periodicamente um servidor remoto defangado como web-telegram[.]ug a cada 30 segundos para receber instruções, incluindo execução de JavaScript ou arquivos executáveis.
A superfície primária está em instâncias do Ghost CMS que não receberam a correção de fevereiro de 2026. O componente crítico é a Content API vulnerável, mas a consequência operacional passa pela Admin API, porque a chave administrativa recuperada sem autorização permite adulteração direta de artigos. Sites com grande volume de conteúdo publicado ou com cache distribuído podem ter múltiplas páginas contaminadas ao mesmo tempo, ampliando a exposição para visitantes sem que haja alteração visual evidente no conteúdo editorial.
A campanha afeta também usuários finais que acessam páginas já comprometidas. O risco para o visitante depende da entrega bem-sucedida da etapa ClickFix e da execução manual induzida no Windows. Portanto, o comprometimento do CMS é a condição de distribuição, enquanto a infecção do endpoint exige interação socialmente manipulada. Esse limite é importante: o contexto confirma adulteração de sites e tentativa de entrega de payloads, mas não sustenta afirmar que todos os visitantes foram comprometidos.
- Instâncias do Ghost CMS sem a correção
6.19.1ou posterior aplicada. - Artigos publicados modificados por meio da Admin API após obtenção indevida da chave administrativa.
- Visitantes Windows expostos a falsas verificações CAPTCHA e instruções ClickFix.
- Setores observados incluem universidades, blockchain, inteligência artificial, SaaS, pesquisa de segurança, mídia e fintech.
Equipes que operam Ghost CMS devem revisar logs da Content API e da Admin API em busca de padrões anormais antes e depois de 7 de maio de 2026. A investigação deve priorizar leituras incomuns de dados, chamadas administrativas originadas de endereços ou user agents não associados a operadores legítimos, alterações em massa de posts e modificações próximas no tempo em vários artigos. A presença de JavaScript novo no rodapé de páginas é um sinal direto de contaminação, especialmente quando o código carrega recursos externos em tempo de execução.
No endpoint, a telemetria deve focar na sequência ClickFix descrita: navegador acessando site legítimo, apresentação de falsa verificação CAPTCHA, uso subsequente da caixa Executar do Windows, criação ou extração de arquivo ZIP, execução de script batch, acionamento de PowerShell para download remoto e carregamento de DLL por comando operacional omitido. Como o fluxo pode alternar para payload JavaScript, a defesa não deve depender de uma única extensão ou nome de arquivo. O comportamento de instalação de aplicação Electron modificada, persistência e comunicação periódica com domínio externo também deve entrar na análise.
Na rede, o hunting pode procurar conexões para os indicadores defangados citados, mas com cautela para não limitar a detecção a esses valores. A arquitetura de carregador remoto permite troca de payload e infraestrutura sem alterar necessariamente todos os sites comprometidos. É mais robusto combinar detecção por domínio com classes de comportamento: sites Ghost servindo JavaScript recém-injetado, carregamento de script de distribuição de tráfego, iframe inesperado de CAPTCHA e downloads iniciados após interação com páginas editoriais legítimas.
- Alterações em lote em artigos do Ghost CMS e inserção de scripts no final do conteúdo.
- Chamadas à Admin API usando chave administrativa fora dos padrões operacionais normais.
- Carregamento de JavaScript externo a partir de domínios recém-observados ou não previstos no site.
- Execução de PowerShell, comando operacional omitido, scripts batch e instaladores Inno Setup após navegação em site comprometido.
- Comunicação periódica de aplicação Electron modificada com infraestrutura remota defangada como
web-telegram[.]ug.
A primeira medida é atualizar o Ghost CMS para uma versão corrigida, com 6.19.1 como marco mínimo citado para a correção. Em seguida, a resposta deve tratar a chave da Admin API como comprometida se a instância esteve vulnerável ou se há sinais de alteração indevida. A rotação de credenciais precisa abranger chaves administrativas e demais segredos relacionados ao CMS, porque a vulnerabilidade permite leitura arbitrária de dados do banco e não apenas modificação superficial de conteúdo.
A limpeza deve ir além de remover uma linha de JavaScript visível. É necessário inventariar artigos publicados, páginas estáticas e templates que possam ter sido adulterados, comparar versões em repositórios ou backups confiáveis e invalidar caches que ainda possam servir conteúdo contaminado. Em ambientes com CDN, proxy reverso ou cache de borda, a purga deve ser planejada para evitar que visitantes continuem recebendo páginas antigas com carregadores maliciosos.
A contenção voltada a usuários deve considerar a janela de contaminação. Organizações cujos sites foram afetados devem identificar o período em que o JavaScript esteve presente e notificar usuários potencialmente expostos, com orientação defensiva sobre sinais de execução local induzida, downloads suspeitos e instalação inesperada de aplicações. Para endpoints corporativos, a validação deve incluir histórico de navegador, execução de comandos codificados, criação de scripts temporários, presença de clientes PuTTY inesperados, instaladores Electron não aprovados e conexões repetidas para infraestrutura remota relacionada.
- Aplicar a correção do Ghost CMS e confirmar que a instância está em
6.19.1ou versão posterior. - Rotacionar a chave da Admin API e demais credenciais que possam ter sido lidas do banco de dados.
- Auditar e restaurar artigos adulterados a partir de fonte confiável, removendo carregadores JavaScript injetados.
- Revisar logs de acesso, Content API e Admin API desde a janela anterior a 7 de maio de 2026.
- Invalidar caches e verificar CDN, páginas renderizadas e conteúdo estático servido aos visitantes.
- Investigar endpoints que tenham interagido com falsas verificações CAPTCHA ou apresentado execução de scripts, PowerShell, comando operacional omitido e instaladores não autorizados.
0 Comentários