BGP hijack de Softaculous expuso servidores Virtualizor via Hetzner

Qué pasó: un BGP hijack convirtió las actualizaciones de Virtualizor en malware

Un ataque de supply chain ejecutado entre el 28 y el 30 de agosto de 2026 convirtió un tramo de espacio IP legítimo en una tubería para distribuir malware. Los atacantes secuestraron mediante un BGP hijack direcciones IP asignadas a Softaculous, la compañía con sede en Emiratos Árabes Unidos que desarrolla Virtualizor, el panel que usan proveedores de hosting, data centers y operadores de infraestructura para gestionar servidores virtuales.

Según el reporte de Ars Technica, los atacantes aprovecharon dos debilidades encadenadas: una configuración laxa de seguridad de enrutamiento en el proveedor Hetzner Online (AS24940) y el proceso automatizado de emisión de certificados TLS de Let’s Encrypt. Con el prefijo anunciado fraudulentamente y un certificado válido, los atacantes recibieron sin advertencias el tráfico que los servidores Virtualizor enviaban a Softaculous para buscar actualizaciones.

SecurityWeek aporta los detalles técnicos: el incidente comenzó el 28 de agosto a las 20:57 UTC, cuando AS62390 (NexonHost) empezó a anunciar una porción del espacio de direcciones de Hetzner (162.55.0.0/16) de forma más específica de lo habitual, una jugada que, por las reglas de selección de ruta de BGP, tomó precedencia sobre el anuncio legítimo. El atacante mantuvo AS24940 (Hetzner) en el AS path como origen aparente, un truco clásico para dificultar la detección.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Por qué el ataque funcionó: tres errores en cascada

Lo que Ars Technica describe como una comedia de errores que no tiene nada de graciosa es en realidad una concatenación de fallos básicos de seguridad:

RPKI y filtrado laxos en Hetzner. La ausencia de validación estricta de origen (RPKI/ROA) permitió que un anuncio de prefijo más específico tomara precedencia. El atacante pudo redirigir tráfico durante dos ventanas dentro de un periodo total de 33 horas. Hetzner recuperó el espacio 12 horas después del primer hijack; luego dejó de anunciarlo otra vez y el atacante repitió la jugada, tardando esta vez casi 10 horas en ser revertida.
Validación TLS automatizada sin defensa en profundidad. Como Let’s Encrypt valida el dominio mediante consultas que también pasaron por el prefijo secuestrado, el atacante obtuvo un certificado válido para los dominios de Softaculous. El navegador o el cliente de actualización no levantó ninguna alerta.
Falta de code signing en las actualizaciones de Virtualizor. Esta fue la omisión más grave, según Softaculous: sus clientes de actualización no verificaban criptográficamente los paquetes. Si lo hubieran hecho, un binario modificado habría sido rechazado aunque el tráfico llegara desde una IP aparentemente legítima.

BleepingComputer añade que el servicio malicioso desplegado fue /etc/systemd/system/java-jre-update.service y que Softaculous no puede producir una lista definitiva de servidores afectados porque el tráfico malicioso nunca tocó sus logs.

Qué significa esto para tu startup

Este caso importa mucho más allá de Softaculous. Ilustra cómo la confianza entre capas —proveedor de hosting, autoridad certificadora, software vendor, operador del servidor— se rompe cuando falla la base. Para un founder hispanohablante que opera infraestructura en la nube o usa paneles de terceros, las consecuencias prácticas son directas.

Lo que el ataque demuestra a nivel de arquitectura

El BGP es un protocolo de los años 80 que no autentica de forma nativa quién anuncia qué prefijo. Cualquier AS puede anunciar cualquier bloque. La Internet Society estima que, según datos reportados por TechTarget, hubo 14.000 incidentes de enrutamiento en 2017 solo entre los operadores que reportan, una cifra que en 2026 sigue creciendo porque la adopción de RPKI (Resource Public Key Infrastructure) sigue siendo desigual. Los ejemplos históricos más citados: el desvío de tráfico de Apple, Facebook, Google y Microsoft hacia un pequeño ISP ruso, o el robo de aproximadamente 150.000 USD en Ethereum a usuarios de MyEtherWallet en 2018, ambos atribuidos a fallas de BGP.

El caso Softaculous añade una capa nueva: cuando el atacante puede además obtener un certificado válido, el ataque es prácticamente invisible para el usuario final.

Acciones concretas que puedes tomar esta semana

Audita tu superficie de dependencias de infraestructura. Si tu startup usa paneles de gestión como Virtualizor, cPanel, Plesk o similares, o consume actualizaciones desde IPs específicas, mapea cuáles son esos prefijos y verifica con tu proveedor que tienen ROAs firmados y filtrado de prefijos estricto. Pide por escrito la confirmación.
Implementa o exige code signing en tus canales de actualización. La medida que más habría mitigado este ataque es la más básica: firmar criptográficamente cada paquete y verificar la firma del lado del cliente. Si tu propio producto SaaS tiene auto-update, este es el momento de priorizar esa feature de seguridad.
Habilita logging externo y monitoreo de integridad. Softaculous no pudo listar servidores afectados porque el tráfico malicioso nunca llegó a sus logs. Si tu proveedor de software crítico no puede decirte qué pasó en tu servidor durante una ventana comprometida, ese proveedor es un punto ciego. Complementa con logs externos (SIEM, syslog remoto) y verificaciones periódicas de integridad de archivos críticos.

Qué deberías exigirle a tus proveedores

Este incidente cierra con varias recomendaciones que la industria lleva años repitiendo, pero que casos como el de Cloudflare en enero de 2026 (un route leak de 25 minutos que descartó aproximadamente 12 Gbps de tráfico IPv6, según BleepingComputer) muestran que siguen sin implementarse de forma universal:

Adopción de RPKI con ROAs firmados para todos los prefijos propios.
Filtrado estricto de prefijos en los bordes, rechazando anuncios más específicos o no autorizados.
Verificación criptográfica de actualizaciones (code signing) como requisito no negociable.
Monitoring continuo de BGP con herramientas como BGPMon, ThousandEyes o RIPE RIS para detectar anuncios anómalos en minutos, no en horas.
Plan de respuesta a incidentes que asuma la posibilidad de que tu proveedor de hosting sea el eslabón débil, con procedimientos para que tu propio equipo valide de forma independiente la integridad del software.

La moraleja para founders: tu seguridad es tan fuerte como el eslabón más débil de tu cadena de proveedores. Y en 2026, ese eslabón suele ser infraestructura compartida que ni siquiera gestionas directamente.