Uma vulnerabilidade crítica no Ruby on Rails, um dos frameworks mais conhecidos para desenvolvimento de aplicações web, entrou definitivamente no radar dos cibercriminosos. A falha, identificada como CVE-2026-66066 e apelidada de KindaRails2Shell, está sendo explorada ativamente e pode permitir que invasores obtenham informações extremamente sensíveis armazenadas nos servidores.
O problema recebeu pontuação 9,5 de 10 na escala CVSS, colocando a vulnerabilidade entre as de maior severidade. No início de agosto, pesquisadores da VulnCheck identificaram mais de 7.100 instâncias potencialmente vulneráveis do Ruby on Rails expostas diretamente à internet.
A preocupação aumentou depois que ataques começaram a ser observados na prática, aproximadamente um mês após a divulgação das correções.
O que é a KindaRails2Shell?
A vulnerabilidade está relacionada à maneira como determinadas aplicações Rails processam arquivos enviados pelos usuários.
O problema aparece especialmente em aplicações que utilizam o Active Storage com a biblioteca libvips para processamento de imagens e permitem uploads de fontes não confiáveis.
Existe uma diferença na forma como os componentes envolvidos interpretam o tipo do arquivo.
Enquanto uma parte da aplicação pode considerar as informações fornecidas pelo próprio cliente, o libvips analisa os chamados magic bytes para determinar qual formato está realmente sendo processado.
Um atacante pode explorar essa inconsistência criando um arquivo especialmente preparado.
A cadeia passa por diferentes bibliotecas, incluindo libvips, libmatio e HDF5, e pode fazer com que um arquivo existente no servidor seja tratado como parte do conteúdo enviado pelo criminoso.
Hackers podem ler arquivos do servidor
O impacto inicial já é grave.
Um invasor não autenticado pode conseguir acessar arquivos que estejam disponíveis para o processo executado pelo Rails.
Isso pode revelar informações como secret_key_base, master keys, senhas de bancos de dados, credenciais de serviços de armazenamento em nuvem e tokens de APIs.
O problema, portanto, vai muito além da exposição de um arquivo isolado.
Credenciais obtidas dessa maneira podem permitir que os criminosos avancem para outras partes da infraestrutura.
Uma chave de cloud comprometida, por exemplo, pode oferecer acesso a armazenamento, servidores ou outros serviços.
Uma credencial de banco de dados pode permitir acesso a informações internas.
Já determinados segredos utilizados pelo Rails podem ser empregados para falsificar sessões ou outras estruturas assinadas pela aplicação.
Ataque pode evoluir para execução remota de código
É justamente aí que a vulnerabilidade se torna ainda mais perigosa.
A leitura arbitrária de arquivos pode fornecer os segredos necessários para avançar até execução remota de código (RCE).
Nesse cenário, o invasor deixa de apenas consultar informações.
Ele pode alcançar capacidade de executar comandos no ambiente comprometido, dependendo da configuração e das credenciais obtidas.
Isso abre caminho para uma série de ações posteriores: instalação de malware, roubo adicional de credenciais, movimentação lateral pela rede, persistência e comprometimento de outros sistemas conectados.
Mais de 7 mil servidores estavam vulneráveis
O tamanho da superfície de ataque chamou a atenção dos pesquisadores.
No início de agosto, a VulnCheck havia encontrado mais de 7.100 instâncias vulneráveis expostas à internet.
Esse número é especialmente relevante porque vulnerabilidades públicas tendem a ser rapidamente incorporadas a ferramentas automatizadas de exploração.
Um criminoso não precisa escolher manualmente milhares de empresas.
Scanners podem percorrer grandes faixas da internet procurando servidores que apresentem características compatíveis com versões vulneráveis.
Quando um alvo é encontrado, a tentativa de exploração pode acontecer automaticamente.
É justamente esse tipo de cenário que transforma uma vulnerabilidade em risco de ataques em massa.
Exploração já começou
A ameaça deixou de ser apenas teórica.
A VulnCheck detectou tentativas contra seus próprios sistemas de monitoramento localizados em Singapura, Israel e Reino Unido.
A atividade observada foi relacionada a um endereço IP localizado na França, enquanto a infraestrutura utilizada para comando e controle estava associada a um servidor em Israel.
O início dos ataques ocorreu aproximadamente um mês depois da disponibilização das correções para a vulnerabilidade.
Esse intervalo mostra mais uma vez como a janela entre divulgação de uma falha e exploração real pode ser curta.
Depois que detalhes técnicos e códigos de prova de conceito começam a circular, a barreira para exploração diminui significativamente.
Correção também levantou preocupação
Outro ponto chama atenção.
Testes realizados pela VulnCheck em um servidor atualizado para Rails 8.1.3.1 mostraram que a correção bloqueava o vetor utilizado para leitura de arquivos pelo libvips.
Entretanto, os pesquisadores afirmaram que um segundo elemento relacionado à desserialização Marshal ainda poderia levar à execução de código caso o atacante possuísse uma assinatura válida.
Isso não significa que atualizar o Rails seja inútil — pelo contrário, aplicar as correções continua sendo uma medida essencial.
Mas mostra que equipes de segurança precisam considerar também a possibilidade de credenciais e segredos já terem sido comprometidos antes da atualização.
Nesse caso, simplesmente instalar o patch pode não encerrar completamente o risco.
Langflow também está sendo atacado
A investigação revelou ainda uma segunda frente preocupante.
Hackers estão explorando vulnerabilidades críticas no Langflow, plataforma utilizada para desenvolvimento de aplicações e fluxos relacionados à inteligência artificial.
Uma delas é a CVE-2026-0768, classificada com CVSS 9,8.
A falha pode permitir a execução arbitrária de código Python com privilégios elevados.
A VulnCheck registrou inicialmente mais de 50 detecções relacionadas às vulnerabilidades em poucas horas em 30 de agosto. Posteriormente, o número chegou a 360 detecções.
Hackers procuram credenciais de IA e cloud
Os dados buscados pelos invasores ajudam a entender por que plataformas como o Langflow se tornaram alvos atraentes.
Entre as informações procuradas aparecem chaves de API da OpenAI, credenciais AWS, informações de SSH, secrets armazenados pelo Langflow e histórico de comandos Bash.
Isso representa um problema crescente para empresas que estão incorporando inteligência artificial às suas operações.
Ambientes utilizados para desenvolver aplicações de IA frequentemente possuem acesso a diferentes serviços externos.
Uma aplicação pode estar conectada simultaneamente a modelos de IA, bancos de dados, serviços de cloud, APIs corporativas e sistemas internos.
Comprometer esse ambiente pode oferecer ao invasor um verdadeiro mapa de credenciais para avançar pela infraestrutura.
Brasil aparece entre países com instalações vulneráveis
A investigação identificou instalações vulneráveis do Langflow em diferentes regiões.
Entre os países com maior presença dessas instalações aparecem Estados Unidos, Alemanha, Malásia, Brasil e Índia.
Para empresas brasileiras, portanto, o alerta não é apenas internacional.
A popularização de ferramentas para desenvolvimento de IA também amplia a necessidade de inventariar corretamente esses sistemas.
Plataformas criadas rapidamente para testes ou provas de conceito podem acabar conectadas a ambientes de produção e permanecer expostas à internet sem os controles adequados.
Ataques contra Langflow já instalaram malware
Os pesquisadores também documentaram consequências reais de vulnerabilidades anteriores.
Em um incidente envolvendo a CVE-2026-5027, invasores instalaram um coletor de credenciais escrito em Python, agentes de proxy e o software de acesso remoto SimpleHelp.
Em outra campanha, a CVE-2025-3248 foi utilizada para incorporar sistemas comprometidos a uma botnet destinada à mineração da criptomoeda Monero.
Também houve casos em que atacantes desativaram o serviço auditd, utilizado para auditoria em sistemas Linux.
Essa ação reduz a quantidade de registros disponíveis para investigação posterior.
É uma estratégia conhecida: depois de conquistar acesso, o invasor tenta reduzir a visibilidade das ferramentas defensivas antes de avançar.
Vulnerabilidades de aplicações podem virar porta para toda a empresa
O caso do Ruby on Rails mostra um problema maior enfrentado pelas equipes de segurança.
Uma aplicação web aparentemente isolada pode armazenar ou acessar uma enorme quantidade de credenciais.
O servidor pode possuir acesso ao banco de dados.
A aplicação pode utilizar chaves para armazenamento em cloud.
APIs podem depender de tokens.
Sessões podem ser assinadas utilizando secrets armazenados no ambiente.
Assim, uma vulnerabilidade inicialmente classificada como “leitura de arquivos” pode produzir consequências muito maiores.
O invasor procura justamente esses segredos para transformar um acesso limitado em um comprometimento mais amplo.
Aplicações antigas representam risco adicional
Ruby on Rails existe há mais de duas décadas e continua presente em inúmeras aplicações corporativas.
Isso significa que empresas podem possuir sistemas Rails antigos que continuam funcionando normalmente, mas recebem pouca atenção das equipes responsáveis pela infraestrutura.
São os chamados sistemas legados.
O problema aparece quando essas aplicações continuam acessíveis pela internet.
Uma aplicação esquecida pode possuir exatamente o mesmo nível de exposição de um sistema novo — mas sem receber a mesma velocidade de atualização.
Para scanners utilizados por criminosos, não existe diferença.
Se o servidor responde e apresenta uma vulnerabilidade explorável, ele se torna um potencial alvo.
Empresas precisam descobrir o que realmente está exposto
Um dos principais desafios é inventário.
Antes de corrigir uma vulnerabilidade, a organização precisa saber que utiliza aquele software.
Isso parece óbvio, mas grandes empresas podem possuir centenas ou milhares de aplicações distribuídas entre servidores próprios, serviços de cloud, fornecedores e ambientes de desenvolvimento.
Algumas aplicações podem ter sido criadas anos atrás.
Outras surgiram como projetos temporários e acabaram permanecendo em produção.
Sem um inventário atualizado, vulnerabilidades críticas podem permanecer expostas mesmo depois que o fornecedor disponibiliza uma correção.
Atualizar é apenas o primeiro passo
Para organizações que utilizam Ruby on Rails, a recomendação imediata é revisar as versões instaladas e aplicar as correções disponibilizadas para a CVE-2026-66066.
Mas o cenário atual exige medidas adicionais.
Equipes devem analisar logs e procurar possíveis sinais de exploração, especialmente em aplicações que utilizem Active Storage, libvips e upload de imagens provenientes de usuários não confiáveis.
Também é importante avaliar a rotação de segredos e credenciais caso exista qualquer possibilidade de comprometimento.
Isso inclui chaves de aplicação, tokens de API, senhas de banco de dados e credenciais de cloud.
Se uma chave foi roubada antes da atualização, ela pode continuar válida depois do patch.
O tempo entre correção e ataque está diminuindo
O caso KindaRails2Shell reforça uma tendência importante na cibersegurança.
Publicar uma atualização não significa que o problema acabou.
Na realidade, pode significar o início de uma corrida.
De um lado estão administradores tentando atualizar milhares de servidores.
Do outro estão pesquisadores e criminosos analisando exatamente o que mudou no código.
Quando o patch revela onde estava a vulnerabilidade, especialistas podem reconstruir a falha e desenvolver uma prova de conceito.
Criminosos podem então transformar essa informação em ferramentas automatizadas.
Nesse momento, qualquer servidor ainda desatualizado passa a competir contra scanners que funcionam 24 horas por dia procurando exatamente aquele problema.
Com mais de 7 mil instâncias vulneráveis do Ruby on Rails identificadas na internet e exploração já confirmada, a CVE-2026-66066 mostra como essa corrida pode se transformar rapidamente em uma ameaça concreta.
Para as empresas, a lição é clara: vulnerabilidades críticas em aplicações expostas à internet precisam ser tratadas em horas ou dias — não em semanas ou meses.
