Una falla crítica en la plataforma de reportes permite a atacantes generar tokens válidos offline y ejecutar código arbitrario en servidores sin autenticación previa.
AJ-Report, una plataforma open-source de visualización de datos y reportes empresariales, arrastra hasta su versión 1.7.1 una vulnerabilidad clasificada como crítica por el National Vulnerability Database que permite a atacantes remotos ejecutar código arbitrario en servidores sin necesidad de credenciales. El problema radica en un secreto JWT hardcodeado en el código fuente que firma los tokens de compartición de reportes, lo que convierte la autenticación en un mecanismo completamente eludible. La vulnerabilidad, identificada como CVE-2026-120209, combina tres errores de diseño en cadena: un secreto criptográfico estático, validación inexistente de tokens y ejecución directa de scripts sin sandbox.
Cómo un secreto compartido convierte la autenticación en teatro de seguridad
El sistema de compartición de reportes de AJ-Report utiliza JSON Web Tokens para autorizar el acceso a visualizaciones sin requerir login completo. El problema es que todas las instalaciones de AJ-Report hasta la versión 1.7.1 firman estos tokens con el mismo secreto JWT embebido en el código fuente del proyecto. Cualquier atacante con acceso al repositorio público puede extraer ese secreto y usarlo para forjar tokens válidos completamente offline, sin necesidad de interactuar con el servidor objetivo ni dejar rastro en logs de autenticación fallida.
La cadena de explotación no termina ahí. Un atacante puede crear un Share-Token con el campo reportCode configurado en el valor especial ‘dataSet’, lo que habilita acceso al endpoint testTransform. Este endpoint está diseñado para probar transformaciones de datos mediante scripts Groovy, pero no valida el origen del token ni restringe las operaciones permitidas. El script recibido se pasa directamente a GroovyClassLoader, un intérprete que ejecuta código Groovy con los mismos privilegios del proceso de la aplicación, sin ningún tipo de sandbox o lista blanca de operaciones.
Por qué esta falla es estructuralmente distinta de un bypass de autenticación común
La mayoría de las vulnerabilidades de autenticación requieren algún tipo de interacción con el sistema objetivo: probar credenciales, explotar una lógica de sesión, forzar un reset de contraseña. CVE-2026-120209 elimina esa fase por completo. El atacante puede generar el token de acceso en su propia máquina, sin enviar una sola petición al servidor hasta el momento de la explotación final. Esto tiene dos implicancias operacionales críticas: primero, no hay forma de detectar intentos de explotación mediante análisis de patrones de autenticación fallida, porque técnicamente no hay autenticación fallida — el token es criptográficamente válido. Segundo, la ventana de explotación no depende de timing ni de condiciones de carrera: el atacante puede preparar el payload con calma y ejecutarlo cuando las condiciones operacionales sean óptimas.
El uso de GroovyClassLoader sin restricciones agrava el impacto. A diferencia de entornos de scripting con capacidades limitadas, Groovy tiene acceso completo a la JVM subyacente, lo que significa que un atacante puede leer archivos del sistema, establecer conexiones de red salientes, cargar bibliotecas nativas o modificar el estado de la aplicación en memoria. En términos prácticos, esto convierte cualquier instancia de AJ-Report expuesta a internet en un punto de entrada completo al entorno donde corre, equivalente a tener acceso SSH sin credenciales.
El patrón de secretos hardcodeados que persiste en proyectos open-source
CVE-2026-120209 no es un caso aislado de negligencia individual — es una manifestación más de un patrón estructural en proyectos open-source que priorizan facilidad de deployment sobre seguridad por defecto. El problema de los secretos hardcodeados aparece típicamente cuando los desarrolladores necesitan que la aplicación funcione «out of the box» sin configuración manual, y eligen embeber valores por defecto en el código en lugar de forzar su generación durante la instalación. La lógica es comprensible desde la perspectiva de experiencia de usuario: una aplicación que requiere configurar secretos criptográficos antes del primer arranque tiene una barrera de entrada más alta. Pero esa conveniencia se convierte en deuda de seguridad permanente cuando esos valores por defecto nunca se documentan como inseguros ni se fuerza su rotación.
El caso de AJ-Report es particularmente problemático porque el secreto JWT no es un valor de configuración visible en un archivo .env o config.yml que un administrador podría revisar — está embebido en el código compilado. Esto significa que incluso organizaciones con prácticas de hardening razonables (cambiar contraseñas por defecto, revisar configuraciones expuestas) pueden haber desplegado instancias vulnerables sin darse cuenta de que el secreto criptográfico central de la aplicación es público. La única forma de detectar el problema es mediante auditoría de código fuente o escaneo específico de la vulnerabilidad, no mediante revisión de configuración post-instalación.
Exposición en América Latina: cuántas instancias están en riesgo y dónde
AJ-Report no es una plataforma con adopción masiva documentada en la región, pero su naturaleza open-source y su enfoque en visualización de datos la hace atractiva para startups tecnológicas, equipos de BI internos y proyectos de gobierno digital que buscan alternativas a soluciones comerciales como Tableau o Power BI. La falta de telemetría pública sobre instalaciones hace imposible cuantificar la exposición exacta, pero el patrón de adopción de herramientas similares en Brasil, México, Argentina y Colombia sugiere que las instancias más probables están en entornos de desarrollo y staging que luego se olvidan expuestos a internet, o en despliegues internos de organizaciones medianas sin equipos de seguridad dedicados.
El riesgo no está tanto en el volumen de instalaciones como en el perfil de los datos que procesan. AJ-Report se usa típicamente para consolidar métricas de negocio, dashboards financieros o reportes de compliance — exactamente el tipo de información que un atacante buscaría después de comprometer un servidor. La combinación de RCE no autenticada más acceso a datos sensibles convierte cada instancia vulnerable en un objetivo de alto valor, incluso si el servidor en sí no tiene otros servicios críticos corriendo. Para organizaciones en sectores regulados (fintech, salud, gobierno), una instancia comprometida de AJ-Report puede ser la puerta de entrada a un incidente de filtración de datos con implicancias de compliance bajo LGPD en Brasil o normativas locales de protección de datos personales.
Nuestro análisis
CVE-2026-120209 es un recordatorio de que la seguridad de aplicaciones open-source no se resuelve únicamente con parches rápidos — requiere cambios en los patrones de diseño que priorizan conveniencia sobre seguridad por defecto. El hecho de que una aplicación llegue a la versión 1.7.1 con un secreto JWT hardcodeado indica que el problema no fue detectado en code review, testing de seguridad ni reportes de usuarios durante múltiples ciclos de release. Esto sugiere una de dos cosas: o el proyecto no tiene procesos de revisión de seguridad establecidos, o esos procesos existen pero no incluyen verificación de secretos criptográficos embebidos. Ambas opciones son problemáticas para cualquier organización que dependa de la plataforma en producción.
La severidad crítica asignada por NVD está justificada no solo por el impacto técnico (RCE completa sin autenticación) sino por la facilidad de explotación. No se requieren condiciones especiales, timing preciso ni conocimiento profundo del sistema objetivo — solo acceso al código fuente público y capacidad de enviar una petición HTTP. Esto coloca la vulnerabilidad en la categoría de «explotación trivial», el tipo de falla que se incorpora a herramientas automatizadas de escaneo y explotación en cuestión de días después de la divulgación pública. Para organizaciones que corren AJ-Report, la ventana entre la publicación del CVE y la explotación activa en internet es medible en horas, no en semanas. ¿Cuántas instancias en la región están corriendo versiones vulnerables sin que sus administradores sepan siquiera que AJ-Report está instalado en su infraestructura?