Compraron un software de inventario de equipos y, de regalo, dieron a los hackers acceso a toda la red: la triste historia del producto SolarWinds.

Compraron un software de inventario de equipos y, de regalo, dieron a los hackers acceso a toda la red: la triste historia del producto SolarWinds.

Web Help Desk sigue siendo vulnerable incluso después de instalar las últimas actualizaciones de seguridad.

Podría parecer que compras «servicio de soporte» para solicitudes y control de equipos, y en el paquete obtienes 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 tickets. Estos sistemas a menudo se exponen al exterior, conectan a muchos empleados y contratistas, y almacenan internamente conversaciones, cuentas de usuario, información sobre equipos y, a veces, contraseñas en los comentarios. Por eso cualquier vulnerabilidad en un producto así se vuelve rápidamente costosa.

La historia de Web Help Desk es complicada. Anteriormente en torno al producto surgieron 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 consideró un bypass de correcciones anteriores.

watchTowr empezaron precisamente intentando reproducir la CVE-2025-26399, pero durante el proceso encontraron su propia cadena. En la cadena hay 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.

La cuestión técnica se basa en 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 introducir un objeto «equivocado» o campos «incorrectos», surge la vía clásica hacia la ejecución de código mediante cadenas en bibliotecas de terceros.

SolarWinds intentó cerrar esas 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 «ajax» y empezaron a buscar cadenas sospechosas como javaClass, rastros de objetos serializados y los nombres de cadenas populares. watchTowr demostraron que esa defensa falla por las diferencias entre los manejadores. El cuerpo de la solicitud se «normaliza» primero con algunas bibliotecas para las comprobaciones, y luego se analiza con otro analizador JSON ya para la lógica real de AjaxProxy. El analizador antiguo entiende escapes del tipo \xNN, que otros componentes no «deshacen». Por eso es posible esconder claves como javaClass o params, pasar la comprobación y, en la etapa siguiente, obtener los valores originales «como se necesita» para la deserialización.

Además, los investigadores describieron una forma de «anular» la comprobación de longitud. La limitación se aplicaba solo si la aplicación reconocía con confianza el cuerpo como JSON válido. Bastaba con añadir una secuencia que, tras una decodificación preliminar, convertía el JSON en inválido, y la comprobación de longitud no se activaba. No obstante, 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 permanecía 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 disfrazar la clave y dejar los parámetros en su lugar. Luego quedaba la cuestión de «con qué» ejecutar el código, porque una de las variantes conocidas se basaba en la biblioteca c3p0, y en la instrucción del parche anterior SolarWinds sugería eliminar c3p0 manualmente de la carga de clases. watchTowr escogieron otro camino: usaron un objeto que, al serializarse, inicia la conexión a la base vía JDBC y luego ejecuta una consulta de comprobación determinada. El PostgreSQL integrado de Web Help Desk, según su descripción, 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 ejecutar comandos mediante la construcción SQL COPY FROM PROGRAM, y en Windows el comando se ejecutaba con privilegios SYSTEM.

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

Para los administradores la conclusión es simple e incómoda. 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 debería considerarse urgente, y después de actualizar conviene comprobar por separado si han quedado servicios y ajustes que abran caminos locales innecesarios, como la base integrada.