Como o Hacktron oferece segurança 24/7 para a Rocket.Chat
- 1 a 2 minutos em média
- para revisar um PR em busca de problemas de segurança
- 17 vulnerabilidades reais
- encontradas e triadas nos primeiros 20 dias
- 73% dos problemas encontrados
- eram acionáveis e foram tratados
“Agora conseguimos escalar a varredura de segurança para todos os nossos PRs.
“O Hacktron sinaliza possíveis problemas, e assim concentramos o esforço de revisão nos pull requests que precisam de mais atenção.”
Julio Araujo
Diretor de segurança
Sobre a Rocket.Chat
A Rocket.Chat é uma plataforma de comunicação de código aberto e totalmente personalizável, usada por equipes de governo, defesa e grandes empresas no mundo todo. A segurança é prioridade máxima para um software dessa escala e porte, e um dos lugares mais baratos para detectar vulnerabilidades de segurança é o início do ciclo de vida de desenvolvimento, com um design melhor e revisões de código contínuas antes que o código chegue à produção.
O desafio: a distância crescente entre a velocidade do código e a revisão de segurança
No entanto, mesmo antes da IA, a proporção entre desenvolvedores e engenheiros de segurança tornava inviável revisar minuciosamente cada PR em busca de vulnerabilidades. Agora que a IA acelera a escrita e a entrega de código, revisar a segurança de cada mudança se tornou mais importante do que nunca.
“Simplesmente não temos engenheiros suficientes para fazer uma revisão minuciosa de cada PR. Ferramentas tradicionais de SAST, SCA e varredura de segredos podem ser muito úteis, e ainda as usamos, mas muitas vezes falta a elas o contexto necessário para identificar problemas complexos, como vulnerabilidades de lógica de negócio.
“Elas também têm dificuldade para raciocinar em várias etapas ou encadear vulnerabilidades para entender como um sistema poderia de fato ser explorado.”
Julio Araujo
Diretor de segurança
Revisão de segurança em escala em cada PR com o Hacktron
Para fechar essa distância, a Rocket.Chat usa o Hacktron Review para revisão contínua de código e de segurança, 24/7, o que ajuda a detectar vulnerabilidades caras antes que cheguem à produção.
Em cada PR, o Hacktron:
- Faz uma revisão de segurança aprofundada das mudanças de código.
- Sinaliza vulnerabilidades diretamente no PR com comentários claros.
- Permite que os desenvolvedores corrijam problemas acionáveis antes do merge.
- Ajuda a equipe de segurança a acompanhar e agrupar achados de menor prioridade para correção periódica.
- Mantém a revisão de segurança contínua, em vez de depender só de auditorias periódicas ou revisões manuais.
“O Hacktron aprende com a nossa base de código e com o nosso feedback ao longo do tempo.
“À medida que damos mais contexto sobre a funcionalidade pretendida, os riscos aceitos e os requisitos de segurança, os falsos positivos ficam menos frequentes, o que melhora a precisão e reduz o tempo gasto na triagem de não problemas.”
Julio Araujo
Diretor de segurança
Vamos analisar as revisões do Hacktron na Rocket.Chat: que tipos de vulnerabilidade ele encontra, qual a precisão desses achados e como ele ajuda a equipe a entregar mais rápido. Nos primeiros 20 dias, ele revisou 155 PRs e revelou problemas reais. Entre eles, um bug crítico de autorização que permitiria a qualquer usuário logado baixar a exportação completa de dados de outro usuário, duas falhas críticas no Apple OAuth que enfraqueciam a barreira de login entre implantações e algumas vulnerabilidades de XSS.
Análise dos achados
Nos primeiros 20 dias (de 5 a 25 de junho de 2026), o Hacktron revisou cada pull request assim que chegava, com 490 varreduras em 10.744 arquivos alterados. Veja abaixo o detalhamento dos PRs revisados, dos problemas encontrados, de como foram triados e da severidade real dos verdadeiros positivos.
Todos os PRs foram revisados automaticamente, e as revisões em si levaram ~1 a 2 minutos em um PR típico (mediana de 1,4 minuto e 5,3 minutos no percentil 95), rápido o bastante para rodar no CI sem atrasar ninguém. Vale observar, porém, que, quando um PR tem muitas mudanças, o Hacktron leva o tempo necessário para testar com rigor.
Que tipos de vulnerabilidade ele encontra?
A pergunta importante é que tipo de vulnerabilidade ele detectou. O Hacktron não é só um verificador de padrões. Ele lê o código e raciocina sobre ele como um pesquisador de segurança. Por isso, os achados cobriram a maior parte do OWASP Top 10: controle de acesso quebrado, bypass de autenticação/2FA, XSS, SSRF/open redirect, falhas criptográficas, exposição de segredos e falhas de lógica de negócio.
Vamos aos detalhes das 3 principais vulnerabilidades que o Hacktron detectou.
Tomada de conta via Apple OAuth
Esta é a primeira vulnerabilidade que o Hacktron encontrou logo depois que a Rocket.Chat o integrou aos seus fluxos de trabalho, e é um bug muito elegante e crítico.
Um detalhe importante é que o Hacktron encontrou um bug fora das mudanças do PR. Isso acontece porque as revisões do Hacktron não se limitam ao diff do PR; ele percorre dependências e efeitos em toda a base de código para encontrar vulnerabilidades de segunda ordem.
Alta
Tomada de conta via e-mail não verificado no login com Apple OAuth
apps/
O handler de login do Apple OAuth em loginHandler.ts tem uma vulnerabilidade: ele confia em um endereço de e-mail fornecido pelo cliente quando o token de identidade da Apple não contém um. Como o campo email fornecido pelo cliente no loginRequest não é verificado criptograficamente, um atacante pode informar um endereço de e-mail arbitrário (por exemplo, o e-mail de uma vítima). O hook accounts_meld.js então usa esse e-mail não verificado para buscar um usuário existente e vincular o ID de serviço Apple do atacante à conta da vítima. Isso permite que o atacante entre na conta da vítima com o próprio Apple ID, o que leva à tomada completa da conta.
Passos para reproduzir
- O atacante inicia um login com a Apple usando o próprio Apple ID e garante que o
identityTokenda Apple não contenha a claimemail(por exemplo, usando um Apple ID que não compartilhou o e-mail, ou em um login posterior em que a Apple omite o e-mail). - O atacante intercepta a requisição de login enviada ao servidor do Rocket.Chat (por exemplo, a chamada ao método DDP
login). - O atacante modifica o payload do
loginRequestpara incluir o endereço de e-mail da vítima no campoemail:{"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}. - O servidor processa a requisição. Em
loginHandler.ts,serviceData.emailestá vazio, então ele atribuiserviceData.email = email(o e-mail da vítima). - O hook
accounts_meld.jsbusca o usuário pelo e-mail da vítima, encontra a conta dela e vincula o Apple ID do atacante a essa conta (Users.setServiceId(user._id, serviceName, serviceData.id)). - Agora o atacante está logado na conta da vítima e pode acessá-la a qualquer momento com o próprio Apple ID.
Em apps/meteor/app/apple/server/loginHandler.ts, o fluxo do Apple Sign-In recorria a um e-mail fornecido pelo cliente quando o JWT da Apple não continha um:
const serviceData = await handleIdentityToken(identityToken);if (!serviceData.email && email) { serviceData.email = email; // attacker-controlled fallback}Um atacante podia forjar um JWT da Apple sem a claim de e-mail e informar um email arbitrário na requisição,
o que permitia se autenticar como qualquer usuário. A Rocket.Chat publicou isso como alerta de severidade Crítica
(GHSA-wx3c-76rf-wpwf, CVE-
O Apple Sign-In pula a validação das claims do JWT
Havia outro bug no mesmo handler: ele verificava a assinatura do JWT, mas pulava a validação das claims.
Ele usava JWS.verify (só a assinatura) em vez de JWS.verifyJWT e nunca verificava aud, exp nem nbf.
Qualquer token assinado pela Apple com um iss não vazio era aceito, então um token vazado ou emitido para outra audiência podia ser reutilizado para entrar como a vítima,
sem prazo de expiração para essa janela de replay. A Rocket.Chat publicou isso como alerta de severidade Alta
(GHSA-c75c-5hc7-j4vp, CVE-
Crítica
Falta de validação da audiência (aud) do JWT no handler de token de identidade da Apple leva à tomada de conta
A função handlePassportIdentityToken em apps/meteor/app/apple/lib/handlePassportIdentityToken.ts faz o parsing e a validação dos tokens de identidade da Apple no fluxo do Apple Sign-In baseado em Passport.js (apps/meteor/app/apple/server/applePassportOAuth.ts). Ela valida corretamente a assinatura criptográfica, o emissor (iss) e a expiração (exp) do token, mas não valida a claim de audiência (aud).
Em fluxos de autenticação baseados em JWT, como o OpenID Connect, a claim aud indica o destinatário pretendido do token (o Client ID). Sem validar se o aud corresponde ao Apple Client ID configurado na instância do Rocket.Chat, a aplicação aceita qualquer token de identidade da Apple válido.
Um atacante pode explorar isso criando a própria aplicação com “Sign in with Apple” ativado. Quando uma vítima entra na aplicação do atacante, o atacante recebe um token de identidade da Apple válido dessa vítima. Em seguida, ele pode enviar esse token ao endpoint de callback do Apple OAuth no servidor do Rocket.Chat. Como o token é de fato assinado pela Apple, tem um emissor válido e não expirou, handlePassportIdentityToken retorna os dados da vítima. A estratégia do Passport acima dele (AppleStrategy em applePassportOAuth.ts) então usa esses dados para autenticar o atacante como a vítima, o que leva à tomada completa da conta.
Observe que outra função, handleIdentityToken em apps/meteor/app/apple/lib/handleIdentityToken.ts, implementa corretamente a validação de audiência, mas handlePassportIdentityToken a omite por completo.
Qualquer usuário podia baixar a exportação de dados de outro usuário
No caminho de download da exportação de dados da GDPR, a verificação de acesso era chamada sem o objeto do arquivo, então caía em fail-open e autorizava qualquer usuário logado. Com um ID de arquivo de exportação válido, um atacante podia obter a exportação completa de dados de outro usuário: mensagens privadas, perfil e dados das salas. Detectado no PR #40889 e corrigido antes do merge.
Crítica
Falha de autorização em nível de objeto (BOLA) em UserDataFiles permite que qualquer usuário autenticado baixe exportações de dados da GDPR
apps/
Existe uma vulnerabilidade de bypass de autorização no mecanismo de controle de acesso de upload de arquivos do Rocket.Chat. Quando um usuário pede para baixar um arquivo da coleção UserDataFiles (que contém exportações de dados da GDPR altamente sensíveis dos usuários, incluindo mensagens privadas, mensagens diretas e dados pessoais), o servidor não valida se o usuário que fez o pedido é o dono da exportação de dados.
O resultado: uma postura de segurança mais forte e menos tempo na triagem de não problemas
Para a Rocket.Chat, o maior impacto é a alavancagem. O Hacktron dá à equipe de segurança uma forma de aplicar revisão especializada de modo consistente em todo o fluxo de desenvolvimento, sem transformar a segurança em um obstáculo para a velocidade da engenharia.
O resultado é um ciclo de feedback mais curto entre engenharia e segurança: as vulnerabilidades são detectadas mais cedo, os desenvolvedores recebem orientações mais claras no momento da mudança e a equipe de segurança passa menos tempo separando ruído e mais tempo nos problemas que realmente importam.