Cómo Hacktron ofrece seguridad 24/7 a Rocket.Chat
- 1-2 minutos de media
- para revisar la seguridad de un PR
- 17 vulnerabilidades reales
- encontradas y clasificadas en los primeros 20 días
- 73 % de los problemas encontrados
- eran accionables y se resolvieron
«Ahora podemos escalar el escaneo de seguridad a todos nuestros PR.
«Hacktron señala los posibles problemas y nos permite centrar el esfuerzo de revisión en los pull requests que necesitan más atención.»
Julio Araujo
Director de seguridad
Sobre Rocket.Chat
Rocket.Chat es una plataforma de comunicaciones de código abierto y totalmente personalizable que usan equipos gubernamentales, de defensa y de empresa de todo el mundo. La seguridad es una prioridad máxima para un software de esta escala y tamaño, y uno de los momentos más baratos para detectar vulnerabilidades es al principio del ciclo de vida del desarrollo de software, con un mejor diseño y revisiones de código continuas antes de que el código llegue a producción.
El reto: una brecha creciente entre la velocidad del código y la revisión de seguridad
Sin embargo, incluso antes de la IA, la proporción entre desarrolladores e ingenieros de seguridad hacía inviable revisar minuciosamente cada PR en busca de vulnerabilidades. Ahora que la IA acelera la rapidez con la que se escribe y se publica el código, revisar la seguridad de cada cambio es más importante que nunca.
«Sencillamente no tenemos suficientes ingenieros para revisar a fondo cada PR. Las herramientas tradicionales de SAST, SCA y escaneo de secretos pueden ser muy útiles, y las seguimos usando, pero a menudo les falta el contexto necesario para identificar problemas complejos como las vulnerabilidades de lógica de negocio.
«También les cuesta razonar a lo largo de varios pasos o encadenar vulnerabilidades para entender cómo se podría explotar realmente un sistema.»
Julio Araujo
Director de seguridad
Escalar la revisión de seguridad a cada PR con Hacktron
Para cerrar esa brecha, Rocket.Chat usa Hacktron Review para una revisión de código y de seguridad continua, 24/7, que ayuda a detectar vulnerabilidades costosas antes de que lleguen a producción.
En cada PR, Hacktron:
- Hace una revisión de seguridad a fondo de los cambios de código.
- Señala las vulnerabilidades directamente en el PR con comentarios claros.
- Permite a los desarrolladores corregir los problemas accionables antes del merge.
- Ayuda al equipo de seguridad a hacer seguimiento de los hallazgos de menor prioridad y a agruparlos para corregirlos periódicamente.
- Mantiene la revisión de seguridad de forma continua, en lugar de depender solo de auditorías periódicas o revisiones manuales.
«Hacktron aprende de nuestro código y de nuestro feedback con el tiempo.
«A medida que damos más contexto sobre la funcionalidad prevista, los riesgos aceptados y los requisitos de seguridad, los falsos positivos son menos frecuentes, lo que mejora la precisión y reduce el tiempo dedicado a clasificar problemas que no lo son.»
Julio Araujo
Director de seguridad
Veamos un análisis de las revisiones de Hacktron en Rocket.Chat: qué tipos de vulnerabilidades encuentra, qué precisión tienen esos hallazgos y cómo ayuda al equipo a publicar más rápido. En los primeros 20 días revisó 155 PR y sacó a la luz problemas reales. Entre ellos, un bug de autorización crítico que habría permitido a cualquier usuario con sesión iniciada descargar la exportación completa de datos de otro usuario, dos fallos críticos de Apple OAuth que debilitaban la frontera del inicio de sesión en todos los despliegues y unas cuantas vulnerabilidades XSS.
Análisis de los hallazgos
En los primeros 20 días (del 5 al 25 de junio de 2026), Hacktron revisó cada pull request a medida que llegaba y ejecutó 490 escaneos sobre 10 744 archivos modificados. Este es el desglose de los PR revisados, los problemas encontrados, cómo se clasificaron y la severidad efectiva de los positivos reales.
Cada PR se revisó automáticamente, y las revisiones tardaron entre 1 y 2 minutos en un PR típico (una mediana de 1,4 minutos y 5,3 minutos en el percentil 95), lo bastante rápido para estar en la CI sin frenar a nadie. Aun así, conviene tener en cuenta que, si un PR tiene muchos cambios, Hacktron se toma su tiempo para ser exhaustivo en sus pruebas.
¿Qué tipos de vulnerabilidades encuentra?
Ahora viene la pregunta importante: qué tipo de vulnerabilidades detectó. Hacktron no es un simple buscador de patrones. Lee el código y razona sobre él igual que un investigador de seguridad. Por eso los hallazgos abarcaron la mayor parte del OWASP Top 10: control de acceso roto, evasiones de autenticación y de 2FA, XSS, SSRF y open redirect, fallos criptográficos, exposición de secretos y fallos de lógica de negocio.
Veamos en detalle las 3 vulnerabilidades principales que detectó Hacktron.
Toma de control de cuentas mediante Apple OAuth
Es la primera vulnerabilidad que Hacktron encontró justo después de que Rocket.Chat lo integrara en sus flujos de trabajo, y es un bug muy elegante y crítico.
Un detalle importante es que Hacktron encontró un bug fuera de los cambios del PR. El motivo es que las revisiones de Hacktron no se limitan estrictamente al diff del PR. Recorren las dependencias y los efectos en todo el código para encontrar vulnerabilidades de segundo orden.
Alta
Toma de control de cuentas mediante un correo no verificado en el inicio de sesión con Apple OAuth
apps/
El handler de inicio de sesión de Apple OAuth en loginHandler.ts tiene una vulnerabilidad: confía en una dirección de correo proporcionada por el cliente si el token de identidad de Apple no contiene ninguna. Como el campo email que proporciona el cliente en loginRequest no está verificado criptográficamente, un atacante puede indicar una dirección de correo arbitraria (por ejemplo, la de la víctima). El hook accounts_meld.js usará entonces ese correo no verificado para buscar un usuario existente y vincular el ID de servicio de Apple del atacante a la cuenta de la víctima. Así, el atacante puede iniciar sesión en la cuenta de la víctima con su propio Apple ID, lo que supone una toma de control total de la cuenta.
Pasos para reproducirlo
- El atacante inicia sesión con Apple usando su propio Apple ID y se asegura de que el
identityTokende Apple no contenga un claimemail(por ejemplo, con un Apple ID que no ha compartido su correo, o en un inicio de sesión posterior en el que Apple omite el correo). - El atacante intercepta la petición de inicio de sesión que se envía al servidor de Rocket.Chat (por ejemplo, la llamada al método DDP
login). - El atacante modifica el payload de
loginRequestpara incluir el correo de la víctima en el campoemail:{"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}. - El servidor procesa la petición. En
loginHandler.ts,serviceData.emailestá vacío, así que asignaserviceData.email = email(el correo de la víctima). - El hook
accounts_meld.jsbusca al usuario por el correo de la víctima, encuentra su cuenta y le vincula el Apple ID del atacante (Users.setServiceId(user._id, serviceName, serviceData.id)). - El atacante ha iniciado sesión en la cuenta de la víctima y puede acceder a ella en cualquier momento con su Apple ID.
En apps/meteor/app/apple/server/loginHandler.ts, el flujo de inicio de sesión con Apple recurría a un correo proporcionado por el cliente cuando el JWT de Apple no lo incluía:
const serviceData = await handleIdentityToken(identityToken);if (!serviceData.email && email) { serviceData.email = email; // attacker-controlled fallback}Un atacante podía falsificar un JWT de Apple sin el claim de correo e indicar un email arbitrario en la petición,
lo que le permitía autenticarse como cualquier usuario. Rocket.Chat lo publicó como aviso de severidad crítica
(GHSA-wx3c-76rf-wpwf, CVE-
El inicio de sesión con Apple omite la validación de los claims del JWT
Había otro bug en el mismo handler: verificaba la firma del JWT pero omitía la validación de los claims.
Usaba JWS.verify (solo la firma) en lugar de JWS.verifyJWT, y nunca comprobaba aud, exp ni nbf.
Se aceptaba cualquier token firmado por Apple con un iss no vacío, así que un token filtrado o emitido para otra audiencia podía reutilizarse para iniciar sesión como la víctima,
sin que la ventana de reutilización caducara nunca. Rocket.Chat lo publicó como aviso de severidad alta
(GHSA-c75c-5hc7-j4vp, CVE-
Crítica
Falta la validación de la audiencia (aud) del JWT en el handler del token de identidad de Apple, lo que permite tomar el control de cuentas
La función handlePassportIdentityToken de apps/meteor/app/apple/lib/handlePassportIdentityToken.ts se encarga de analizar y validar los tokens de identidad de Apple durante el flujo de inicio de sesión con Apple basado en Passport.js (apps/meteor/app/apple/server/applePassportOAuth.ts). Aunque valida correctamente la firma criptográfica del token, el emisor (iss) y la caducidad (exp), no valida el claim de audiencia (aud).
En flujos de autenticación basados en JWT como OpenID Connect, el claim aud indica el destinatario previsto del token (el Client ID). Si no se valida que aud coincide con el Apple Client ID configurado en la instancia de Rocket.Chat, la aplicación aceptará cualquier token de identidad de Apple válido.
Un atacante puede explotarlo creando su propia aplicación con «Iniciar sesión con Apple» activado. Cuando una víctima inicia sesión en la aplicación del atacante, este recibe un token de identidad de Apple válido para esa víctima. Después, el atacante puede enviar ese token al endpoint de callback de Apple OAuth del servidor de Rocket.Chat. Como el token está firmado de verdad por Apple, tiene un emisor válido y no ha caducado, handlePassportIdentityToken devolverá los datos de la víctima. La estrategia de Passport que la llama (AppleStrategy en applePassportOAuth.ts) usa entonces esos datos para iniciar la sesión del atacante como la víctima, lo que supone una toma de control total de la cuenta.
Ten en cuenta que otra función, handleIdentityToken en apps/meteor/app/apple/lib/handleIdentityToken.ts, sí implementa correctamente la validación de la audiencia, pero handlePassportIdentityToken la omite por completo.
Cualquier usuario podía descargar la exportación de datos de otro usuario
En la ruta de descarga de exportaciones de datos del RGPD, la comprobación de acceso se llamaba sin el objeto del archivo, así que fallaba en abierto y autorizaba a cualquier usuario con sesión iniciada. Con un ID de archivo de exportación válido, un atacante podía obtener la exportación completa de datos de otro usuario: mensajes privados, perfil y datos de salas. Detectado en el PR #40889 y corregido antes del merge.
Crítica
Autorización rota a nivel de objeto (BOLA) en UserDataFiles, que permite a cualquier usuario autenticado descargar exportaciones de datos del RGPD
apps/
Existe una vulnerabilidad de evasión de autorización en el mecanismo de control de acceso a la subida de archivos de Rocket.Chat. Cuando un usuario solicita descargar un archivo de la colección UserDataFiles (que contiene exportaciones de datos del RGPD de los usuarios, muy sensibles, con mensajes privados, mensajes directos y datos personales), el servidor no valida si el usuario que hace la petición es el propietario de la exportación de datos.
El resultado: una postura de seguridad más sólida y menos tiempo clasificando problemas que no lo son
Para Rocket.Chat, el mayor impacto es el efecto multiplicador. Hacktron da al equipo de seguridad una forma de aplicar una revisión experta de manera coherente en todo el flujo de desarrollo, sin convertir la seguridad en un freno para la velocidad de ingeniería.
El resultado es un ciclo de feedback más corto entre ingeniería y seguridad: las vulnerabilidades se detectan antes, los desarrolladores reciben indicaciones más claras en el momento del cambio y el equipo de seguridad dedica menos tiempo a filtrar ruido y más a los problemas que de verdad importan.