Un ataque de secuestro de BGP redirigió el tráfico de actualizaciones de Softaculous y Virtualizor hacia un servidor controlado por el atacante entre el 28 y el 30 de agosto de 2026, lo que permitió que unos paquetes maliciosos de Virtualizor llegaran a unas cuantas instalaciones. La breve lección que podemos extraer es inquietante: el protocolo HTTPS solo puede garantizar que te estás comunicando con un dominio si el enrutamiento y la emisión de certificados no han sido manipulados previamente. Los sistemas de actualización necesitan que los paquetes firmados, los controles de enrutamiento y las defensas de los repositorios funcionen de forma conjunta.
¿Qué ocurrió en el ataque de secuestro de BGP contra Softaculous?
El incidente se centró en 162.55.80.0/24, un rango de direcciones IP alojado por Hetzner y utilizado por la infraestructura de Softaculous, incluidos el punto final de actualizaciones de Virtualizor y los sistemas de clientes y facturación de Softaculous. Según Virtualizor y Softaculous, se produjo un anuncio de ruta no autorizado alrededor de las 20:57 UTC del 28 de agosto de 2026, y el enrutamiento normal se restableció a nivel mundial alrededor de las 06:10 UTC del 30 de agosto.
El anuncio no autorizado afectó a AS62390, NexonHost, y al proveedor de tránsito AS6204, Zet.net. El origen legítimo era AS24940, Hetzner. Dado que la ruta secuestrada era una /24, resultaba más específica que la ruta más amplia de Hetzner, 162.55.0.0/16, por lo que muchas redes prefirieron la ruta controlada por el atacante, de acuerdo con la regla de coincidencia de prefijo más largo de Internet.
Suena complicado. Pero no lo es. Si tu servidor solicitara una actualización de Virtualizor durante los periodos de desvío, algunas partes de Internet podrían enviar esa solicitud a un lugar equivocado, aunque el nombre de host siguiera pareciendo correcto.
BleepingComputer informó el 1 de septiembre de 2026 de que, durante el incidente, se distribuyeron paquetes de actualización maliciosos de Virtualizor. Virtualizor y Softaculous calificaron el grupo afectado de reducido, ya que solo quedaron expuestas aquellas instalaciones que comprobaron si había actualizaciones durante el ataque y recibieron respuestas maliciosas.
La cronología, con las cifras que importan
El informe de incidentes de Virtualizor del 31 de agosto de 2026 dividió el suceso en dos oleadas activas. La primera se prolongó desde aproximadamente las 21:00 UTC del 28 de agosto hasta las 08:50 UTC del 29 de agosto. La segunda se prolongó desde aproximadamente las 20:00 UTC del 29 de agosto hasta las 06:00 UTC del 30 de agosto, y los atacantes se retiraron aproximadamente a las 06:10 UTC.
Un cálculo útil: el periodo total del incidente duró aproximadamente 33 horas, pero las dos oleadas activas principales suman unas 21 horas y 50 minutos. Eso supone alrededor de dos tercios de dicho periodo. Para los responsables de la seguridad, esa distinción es importante porque una simple marca de tiempo que indique «el incidente duró 33 horas» puede exagerar la exposición continua y, al mismo tiempo, subestimar el problema operativo: las comprobaciones de actualizaciones son automáticas, dispersas y fáciles de pasar por alto.
| Evento de 2026 | Detalles comunicados | Por qué importaba |
|---|---|---|
| 28 de agosto, ~20:57 UTC | AS62390 comenzó a anunciar 162.55.80.0/24 | El tráfico hacia los servicios de Softaculous afectados podría ser desviado |
| 29 de agosto, ~08:00–08:50 UTC | Virtualizor afirma que la interceptación activa ha sido confirmada de forma independiente | Un servidor redirigido respondió para los dominios de Softaculous con un certificado válido |
| 29 de agosto, ~08:50 UTC | Hetzner comenzó a anunciar directamente la subred 162.55.80.0/24 | Según Virtualizor, la desviación se redujo a cero en cuestión de minutos. |
| 30 de agosto, ~06:10 UTC | Ruta no autorizada retirada | Se ha restablecido el enrutamiento global normal |
| 1 de septiembre de 2026 | Lanzamiento de Virtualizor 3.2.9, parche 9 | Se ha añadido el «Analizador de seguridad» al panel de administración |
Virtualizor informó de que había medido el evento con 368 pares recopiladores de RIPE RIS. Según sus cifras, procedentes de una única fuente, 368 de los 368 pares transportaron la ruta secuestrada en algún momento, con un pico registrado cerca de 100% de puntos de observación que transportaban la ruta durante los periodos activos, una mediana de 266 pares y aproximadamente 10 600 retiradas de rutas durante ese intervalo.
Utiliza esas mediciones con precaución. Los pares de RIPE RIS son puntos de observación, no un censo de todos los servidores afectados. Aun así, demuestran que la fuga de rutas no fue una pequeña anomalía local. Se propagó lo suficiente como para que el tráfico habitual de actualizaciones de software se convirtiera en un canal de distribución.
¿Por qué TLS no salvó el canal de actualización?
Un error muy común es pensar que el protocolo HTTPS pone fin a este tipo de situaciones. En el caso de Softaculous, al parecer el atacante obtuvo certificados TLS técnicamente válidos durante el secuestro, ya que el tráfico de validación de certificados también se redirigió al servidor del atacante. Virtualizor afirmó que el certificado abarcaba dominios como virtualizor.com, api.virtualizor.com y files.virtualizor.com.
El protocolo TLS protege la sesión de transporte: la conexión está cifrada y el certificado vincula un nombre a una clave dentro del sistema de la autoridad de certificación. Pero si el proceso que acredita el control del dominio es engañado a su vez por un desvío temporal del enrutamiento, es posible que el navegador o el cliente de actualización no detecte ningún error de certificado. Candado en orden. Destino incorrecto.
Ars Technica informó en septiembre de 2026 que Let’s Encrypt había señalado que la vinculación de cuentas mediante CAA habría hecho que la emisión de certificados resultara «mucho más difícil» para el atacante. Se trata de una medida de mitigación significativa, no de un escudo mágico. Los controles de certificados reducen la probabilidad de que se produzcan emisiones fraudulentas; no verifican que la carga útil del software sea la que el proveedor tenía previsto distribuir.
El inconveniente que muchos análisis retrospectivos pasan por alto: la supervisión de certificados a posteriori puede indicar que existía un certificado sospechoso, pero es posible que no revele qué clientes automatizados confiaron en él durante un intervalo de 20 minutos o dos horas de un evento de enrutamiento. Para entonces, es posible que tu programa de actualización ya se haya ejecutado como root.
La firma de paquetes es el elemento que le faltaba a Virtualizor
Virtualizor afirmó que los clientes de actualización de su producto aún no verificaban criptográficamente los paquetes de actualización. Eso significa que un paquete modificado no habría sido rechazado por motivos relacionados con la firma del paquete una vez que el cliente hubiera aceptado el punto final HTTPS. Sinceramente, en el caso del software de gestión de servidores, esa falta de seguridad es lo que debería hacer que los administradores se preocupen.
A proper update design makes the client verify the payload independently from the connection. The client checks a vendor signature, a trusted signing key, signed metadata, or a pinned hash before installing. If the mirror, CDN, DNS path, or BGP route lies, the package still fails verification.
Se trata de la misma separación de funciones que los equipos de seguridad ya aplican a la identidad en otros ámbitos. Si pensamos en las credenciales de las máquinas y las identidades de los servicios, el problema general es similar al descrito en gestión de identidades no humanas: los agentes automatizados toman decisiones a la velocidad de una máquina, por lo que los supuestos de confianza débil no se adaptan bien a gran escala.
La verificación del hash por sí sola puede ser útil, pero solo si el hash de confianza procede de un canal que el atacante no pueda modificar también. Los metadatos firmados ofrecen mayor seguridad. El «Update Framework», conocido como TUF, va más allá con roles delegados, firmas de umbral, caducidad y protección contra retrocesos, de modo que un espejo malicioso no pueda simplemente reproducir una versión antigua y vulnerable o mezclar archivos de diferentes versiones.
El papel de BGP, RPKI y ROV en la defensa
El BGP se diseñó para garantizar la accesibilidad entre redes que cooperan entre sí, no para demostrar la titularidad legítima de cada anuncio de ruta. Un ataque de secuestro de BGP se aprovecha de esa confianza para hacer que Internet dé preferencia a una ruta no autorizada. La regla de «coincidencia de prefijo más largo» hace entonces exactamente lo que se diseñó para hacer: elegir la ruta más específica.
El RPKI y la validación del origen de las rutas pueden limitar los anuncios de origen no autorizados cuando las autorizaciones de origen de las rutas son estrictas y las redes las hacen cumplir. En este caso, según informó Ars Technica citando a Doug Madory, la ruta AS falsificada seguía siendo válida según la RPKI porque la ROA requería el AS de origen 24940 y permitía longitudes de prefijo desde /16 hasta /24. Ese caso extremo es relevante.
Traducción: contar con el RPKI no equivale a tener una política de enrutamiento que bloquee todas las formas de secuestro útiles. Si un ROA permite un /24 y la ruta puede parecer válida a nivel de origen, es posible que los defensores necesiten una supervisión adicional, longitudes máximas de prefijo más restrictivas siempre que sea posible, filtrado en el origen y una escalación rápida con los proveedores de alojamiento.
Para los equipos que planean ofrecer servicios de alojamiento y visibilidad en la red, la seguridad de las rutas debe tener la misma importancia que la capacidad y la ubicación geográfica, y no quedar relegada a un apéndice olvidado. Esa misma mentalidad práctica se aplica cuando... planificar la implementación de un servidor dedicado: Infórmate sobre los controles de enrutamiento, el proceso de notificación y los contactos de emergencia de tu proveedor antes de que se produzca una interrupción del servicio o un secuestro de tráfico.
¿Qué deben comprobar ahora los operadores de Virtualizor?
Tanto Virtualizor como BleepingComputer aconsejan a los operadores que comprueben si hay /etc/systemd/system/java-jre-update.service como indicador de una posible vulneración. Softaculous también aconsejó a los usuarios del área de clientes que restablecieran sus contraseñas si habían iniciado sesión durante los periodos afectados. Dado que Virtualizor indicó que las respuestas maliciosas procedían del sistema del atacante, la empresa no pudo elaborar una lista definitiva de los servidores afectados a partir de sus propios registros.
Esto da lugar a una situación complicada: si tu servidor se ha actualizado durante ese periodo, el hecho de que no figure en la lista de proveedores no garantiza su seguridad. Necesitas pruebas locales.
- Comprueba si
/etc/systemd/system/java-jre-update.serviceexiste, y conservar las pruebas forenses antes de borrar nada. - Revisa el historial de actualizaciones de Virtualizor y los registros del sistema correspondientes al periodo comprendido entre las 20:57 UTC del 28 de agosto y las 06:10 UTC del 30 de agosto de 2026.
- Instala Virtualizor 3.2.9 Patch 9, publicado el 1 de septiembre de 2026, y ejecuta el Analizador de seguridad desde el panel de administración.
- Renueva las credenciales que puedan haberse utilizado en las sesiones de cliente y facturación de Softaculous o Virtualizor afectadas.
- Vuelve a crear el sistema a partir de un soporte que sepas que funciona correctamente si detectas el indicador o no puedes determinar qué se ejecutó durante el periodo en el que se produjo la desviación.
La corrección automatizada resulta tentadora, pero no te saltes la fase de recopilación de pruebas. Si un servidor de gestión se ve comprometido, es posible que tenga credenciales para acceder a servidores invitados, plantillas, almacenamiento, API de DNS o sistemas de copia de seguridad. Los paneles de control de los servidores se encuentran en ubicaciones con privilegios.
Los equipos que ya llevan a cabo simulaciones de ataques deberían incorporar a sus escenarios la violación de la seguridad del canal de actualización. Si se utilizan pruebas autónomas, un siguiente paso útil es modelar la misma cadena descrita en equipos rojos autónomos: confianza en la ruta, confianza en el certificado, confianza en el paquete y persistencia tras la instalación.
La verdadera lección: las actualizaciones requieren una desconfianza gradual
A BGP hijacking attack like this one is not just a network story. It is a supply-chain story wearing a routing mask. The attacker didn’t need to breach every Virtualizor customer directly; the update mechanism did the distribution work for any client that asked at the wrong time.
Una buena arquitectura parte de la base de que cualquier capa puede fallar durante un tiempo. TLS puede ser válido y, aun así, no ser suficiente. BGP puede estar supervisado y, aun así, desviarse momentáneamente. Un repositorio puede estar accesible y, aun así, ser hostil. Los paquetes firmados, los metadatos firmados, los metadatos de repositorio de corta duración, la protección contra retrocesos, la firma por umbrales y la supervisión independiente cierran, cada uno de ellos, una puerta diferente.
Hay un contraargumento: los proveedores más pequeños no pueden alcanzar de la noche a la mañana el nivel de seguridad de los repositorios de Debian. Es cierto. Pero, como mínimo, el software del lado del servidor que se actualiza con privilegios elevados debería verificar las firmas criptográficas en el cliente antes de la instalación. Con este nivel de riesgo, es difícil justificar cualquier medida menos rigurosa.
The broader cloud security lesson is familiar: infrastructure controls and application controls have to mature together. If you treat them separately, you get exactly this kind of gap, which is why the argument in Los servicios en la nube y la seguridad evolucionan al unísono Esto encaja a la perfección aquí.
Preguntas frecuentes
¿Qué es un ataque de secuestro de BGP?
Un ataque de secuestro de BGP se produce cuando una red anuncia rutas IP que no está autorizada a originar, lo que provoca que otras redes envíen el tráfico por una ruta incorrecta. Las reglas de enrutamiento predeterminadas de Internet suelen dar preferencia a las rutas más específicas, como una /24 frente a una /16.
¿Se han visto comprometidas todas las instalaciones de Virtualizor?
No. Virtualizor, Softaculous y BleepingComputer describieron el envío de actualizaciones maliciosas a un pequeño número o a unas pocas instalaciones que buscaban actualizaciones durante el redireccionamiento del tráfico. El proveedor también afirmó que no podía elaborar una lista definitiva de los servidores afectados, ya que las respuestas maliciosas procedían del sistema del atacante.
¿Por qué un certificado TLS válido puede ser peligroso en este caso?
El certificado puede ser técnicamente válido si el atacante controla la ruta del tráfico durante la validación del dominio. En ese caso, TLS podría cifrar una conexión con un servidor controlado por el atacante en lugar de bloquear la actualización maliciosa.
¿Evita el RPKI este tipo de ataques?
El RPKI y la validación del origen de la ruta (ROA) pueden reducir la propagación de rutas erróneas, pero por sí solos no son suficientes. En este incidente, Ars Technica informó de que la ruta AS falsificada seguía siendo válida según el RPKI porque la ROA permitía longitudes de prefijo comprendidas entre /16 y /24.
¿Cuál es el primer indicador que deben comprobar los administradores de Virtualizor?
Tanto Virtualizor como BleepingComputer han mencionado /etc/systemd/system/java-jre-update.service como indicador de una posible intrusión. Si lo detectas, conserva las pruebas y considera que el servidor puede haber sido comprometido.
ES 
EN 
FR