Entre las 20:57 UTC del 28 de agosto de 2026 y las 06:10 UTC del 30, el tráfico dirigido a 256 direcciones IP de un proveedor de paneles de hosting se fue a otra parte. El navegador no avisó de nada, porque el atacante consiguió un certificado TLS legítimo para esos dominios. Unos cuantos servidores pidieron una actualización, recibieron un paquete malicioso y lo instalaron. Y luego está la parte que nos hizo abrir la consola: mientras duró, la ruta secuestrada era válida para RPKI. No inválida ni dudosa: válida.
Somos operador con red propia: anunciamos nuestras direcciones por BGP y tenemos tránsito y peering. Cuando leímos el informe del incidente echamos en falta una palabra, así que fuimos a buscarla nosotros. Lo que sigue es la reconstrucción, el dato que no está en el informe y las comprobaciones que puede hacer hoy cualquiera, tenga o no un sistema autónomo propio.
Lo que pasó, con horas
A las 20:57 UTC del 28 de agosto, el sistema autónomo AS62390 (NexonHost) empezó a anunciar el prefijo 162.55.80.0/24 a través del tránsito AS6204 (Zet.net), declarando como origen el AS24940 —que es Hetzner, el titular legítimo de ese espacio—. El bloque real se anuncia como un /16.
Y ahí está la regla de BGP que decide el resto de la historia: gana el prefijo más específico. Un /24 le gana a un /16 en cualquier red que acepte el anuncio, sin que importen preferencias locales, comunidades ni longitud del camino. No hay empate que romper: son dos destinos distintos y el router elige el más concreto.
La ventana del incidente fue de unas 33 horas, pero el desvío no estuvo activo todo ese rato: fueron dos oleadas que suman alrededor de 22 horas, separadas por un intervalo de once. Y ese intervalo no fue casualidad. La cronología del proveedor lo cuenta así: después de reportar el secuestro a Hetzner y escalarlo varias veces, «Hetzner empieza a anunciar 162.55.80.0/24 directamente» y «el desvío cae a cero en minutos». La mitigación que funcionó fue de-agregar: pelear el prefijo más específico con la misma arma. Apunta esa frase, que vuelve dos apartados más abajo.
Medido sobre los 368 peers del sistema de recolección de rutas de RIPE, en su pico la ruta falsa la veía cerca del 72 %; la media ponderada en el tiempo fue de alrededor del 28 % del total, o del 65 % contando solo los que llevaban ruta hacia ese destino. Los 368 la llevaron en algún momento, con unas 10.600 retiradas registradas. Un camino de ejemplo que recoge el informe: 20912 6204 62390 24940. Ese último salto —el origen— es lo único que mira la validación de origen, y es un número que el atacante escribió a mano.
El candado no dice quién eres: dice quién contestó
Una autoridad de certificación comprueba que controlas un dominio conectándose a él por la red. Si la red miente, la comprobación miente. El informe lo dice sin rodeos: la validación automatizada de propiedad del dominio de la autoridad de certificación también iba encaminada a través del secuestro. Resultado: un certificado de Let's Encrypt técnicamente válido para las webs del proveedor —el anexo del informe lista todos los nombres de host cubiertos—, emitido a quien no era. Ni aviso en el navegador, ni error en el cliente que descargaba las actualizaciones.
Alguien preguntará por la validación desde varios puntos de la red. Existe: Let's Encrypt la desplegó a escala en febrero de 2020 y dice haber sido la primera autoridad en hacerlo. Sube el listón y evita secuestros locales o de alcance corto. Pero una ruta que ve la mayor parte de internet la ven también los puntos desde los que se valida, y ahí la multiplicidad deja de aportar. El informe no explica cómo se superó esa comprobación y nosotros no vamos a inventárnoslo; lo que sí está medido es hasta dónde llegó la ruta. Es la misma lección que escribimos sobre el secuestro de DNS en el wifi de un hotel: el cifrado protege el contenido del camino, no te dice si el camino es el correcto.
El dato que no está en el informe
La palabra que faltaba es RPKI. El informe del incidente no la menciona ni una vez. RPKI es el sistema con el que el titular de unas direcciones firma un objeto —una ROA— que dice «este prefijo lo puede originar este sistema autónomo, hasta esta longitud». Los routers que hacen validación de origen descartan lo que no cuadra. Así que fuimos a mirar qué decía la ROA de ese bloque.
Consultado el 5 de septiembre de 2026, RIPEstat responde que hoy ese /24 es inválido por longitud: la ROA de 162.55.0.0/16 autoriza al AS24940 con maxLength 16. Puedes reproducirlo en una línea:
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS24940&prefix=162.55.80.0/24" | jq .data.status
# devuelve: "invalid_length"
curl -s "https://stat.ripe.net/data/rpki-history/data.json?resource=162.55.0.0/16" | jq -r '.data.timeseries[] | [.time, .max_length] | @tsv'
# 2026-08-28 24 <- el dia del secuestro# 2026-09-01 24# 2026-09-02 16 <- dos dias despuesEl historial es la parte interesante. Desde el primer dato que guarda RIPEstat, el 17 de marzo de 2021, y hasta el 1 de septiembre de 2026, esa ROA tenía maxLength 24. El 2 de septiembre pasó a 16. Es decir: el valor cambió dos días después de que terminara el secuestro, y durante las 33 horas que duró estuvo en 24.
Traducción operativa: mientras duró el ataque, un router con validación de origen activada recibía el 162.55.80.0/24 falso, comprobaba la firma y le salía válido. La ROA autorizaba al AS24940 a originar cualquier cosa hasta /24 dentro de ese bloque, y el atacante decía ser el AS24940. No había nada que descartar.
Vamos a ser honestos con lo que no sabemos: nadie ha declarado por qué se estrechó la ROA el 2 de septiembre. La coincidencia temporal está ahí y cualquiera puede verla; la causa no la ha publicado el titular y no la vamos a publicar nosotros por él.
RPKI valida el origen, no el camino
La validación de origen contesta a una sola pregunta: ¿el sistema autónomo que aparece al final del camino está autorizado a originar este prefijo? Eso resuelve el error humano —el clásico anuncio equivocado a las tres de la mañana— y los secuestros torpes. No resuelve al que falsifica el origen, porque el AS de origen es un campo del anuncio, no una firma: se escribe lo que se quiera.
Y si además dejas una maxLength más ancha que lo que anuncias de verdad, le estás regalando al falsificador un sub-prefijo autorizado: exactamente la pieza que gana la elección de ruta. Esto no es una intuición nuestra. Está escrito en el RFC 9319 (BCP 185, octubre de 2022), titulado The Use of maxLength in the Resource Public Key Infrastructure (RPKI): «In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal». El mismo documento recoge una medición de junio de 2017: el 12 % de los prefijos autorizados en ROAs llevaban una maxLength mayor que su propia longitud y, de esos, el 84 % quedaban expuestos a un secuestro de sub-prefijo con origen falsificado.
La parte incómoda: esa maxLength también fue la cura
Vuelve la frase que pedimos apuntar. Lo que paró el desvío fue que el titular legítimo anunciara él mismo el /24. Y ese anuncio de emergencia solo era RPKI válido porque la maxLength estaba en 24. Con una ROA mínima —maxLength 16, la que hay hoy y la que recomienda el RFC— la contramedida de Hetzner habría salido inválida por longitud y la habrían descartado precisamente las redes que mejor hacen los deberes.
Esa tensión es real y el propio RFC 9319 la reconoce: quien emite ROAs mínimas tiene que cambiarlas para cambiar lo que anuncia, y aun así concluye que la ROA mínima ofrece la mejor protección posible frente al impacto inmediato del ataque. Estamos de acuerdo, con una condición operativa que casi nadie escribe: si estrechas la maxLength, necesitas poder reemitir la ROA en caliente —a las tres de la mañana, sin buscar quién tiene la contraseña del portal del RIR—. La ROA mínima es la postura correcta; la agilidad para cambiarla es lo que la hace segura. Sin lo segundo, has cambiado un riesgo por otro.
La pieza que cerraría del todo el agujero del camino —validar que quien propaga el anuncio tiene derecho a hacerlo, y no solo quién dice originarlo— sigue en estandarización y su despliegue es todavía marginal. Mientras tanto, la defensa realista se apoya en dos cosas: no dejar sub-prefijos autorizados sueltos y no confiar en la red para nada que importe de verdad.
Qué se lleva de esto una empresa sin AS propio
Si tu empresa no habla BGP, no puedes impedir que alguien secuestre el prefijo de tu proveedor. Lo que sí controlas es qué ocurre en tu casa cuando eso pasa. Y lo que pasó aquí es que unos servidores pidieron una actualización por un canal cifrado impecable y se instalaron un paquete que nadie había firmado. El cifrado autenticaba el nombre del servidor; nada autenticaba el contenido.
El proveedor ha anunciado que implementará firma de código para todos sus paquetes. Es la conclusión correcta, y es la pregunta que deberías hacerle a cualquiera que tenga permiso para instalar software en tus máquinas sin que tú intervengas —empezando por el agente de gestión remota, del que ya hemos escrito que es una superficie de ataque con nombre propio—.
El indicador de compromiso que publicó el proveedor es una unidad de systemd: /etc/systemd/system/java-jre-update.service. Un nombre plausible, en un sitio normal, con toda la pinta de haber salido de un proceso de actualización legítimo. Ninguna capa de red ve eso; lo ve la telemetría del propio equipo. Esa es la diferencia práctica entre un antivirus que mira ficheros y un servicio de EDR/MDR que mira lo que se crea, se ejecuta y persiste.
Seis comprobaciones que puedes hacer hoy
- 1Mira tu ROA (o la de tu proveedor) con la consulta de arriba. Si la
maxLengthes más ancha que el prefijo que anuncias de verdad, estréchala hasta igualarla. Es un cambio de un minuto en el portal del RIR y cierra la puerta exacta que se usó aquí. En el mismo minuto, escribe quién puede reemitirla de madrugada si algún día hay que de-agregar. - 2Pregunta por escrito a tus tránsitos si descartan las rutas inválidas por RPKI. Un «sí» de palabra en una llamada comercial no es una respuesta; el nombre del router y la política aplicada, sí.
- 3Vigila tus prefijos. Una alerta cuando aparezca un anuncio más específico que tú no has hecho vale más que cualquier informe trimestral. Los datos de RIPE son públicos y gratuitos.
- 4Ninguna actualización automática sin firma verificada contra una clave que no llegue por el mismo canal. Si el instalador se fía del TLS y ya, el TLS es tu única defensa —y acabas de leer lo que vale cuando la ruta miente—.
- 5Telemetría de host con memoria. El proveedor pidió revisar cuatro cosas: claves SSH desconocidas, cuentas de usuario nuevas, tareas programadas o cron inesperados y conexiones salientes inesperadas. El indicador de systemd lo publicó aparte. De esa lista, solo las conexiones salientes las ve un cortafuegos; las otras tres viven dentro de la máquina y solo las ve quien mira dentro.
- 6Cuando un proveedor publique un indicador, búscalo en todo el parque, no solo en la máquina sospechosa. Aquí el propio fabricante reconoce que no puede dar una lista definitiva de instalaciones afectadas: si esperas a que te avisen por tu nombre, no te van a avisar.
Qué hacemos nosotros con esto
En everyWAN operamos red propia: anuncios BGP, tránsito y peering, y la costumbre de mirar cómo se ven nuestras rutas desde fuera antes de que nos lo cuente otro. Cuando montamos direccionamiento propio para un cliente —lo contamos en detalle en multihoming con IP propia y dos operadores— la ROA entra en el entregable con la longitud exacta que se anuncia, y con el nombre de quién puede cambiarla a las tres de la mañana.
Y en la consultoría previa, la mitad del trabajo consiste en escribir la lista de arriba antes de que haga falta: quién firma tus rutas, quién puede instalar software en tus máquinas sin preguntarte, y quién mira el equipo cuando el aviso llega en inglés y en un blog de un proveedor que ni sabías que tenías.
Durante las veintidós horas en que aquel anuncio estuvo activo, cualquiera que hiciera las comprobaciones obtenía una respuesta correcta: el origen estaba autorizado, el certificado era válido y la actualización llegaba servida. Las tres decían que sí, y ninguna de las tres comprobaba lo que hacía falta comprobar.
Fuentes: cronología del secuestro (28 de agosto de 2026 a las 20:57 UTC hasta el 30 a las 06:10 UTC: ventana de unas 33 horas, dos oleadas que suman unas 22 de desvío activo y un intervalo de once horas que empieza cuando Hetzner, tras el aviso y varios escalados, comienza a anunciar el /24 directamente y el desvío cae a cero en minutos), prefijo 162.55.80.0/24, AS62390 (NexonHost) anunciando con tránsito de AS6204 (Zet.net) y origen declarado AS24940, propagación medida sobre 368 peers de RIPE RIS (pico ~72 %, media ponderada ~28 % del total y ~65 % de los que llevaban ruta, ~10.600 retiradas), certificado de Let's Encrypt válido para los nombres de host del proveedor que lista el anexo del informe, entrega de un paquete de actualización malicioso a un número reducido de instalaciones, indicador /etc/systemd/system/java-jre-update.service y medidas recomendadas (rotar claves de API, restringir acceso por IP, revisar claves SSH, cuentas y tareas programadas, resetear contraseñas del área de clientes, firma de código futura): informe público de incidente publicado por Virtualizor/Softaculous. Estado y historial de la ROA de 162.55.0.0/16 (origen AS24940; maxLength 24 desde el 17 de marzo de 2021 hasta el 1 de septiembre de 2026 y 16 desde el 2 de septiembre; estado invalid_length del /24 hoy): consultas a la API pública de RIPEstat realizadas el 5 de septiembre de 2026, reproducibles con los comandos del artículo. Cita sobre maxLength («In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal»), medición de junio de 2017 (12 % de los prefijos autorizados en ROAs con maxLength mayor que su longitud; de esos, 84 % expuestos) y reconocimiento de que emitir ROAs mínimas obliga a modificarlas para cambiar lo que se anuncia: RFC 9319 / BCP 185, «The Use of maxLength in the Resource Public Key Infrastructure (RPKI)», octubre de 2022. El propio RFC contempla excepciones, entre ellas que se anuncien de verdad todos los más específicos que la maxLength permite. Despliegue de validación desde varios puntos de la red en febrero de 2020: blog de Let's Encrypt. Lo que no afirmamos: no sabemos por qué se estrechó la ROA el 2 de septiembre —el titular no lo ha declarado—, y el informe no explica cómo se superó la validación de la autoridad de certificación; la relación que planteamos entre la propagación de la ruta y esa validación es un razonamiento nuestro, no un hecho publicado.
¿Quién firma tus rutas y quién instala tu software?
Revisamos tu direccionamiento y tus ROAs, te decimos qué ve internet de tus prefijos y qué proveedores pueden instalar software en tus máquinas sin pasar por ti. Te lo entregamos por escrito.
Microsoft 365
ES 
CAT 
EN