Mi Primer CVE: CVE-2025-64708
Cómo encontré un bug de seguridad en mi propio laburo
Trabajo como desarrollador en authentik, un Identity Provider open-source muy utilizado. Y bueno, resulta que encontré una vulnerabilidad que terminó siendo mi primer CVE: CVE-2025-64708.
¿Qué es un CVE?
CVE (Common Vulnerabilities and Exposures) es un sistema estándar para identificar y catalogar vulnerabilidades de seguridad. Cada vulnerabilidad recibe un identificador único (como CVE-2025-64708) que permite a investigadores, desarrolladores y administradores de sistemas hablar del mismo problema sin ambigüedades. Cuando una vulnerabilidad recibe un CVE, queda registrada en bases de datos públicas como la del NIST, lo que facilita el seguimiento y la coordinación de parches a nivel global.
Que una organización publique un CVE no es algo malo, al contrario, es señal de transparencia en su proceso de seguridad. Significa que la organización tiene mecanismos para identificar y corregir vulnerabilidades de forma responsable, en lugar de esconderlas. Las empresas que nunca publican CVEs no necesariamente tienen software más seguro; muchas veces simplemente no tienen un proceso de disclosure o prefieren no ser transparentes.
¿Qué pasaba?
El tema era con las invitaciones expiradas. En versiones anteriores, las invitaciones se consideraban válidas aunque ya hayan vencido. El sistema dependía de tareas en segundo plano para limpiar las invitaciones viejas.
En un escenario normal, esto podía tardar hasta 5 minutos porque la limpieza estaba programada para correr cada 5 minutos. Pero si había muchas tareas en la cola, podía tardar más todavía.
O sea que alguien con un link de invitación vencido podía usarlo durante esa ventana de tiempo. Aunque sea poco probable que se explote esa vulnerabilidad, dadas las condiciones que se deben dar, no está bien que se pueda.
Los datos técnicos
- CVE ID: CVE-2025-64708
- CVSS Score: 5.3 - 5.8 (MEDIUM)
- CWE: CWE-613 (Insufficient Session Expiration)
- Vector: Red, sin autenticación requerida
El fix
Como trabajo en el proyecto, pude coordinar directamente con el equipo. La solución salió en las versiones:
- 2025.8.5
- 2025.10.2
El commit: 6672e6a
Para los que no pueden actualizar todavía, hay un workaround con un expression policy:
return not context['flow_plan'].context['invitation'].is_expired
Cómo maneja authentik la seguridad
authentik se toma la seguridad muy en serio y sigue las reglas de responsible disclosure. El proceso es bastante claro:
- Se reporta la vulnerabilidad por email a [email protected] o a través del portal de advisories de GitHub.
- El equipo de seguridad intenta reproducir el problema y pide más información si es necesario.
- Se asigna un nivel de severidad usando el calculador CVSS de NVD.
- Se crea un fix y si es posible, el reporter lo testea.
- El fix se backportea a otras versiones soportadas y se crea un workaround si es posible.
- Se envía un anuncio con la fecha de release y el nivel de severidad al menos 24 horas antes del release (normalmente se da más tiempo para que los usuarios puedan planificar la actualización).
- Se publica la versión corregida.
Aunque no hay bounties monetarios, authentik reconoce a los investigadores publicando una entrada en la página de Security Advisory con el nombre o alias del reporter.
Lo que aprendí
Conseguir mi primer CVE fue una experiencia muy buena. Algunas cosas que rescato:
- Las vulnerabilidades no siempre son rebuscadas: A veces son problemas de timing como este, nada del otro mundo.
- Estar adentro del proyecto ayuda: Conocer el código te permite ver cosas que de afuera capaz no notás.
- El proceso de disclosure es importante: Aunque sea tu propio proyecto, hay que seguir el proceso correcto para que los usuarios tengan tiempo de actualizar.
Referencias
