Compraron un programa para gestionar equipos y, de paso, entregaron las llaves de toda la red a los hackers: la triste historia de SolarWinds.

Parece que compras un «servicio de soporte» para solicitudes y gestión de equipos, y te llevas casi un acceso remoto listo para atacantes. Los especialistas de watchTowr Labs contaron cómo lograron la ejecución remota de código en SolarWinds Web Help Desk antes del inicio de sesión, aunque probaron una instalación del producto «completamente actualizada».

SolarWinds Web Help Desk se utiliza como una plataforma habitual para solicitudes. Estos sistemas a menudo se exponen al exterior, los usan muchos empleados y contratistas, y acumulan correspondencia, cuentas, información de equipos y a veces contraseñas en comentarios. Por eso cualquier falla en un producto de este tipo se vuelve rápidamente costosa.

El historial de Web Help Desk es problemático. Anteriormente ya aparecieron vulnerabilidades del mismo tipo relacionadas con la deserialización en Java y la posibilidad de ejecutar comandos en el servidor. En 2025 se discutió la CVE-2025-26399, que se interpretó como un bypass de correcciones previas.

watchTowr empezaron precisamente intentando reproducir la CVE-2025-26399, pero en el proceso encontraron su propia cadena. La cadena incluye varias fallas: un bypass de autenticación y una vulnerabilidad de deserialización que conduce a la ejecución de código. Según SolarWinds, se trata al menos de CVE-2025-40552, CVE-2025-40553 y CVE-2025-40554.

El núcleo técnico depende de una pila muy antigua. Web Help Desk está construido sobre Java WebObjects, y en su interior hay un componente AjaxProxy que recibe solicitudes con parámetros y convierte los datos de entrada en objetos Java. Luego el servidor invoca el método indicado y devuelve el resultado. Si se logra suministrar un objeto «incorrecto» o campos «equivocados», aparece la vía clásica hacia la ejecución de código mediante cadenas en bibliotecas de terceros.

SolarWinds intentó cerrar estas fallas con filtros. Por ejemplo, en una de las correcciones añadieron una comprobación del cuerpo de la solicitud: limitaron el tamaño para las solicitudes a «ajax» y empezaron a buscar cadenas sospechosas como javaClass, rastros de objetos serializados y nombres de cadenas populares. watchTowr demostraron que esa protección se rompe por las diferencias entre los manejadores. El cuerpo de la solicitud primero se «normaliza» con unas bibliotecas para las comprobaciones, y luego lo procesa otro analizador JSON ya para la lógica real de AjaxProxy. El analizador antiguo entiende el escape del tipo \xNN, que otros componentes no «expanden». Por eso se pueden ocultar claves como javaClass o params, pasar la comprobación y en la etapa siguiente obtener los valores originales «como es debido» para la deserialización.

Por separado, los investigadores describieron una forma de «anular» la comprobación de longitud. La limitación se activaba solo si la aplicación reconocía con certeza el cuerpo como un JSON correcto. Bastaba añadir una secuencia que, tras una decodificación previa, convertía el JSON en inválido, y la comprobación de longitud no se disparaba. Sin embargo, en el camino hacia la deserialización la aplicación volvía a leer el cuerpo de la solicitud en forma «cruda», donde el JSON seguía siendo válido.

Incluso después de que SolarWinds empezara a «eliminar» el campo params en la etapa de saneamiento de la solicitud, el truco con \xNN permitía enmascarar la clave y dejar los parámetros en su lugar. Quedaba la pregunta de «con qué» ejecutar el código, porque una de las opciones conocidas dependía de la biblioteca c3p0, y en la nota del arreglo anterior SolarWinds sugería eliminar c3p0 manualmente de la carga de clases. watchTowr eligieron otro camino: usaron un objeto que al serializarse inicia una conexión a la base vía JDBC y luego ejecuta una consulta de verificación especificada. Según su descripción, el PostgreSQL integrado en Web Help Desk sigue funcionando localmente incluso al elegir una base externa, y las reglas de acceso permiten conexiones locales sin contraseña. Como resultado, los investigadores llegaron a la ejecución de comandos mediante la construcción SQL COPY FROM PROGRAM, y en Windows el comando se ejecutaba con privilegios SYSTEM.

De forma pública SolarWinds publicó un boletín y correcciones el 28 de enero de 2026, y en la documentación figura la versión Web Help Desk 2026.1, que cierra tanto los bypass de autenticación como las cadenas hacia la ejecución remota de código.

Para los administradores la conclusión es simple y desagradable. Web Help Desk volvió a confirmar la reputación de un producto donde «parche sobre parche» no resiste, especialmente cuando la base es una plataforma obsoleta con componentes exóticos de análisis de datos. Si Web Help Desk está accesible desde internet, actualizar a la versión con correcciones debe considerarse urgente, y tras la actualización conviene comprobar por separado si no quedan servicios o ajustes que abran rutas locales innecesarias, como la base de datos integrada.