Bunny.net revoca certificados TLS por incidente CDN

Qué pasó con el nodo CDN de Bunny.net en Armenia

Un proveedor de infraestructura de Bunny.net reportó la semana pasada un acceso no autorizado que involucraba software de gestión de servidores de terceros. Uno de los nodos CDN de la compañía, ubicado en Armenia, estaba alojado en un servidor provisto por esa empresa.

La respuesta está documentada paso a paso: en 20 minutos el equipo de ingeniería dejó de enrutar tráfico por ese servidor, revisó y preservó los logs de seguridad relevantes, borró el servidor de forma segura, revocó su acceso al resto de los sistemas y lo retiró de manera permanente de la infraestructura.

Ni la investigación de Bunny.net ni la del proveedor encontraron evidencia de acceso no autorizado al nodo o a sus datos. El proveedor continúa investigando. Esa es la parte tranquilizadora del reporte; la incómoda es de dónde vino el problema: no de la infraestructura propia, sino de una capa de software que la compañía no controla directamente.

Qué datos podrían haberse visto expuestos

Bunny.net es explícito: aunque ninguna investigación encontró indicios de acceso, no puede descartar por completo la posibilidad. Si hubiera ocurrido, la información potencialmente expuesta habría sido:

• Contenido CDN en caché de forma temporal
• Configuraciones de Pull Zone
• Certificados TLS almacenados en ese servidor

La compañía aclara que ningún otro dato de clientes, incluida la información de cuentas de bunny.net, estaba almacenado en el servidor en cuestión, y que ningún sistema interno se vio afectado.

Vale la pena detenerse en el segundo punto. Una configuración de Pull Zone define de dónde tu CDN trae el contenido y cómo lo sirve. Si esa configuración incluye tokens de origen, URLs internas o reglas de acceso, es material sensible: no es una contraseña, pero es un mapa de tu arquitectura.

Por qué la rotación de certificados TLS es la parte que te toca

Como precaución adicional, Bunny.net revocó y reemitió todos los certificados TLS de sus dominios de plataforma (b-cdn.net y bunny.run). La reemisión de certificados gestionados para dominios personalizados estaba en curso y se esperaba completar en las siguientes 24 horas. Los clientes con certificados gestionados no tienen que hacer nada.

El caso cambia si gestionas tus propios certificados TLS: la recomendación de la compañía es revocarlos y reemitirlos con nuevas claves privadas.

Un certificado TLS es la pieza que garantiza que el tráfico entre tu usuario y tu servidor viaja cifrado y que el sitio es quien dice ser. Si la clave privada que lo respalda queda en manos de un tercero, esa garantía se rompe: alguien podría interceptar o suplantar tráfico sin que el navegador muestre ninguna advertencia. Por eso la rotación con claves nuevas, y no solo la reemisión, es la parte que importa.

Qué significa esto para tu startup

El incidente no ocurrió en tu proveedor, pero la lección sí aplica a tu stack. Tres acciones concretas:

• Rota tus certificados si los gestionas tú. Si tu equipo administra TLS con un balanceador propio o certificados comprados, genera claves privadas nuevas y reemplaza los certificados. Revisa también los registros de transparencia de certificados para detectar emisiones que no reconozcas.
• Revisa qué estás cacheando. El contenido en caché fue uno de los tres elementos potencialmente expuestos. Si tu CDN guarda respuestas de API con tokens, sesiones o datos personales, estás ampliando la superficie de exposición sin necesidad. Ajusta las reglas de caché y los TTL para que solo se almacene lo que es público por definición.
• Mapea tus dependencias de un solo proveedor. Haz la lista de servicios críticos (CDN, DNS, base de datos gestionada, pasarela de pagos) y pregúntate qué pasa si uno cae o queda comprometido. Si la respuesta es que no lo sabes, ya tienes tu próxima tarea.

Cómo auditar tu cadena de suministro de infraestructura

Este incidente es un caso de manual de riesgo de cadena de suministro: el problema entró por el software de gestión de servidores de un proveedor, no por un fallo propio. Es un patrón habitual en los incidentes de infraestructura modernos y es difícil de detectar, porque el proveedor afectado suele estar dos capas por debajo de tu visibilidad.

Algunas preguntas útiles para tu próxima revisión de proveedores o negociación de contrato:

• ¿Con cuánta antelación te notifican un incidente de seguridad y por qué canal?
• ¿Qué obligaciones de preservación de logs y de investigación asume el proveedor?
• ¿Puedes exigir rotación de credenciales y certificados como parte del acuerdo?
• ¿Tienes un plan de conmutación probado, o solo documentado?

Qué se sabe y qué no

El reporte de Bunny.net es notablemente claro para ser una comunicación de incidente: define el alcance, admite lo que no puede descartar y fija próximos pasos con plazos. La compañía se comprometió a publicar una actualización en su status page cuando termine la reemisión de certificados gestionados, y a avisar por email si aparecen hallazgos nuevos que afecten a clientes.

Lo que no se sabe, y conviene no asumir: cuántos clientes usaban ese nodo, cuánto tiempo estuvo el servidor bajo el control del proveedor afectado y qué software de gestión específico fue el vector. Ninguna de esas respuestas está en el comunicado.

Al momento de publicar esta nota no se encontraron datos adicionales verificables en fuentes externas sobre el incidente.

Conclusión

El incidente de Bunny.net no fue un fallo de su infraestructura, sino de una dependencia: el software de gestión de un proveedor. La respuesta, con 20 minutos para cortar el tráfico, logs preservados y el servidor borrado y retirado, es un buen ejemplo de contención rápida. Pero la parte que le toca a cada founder es la otra: revisar qué certificados gestionas tú, qué cacheas y de qué proveedores dependes sin plan B.

La seguridad de tu producto no termina en tu código. Termina donde termina tu visibilidad sobre tus proveedores.

Fuentes

• Bunny.net Status - Security Incident (fuente original)