Através de uma análise de segurança abrangente efectuada pela Red Team da OPSWAT, os investigadores de segurança Thai Do e Minh Pham identificaram várias vulnerabilidades que afectam a estrutura Rack Ruby, especificamente CVE-2025-25184, CVE-2025-27111 e CVE-2025-27610.
Este artigo fornece uma visão geral detalhada dessas vulnerabilidades, com um foco particular no CVE-2025-27610. Examina as causas principais, avalia os potenciais impactos e descreve estratégias de mitigação eficazes para proteger as aplicações que dependem da estrutura Rack.
Visão geral do bastidor
O Rack é uma interface modular que liga servidores Web a aplicações Web baseadas em Ruby. Normaliza a interação entre estes componentes, agrupando pedidos e respostas HTTP numa única chamada de método, simplificando o processo de desenvolvimento e promovendo a compatibilidade entre várias estruturas e servidores.
O Rack é utilizado por muitas estruturas e bibliotecas Web Ruby, como o Ruby on Rails e o Sinatra. Está disponível como uma Ruby Gem. A adoção global generalizada do Rack, com mais de mil milhões de downloads em todo o mundo, destaca o seu papel integral no ecossistema de desenvolvimento Ruby. Os componentes de middleware, como o Rack::Static e o Rack::Sendfile, aumentam a eficiência ao lidar com a entrega de conteúdo estático e ao otimizar a transmissão de ficheiros. Devido a esta integração extensiva, as vulnerabilidades descobertas no Rack apresentam implicações de segurança substanciais, afectando potencialmente inúmeras aplicações e sistemas em todo o mundo.
Descoberta de vulnerabilidades de segurança no Rack
Durante a recente investigação de segurança efectuada sobre a estrutura de middleware Rack, os investigadores OPSWAT Thai Do e Minh Pham identificaram várias vulnerabilidades que representam riscos de segurança significativos para as aplicações Web baseadas em Ruby:
- CVE-2025-25184: Thai Do descobriu uma vulnerabilidade que permite aos atacantes efetuar injeção de registo através de caracteres CRLF (Carriage Return Line Feed), manipulando potencialmente entradas de registo.
- CVE-2025-27111: Minh Pham descobriu uma falha de segurança que permite aos atacantes injetar e manipular o conteúdo do registo através de valores de cabeçalho maliciosos.
- CVE-2025-27610: Minh Pham também identificou uma vulnerabilidade Path Traversal, que poderia permitir que os atacantes obtivessem acesso não autorizado a arquivos localizados fora do diretório de arquivos estáticos designado, representando uma ameaça significativa à segurança.
Entre estas vulnerabilidades, a CVE-2025-27610 é particularmente grave, uma vez que pode permitir que atacantes não autenticados recuperem informações sensíveis, incluindo ficheiros de configuração, credenciais e dados confidenciais, conduzindo assim a violações de dados. A esta vulnerabilidade foi atribuída uma pontuação CVSS de 7,5, classificando-a como um risco de alta gravidade.
Rack::Static e Vulnerabilidade de Inclusão de Ficheiros Locais
Entendendo o Rack::Static
O Rack::Static é um middleware essencial em aplicações Rack utilizado principalmente para servir ficheiros estáticos como JavaScript, CSS e imagens de forma eficiente. Ao tirar partido do Rack::Static, os programadores podem integrar facilmente o serviço de conteúdo estático em aplicações Ruby sem necessitarem de confiar na configuração adicional do servidor Web.
Ao configurar o Rack::Static, duas opções essenciais se destacam - :urls e :root. O entendimento e uso apropriado dessas opções simplificam e agilizam significativamente o processo de servir arquivos estáticos.
1. A opção :urls
A opção :urls especifica quais os caminhos URL que a aplicação Rack deve tratar como activos estáticos. Ela é fornecida como um array de strings, cada uma representando um prefixo de caminho que aciona o tratamento de arquivos estáticos.
Por exemplo:
Nesta configuração, os pedidos para /images, /css, ou /js são interceptados e processados pelo Rack::Static. Qualquer ficheiro que corresponda a estes caminhos será servido diretamente a partir do sistema de ficheiros.
2. A opção :root
A opção :root define o diretório base a partir do qual os ficheiros estáticos serão servidos. Este diretório é relativo ao diretório de trabalho atual da sua aplicação Rack.
Dado o exemplo anterior:
Quando é feito um pedido para /assets/logo.png, o Rack::Static tenta servir o ficheiro localizado em public/assets/logo.png.
Exemplo prático
A implementação efectiva do Rack::Static através das opções :urls e :root fornece um método organizado e eficaz para servir conteúdo estático em aplicações web Ruby:
Neste cenário, os pedidos para /assets/* e /favicon.ico serão automaticamente tratados pelo Rack::Static. Todos os ficheiros correspondentes devem existir no diretório public/assets e public/favicon.ico, respetivamente.
CVE-2025-27610 Detalhes técnicos
Durante uma extensa análise de segurança do Rack::Static, Minh Pham descobriu uma vulnerabilidade significativa relacionada ao tratamento inadequado da opção :root. Especificamente, quando o parâmetro :root não é explicitamente definido, o Rack predefine este valor para o diretório de trabalho atual, atribuindo-lhe o valor de Dir.pwd, designando-o implicitamente como o diretório raiz da Web para a aplicação Rack.
Significativamente, o Rack::Static concatena diretamente os caminhos URL de entrada com o diretório :root especificado sem validação ou sanitização suficientes. Consequentemente, se a opção :root estiver indefinida ou mal configurada em relação à opção :urls, um atacante não autenticado pode explorar esta vulnerabilidade através de técnicas de path traversal para aceder a ficheiros sensíveis fora do diretório web pretendido.
A secção seguinte fornece uma análise detalhada do processo de tratamento de pedidos do Rack::Static, ilustrando claramente como esta vulnerabilidade pode ser explorada.
Vulnerabilidade de travessia de caminho e inclusão de arquivo local em Rack::Static
Para obter uma compreensão mais profunda de como o middleware Rack::Static processa as solicitações, Minh Pham conduziu uma análise completa do código-fonte do Rack. Durante a inicialização da classe Rack::Static, ele observou que, se a opção :root não for explicitamente definida, o Rack::Static tem como padrão servir arquivos do diretório de trabalho atual (Dir.pwd). Consequentemente, omitir esta opção resulta no middleware implicitamente usando o diretório a partir do qual a aplicação é executada.
Após a inicialização, foi determinado que quando o Rack::Static recebe um pedido HTTP de entrada, o método de chamada é invocado.
Subsequentemente, o Rack::Static delega a operação de servir ficheiros ao Rack::Files, que tenta localizar e servir o ficheiro com base no caminho construído para o ficheiro derivado do diretório :root configurado e do PATH_INFO fornecido pelo utilizador.
Primeiro, ao invocar os métodos can_serve(path) e overwrite_file_path(path), o middleware examina o env["PATH_INFO"] para determinar se a solicitação de entrada corresponde a algum dos prefixos de URL configurados (por exemplo, /static, /public).
Se a condição for satisfeita, o Rack::Static constrói o caminho do ficheiro combinando o diretório raiz configurado (:root) com o PATH_INFO fornecido pelo utilizador. Essa construção ocorre sem a normalização ou sanitização adequada do caminho de entrada. Especificamente, o middleware concatena diretamente o PATH_INFO da solicitação de entrada com o diretório especificado pela opção :root, introduzindo uma vulnerabilidade devido à validação insuficiente do caminho fornecido
Minh Pham descobriu que, devido à ausência de sanitização ou validação adequadas neste fluxo de trabalho, se o PATH_INFO fornecido pelo utilizador contivesse sequências de passagem de diretórios e a opção :root não estivesse explicitamente definida, o caminho do ficheiro construído poderia ser resolvido para uma localização fora do diretório raiz pretendido, expondo potencialmente ficheiros sensíveis.
CVE-2025-27610 Prova de conceito
Para demonstrar esta vulnerabilidade no Rack::Static, desenvolvemos uma aplicação web baseada em Ruby utilizando a versão 3.1.10 do Rack. Em cenários em que a aplicação não define explicitamente a opção :root, um atacante não autenticado pode explorar esta vulnerabilidade para aceder a dados sensíveis, tais como credenciais, ficheiros de configuração ou ficheiros de bases de dados, levando potencialmente a uma violação significativa dos dados.
Consulte o vídeo seguinte para uma demonstração pormenorizada do impacto significativo associado a esta vulnerabilidade:
Mitigação e orientação
Para mitigar as vulnerabilidades que discutimos acima, certifique-se de que o seu sistema está atualizado com a versão mais recente do Rack.
MetaDefender Core que utiliza o motor SBOM pode detetar esta vulnerabilidade.
OPSWAT MetaDefender CoreO MetaDefender Core, equipado com capacidades avançadas de SBOMSoftware Bill of Materials), permite que as organizações adoptem uma abordagem proactiva na abordagem dos riscos de segurança. Ao analisar as aplicações de software e as suas dependências, MetaDefender Core identifica vulnerabilidades conhecidas, tais como CVE-2025-27610, CVE-2025-27111 e CVE-2025-25184, dentro dos componentes listados. Isto permite às equipas de desenvolvimento e segurança dar prioridade aos esforços de correção, mitigando potenciais riscos de segurança antes que possam ser explorados por agentes maliciosos.
Abaixo está uma captura de ecrã dos CVE-2025-27610, CVE-2025-27111 e CVE-2025-25184, que foram detectados pelo MetaDefender Core com SBOM:
