Alerta de seguridad
Nivel de peligrosidad: Crítico
Descripción.
CVE-2025-62368 es una vulnerabilidad de ejecución remota de código (RCE) en el componente taiga-back del gestor de proyectos Taiga. La falla es debida a deserialización insegura de datos no confiables en la API y fue divulgada públicamente; permite a un atacante autenticado enviar datos manipulados que se deserializan y ejecutar código arbitrario en el servidor afectado, recientemente se ha dado a conocer un código de exploit público.
Recursos afectados.
Vulnerabilidad clasificada como CRÍTICA (CVSS v3.1: 9.0 - 9.1 según CNA). Permite ejecución remota de código con impacto alto en confidencialidad, integridad y disponibilidad. Existe código de exploit público (módulo Metasploit que facilita la explotación). Esto reduce la barrera de explotación para atacantes con acceso a credenciales o cuentas con privilegios bajos afectando lo siguientes recursos:
- Producto: taiga-back (Taiga API).
- Versiones vulnerables: <= 6.8.3.
Solución | Mitigación.
Aplicar el parche oficial inmediatamente actualizando taiga-back a 6.9.0+ o al paquete oficial que incluya la corrección. Priorizar esta acción para sistemas expuestos. Después del parche, realizar un análisis post-patch completo (ver sección "Revisión recomendada" y "Análisis post-patch").
Revisar y endurecer control de acceso a la API (autenticación fuerte, menores privilegios).
- Corregido en: 6.9.0.
En caso de imposibilidad de actualización inmediata se puede mitigar temporalmente:
- Restringir el acceso a la API (colocar un WAF, bloquear acceso desde Internet, permitir sólo rangos IP internos o VPN).
- Aplicar reglas WAF que filtren cargas con patrones de deserialización sospechosa (ej.: presencia de cadenas relacionadas con pickle, __reduce__, __setstate__, eval(, os.system, etc.) en cuerpos POST.
- Deshabilitar endpoints no necesarios de la API hasta aplicar parche.
- Reforzar autenticación (MFA, rotación de credenciales) y revisar sesiones activas.
- Si la aplicación corre con permisos elevados, bajar privilegios del proceso (usuario sin permisos administrativos).
- Habilitar y priorizar alertas de detección sobre comportamientos inusuales (nuevos procesos, conexiones salientes, cambios en archivos Python).
Indicadores de compromiso (IoCs).
- Peticiones HTTP POST/PUT a endpoints de la API con cargas que contengan cadenas sospechosas: pickle, __reduce__, __setstate__, __reduce_ex__, eval(...), os.system, subprocess, import os, import subprocess.
- Creación/ejecución de procesos inesperados (shells, netcat, Python reverse shells) por el usuario que corre taiga-back.
- Conexiones salientes inusuales desde el host afectado hacia hosts externos en puertos no habituales.
- Archivos o módulos Python nuevos o modificados en el directorio de la aplicación, virtualenv o site-packages.
- Cuentas administrativas nuevas o cambios en permisos dentro de la aplicación Taiga (usuarios con rol admin no autorizados).
- Persistencia: entradas nuevas en cron, systemd unit files no reconocidos, ficheros en /etc/cron.*, /var/spool/cron, o en ~/.config del usuario de la app.
- Registros de la aplicación mostrando excepciones atípicas relacionadas con deserialización o fallos en carga de objetos.
Recomendaciones.
Actualizar a 6.9.0 o cualquier versión posterior estable publicada por el proyecto Taiga. Si su despliegue usa ramas LTS o empaquetados por terceros (Docker images, distros con backports), verificar la equivalencia de la corrección con el mantenedor/paquete y asegurarse de que contenga el cambio que corrige la deserialización insegura.
- Aplicar el parche oficial de manera prioritaria. Actualizar taiga-back a 6.9.0+ en todos los entornos.
- Aislar temporalmente el dispositivo o servicio si se sospecha compromiso.
- Revisar todas las cuentas administrativas de Taiga y del sistema; forzar cambio de contraseñas y eliminar accesos no autorizados; habilitar MFA donde sea posible.
- Incluir la vulnerabilidad en el plan de gestión de riesgos y en el monitoreo continuo de infraestructuras críticas.
- Revisar configuraciones de desarrollo: evitar usar pickle o mecanismos inseguros; revisar librerías que realicen deserialización y aplicar validación estricta o usar formatos seguros (JSON con esquemas, serializers seguros).
Análisis a confirmar (Post-Patch).
- Que no existan procesos persistentes maliciosos ni puertas traseras (reverse shells o cronjobs).
- Que no existan cuentas administrativas nuevas ni SSH keys introducidas recientemente.
- Que los ficheros de la aplicación y librerías no hayan sido alterados (comparar con backup o paquete oficial).
- Que no existan cargas de trabajo o conexiones salientes sospechosas posteriores al parche.
- Revisión de backups y restauración desde puntos antes de la posible intrusión si es necesario.