Este artículo es una continuación de nuestro artículo de julio de 2025, Cómo Cloudflare alimenta y favorece a los delincuentes de Internet a través de su imperio de proxy inverso/DNS.

Resumen ejecutivo

  • Crecimiento explosivo del abuso. Los dominios de desarrolladores de Cloudflare batieron nuevos récords en 2024: los incidentes de pages.dev aumentaron un 198 % (460 → 1370) y los de workers.dev un 104 % (2 447 → 4 999). El total de campañas va camino de superar las 1 600 en 2025.

  • Uso indebido sistémico. Varios proveedores de seguridad (Fortra, Trustwave, CloudSEK) e investigadores independientes muestran suplantaciones de identidad de marcas y recopilación de credenciales a gran escala en la infraestructura de Cloudflare.

  • Procesos sin salida. A pesar de los miles de denuncias, incluidas las de denunciantes de confianza, el departamento de abuso de Cloudflare responde con negativas estereotipadas y hace recaer la carga de la prueba en los denunciantes.

  • Colisión legal. La NIS2, sus transposiciones nacionales y la Ley de Servicios Digitales (DSA) imponen obligaciones estrictas a las «plataformas en línea», las CDN, los DNS y los proveedores de proxy inverso. La práctica actual de Cloudflare incumple estas normas y genera una responsabilidad material para los clientes de la UE.

  • Medidas a tomar. Los reguladores deben aclarar la responsabilidad de las CDN; las empresas deben bloquear pages.dev / workers.dev por defecto; los responsables de la respuesta a incidentes deben presionar para obtener la condición de «flagger» de confianza; y los equipos de adquisiciones deben reevaluar Cloudflare en relación con las obligaciones de la cadena de suministro de la NIS2.

El informe de abuso que no llegó a ninguna parte

A continuación se muestra un extracto literal de la respuesta de Cloudflare a una de nuestras recientes solicitudes de eliminación de phishing dirigida a un dominio falso de una agencia de viajes que se hace pasar por tiquetesbaratos.com:

Fecha: 31 de julio de 2025

De: abuse@cloudflare.com

Asunto: Re: [Abuso de Cloudflare] tiquetesbaratoscos[.]pages[.]dev

Hola, Cloudflare ha recibido su informe de phishing relativo a: tiquetesbaratoscos[.]pages[.]dev

No podemos procesar su informe por los siguientes motivos: No hemos podido confirmar el phishing en las URL proporcionadas.

Tenga en cuenta que Cloudflare ofrece soluciones de servicios de red que incluyen servicios de seguridad de paso, una red de distribución de contenidos (CDN) y servicios de registro. Debido a la naturaleza de paso de nuestros servicios, nuestras direcciones IP aparecen en los registros WHOIS y DNS de los sitios web que utilizan Cloudflare. Cloudflare no puede eliminar de Internet material alojado por terceros.

La respuesta es idéntica a las docenas que hemos recibido solo en 2025, independientemente de las pruebas aportadas (capturas de pantalla en directo, capturas, rastreos de paquetes, hash de scripts de robo de credenciales).

Una plataforma de producción bien engrasada para el phishing

Indicador 2023 2024 % Δ
Incidentes de phishing en pages.dev 460 1 370 +198 %
Incidentes de phishing en workers.dev 2 447 4 999 +104 %

Fuente: Fortra SEA, diciembre de 2024

Estas cifras son conservadoras. Nuestra propia telemetría muestra subdominios maliciosos alojados en Cloudflare que suplantan a tiquetesbaratos.com en un ámbito más amplio.

Hallazgos adicionales de terceros:

  • Trustwave SpiderLabs destacó «una gran cantidad de páginas de phishing y estafa que abusan de los servicios de Cloudflare pages.dev».

  • CloudSEK describió un kit de phishing genérico alojado en workers.dev que puede suplantar cualquier marca bajo demanda.

  • Un hilo de Reddit con más de 600 votos positivos narra la frustración de un investigador tras denunciar más de 200 sitios maliciosos de pages.dev, de los cuales menos del 30 % han sido eliminados.

Por qué el proceso de Cloudflare falla a los denunciantes de confianza

  1. Denuncias solo mediante formulario: las denuncias por correo electrónico reciben un rebote automático que dirige a los denunciantes al formulario web. Los incidentes masivos no se pueden enviar de manera eficiente.

  2. Alto nivel de exigencia probatoria: los denunciantes deben demostrar que el phishing está activo en el momento de la revisión, ignorando que las campañas suelen operar en ráfagas cortas.

  3. Resultados opacos: Cloudflare rara vez revela si se ha tomado alguna medida, alegando motivos de privacidad y confidencialidad del cliente.

  4. Sin vía de apelación o escalamiento: no existe un acuerdo de nivel de servicio (SLA) para abusos de alto riesgo, ni una política para el estatus de denunciante de confianza en virtud de la DSA.

¡Sigue el dinero!

Los precios de Cloudflare para desarrolladores son famosos por su generosidad: pages.dev es gratuito y los planes de Workers comienzan en 5 USD al mes. Cada nuevo sitio aumenta el volumen de salida de datos, TLS y computación periférica de Cloudflare, lo que se traduce en:

  • Mayor potencial de venta adicional de servicios premium.

  • Mejores métricas de tráfico para los informes de los inversores.

  • Más telemetría para alimentar las funciones de aprendizaje automático comercializadas como soluciones antiphishing.

Resultado: los costes de moderación amenazan los márgenes; la automatización y la denegación son más baratas.

La perspectiva jurídica: DSA, NIS2 y leyes nacionales de ciberseguridad

Ley de Servicios Digitales (DSA)

  • En vigor desde el 17 de febrero de 2024. Exige a las «plataformas en línea» que actúen ante notificaciones fundamentadas sin demoras indebidas.

  • Multas de hasta el 6 % de la facturación global por incumplimiento sistémico. Cloudflare aún no ha sido designada oficialmente como VLOP, pero su base de usuarios supera fácilmente el umbral de 45 millones de usuarios activos al mes.

Directiva NIS2 (UE 2022/2555) y transposiciones nacionales

  • Fecha límite de transposición: 17 de octubre de 2024; a mediados de 2025, menos de un tercio de los Estados miembros habían notificado la transposición completa. El 7 de mayo de 2025, la Comisión Europea emitió dictámenes motivados a 19 rezagados, entre ellos DE, FR, NL, SE y DK, por no haber aplicado la NIS2.

  • Ampliación del ámbito de aplicación: la NIS2 ahora cubre explícitamente a «los proveedores de servicios DNS, los registros de nombres TLD, los proveedores de servicios de computación en la nube y los proveedores de servicios de centros de datos», todas ellas funciones que Cloudflare desempeña al gestionar el tráfico.

  • Entidades esenciales frente a importantes: las grandes CDN se clasificarán como esenciales (§3(1)(l)), estarán sujetas a supervisión ex ante y a sanciones más estrictas, de hasta 10 millones de euros o el 2 % de la facturación global.

  • Seguridad de la cadena de suministro (artículo 21). Las organizaciones de la UE deben evaluar y mitigar los riesgos derivados de los proveedores de servicios TIC. Seguir confiando en un proveedor con abusos conocidos y rutinas de retirada deficientes puede considerarse una gestión de riesgos no conforme.

  • Notificación de incidentes (art. 23). Los proveedores deben notificar los incidentes significativos sin demoras indebidas. Una plataforma en la que el phishing permanece sin detectar durante semanas corre el riesgo de incumplir esta obligación.

  • Aplicación de la supervisión. Los CSIRT y los reguladores nacionales (BSI-DE, ANSSI-FR, NCSC-NL, MSB-SE) obtienen la facultad de auditar, multar u ordenar la suspensión de los servicios que incumplan la normativa, incluidas las órdenes a los clientes de la UE de que dejen de utilizarlos.

Amplificadores específicos de cada país

  • Alemania (IT‑SiG 2.0) añade multas de hasta 20 millones de euros y faculta a la BSI para designar «componentes críticos».

  • Francia (LPM) y RGPD-SSI exigen que la infraestructura de alojamiento de los sectores críticos cuente con la certificación SecNumCloud, de la que Cloudflare no dispone.

  • Italia D.Lgs. 65/2024 exige que los organismos del sector público utilicen proveedores registrados en el Registro Nacional de la Nube.

  • Suecia (proyecto de ley de ciberseguridad) implementa la NIS2; entrada en vigor propuesta para el 15 de enero de 2026. Las autoridades de supervisión (que se designarán por reglamento) obtendrán facultades de auditoría y de imposición de sanciones, mientras que la MSB seguirá siendo el punto único de contacto y el coordinador nacional.

Conclusión: En virtud de la NIS2 y sus avatares nacionales, la selección de un proveedor de CDN/DNS/proxy inverso ya no es una elección puramente técnica, sino una decisión regulada sobre la cadena de suministro con responsabilidad a nivel directivo.

Cómo responden los proveedores responsables

Proveedor Formatos de pruebas aceptados Latencia típica de retirada Canal de abuso
Namecheap Capturas de pantalla, lista de URL, correo electrónico 12 h para phishing verificado abuse@namecheap.com
PDR Breve descripción, URL, capturas de pantalla 48 h abuse@publicdomainregistry.com + formulario web
OVH Cloud CSV masivo, PCAP 24-48 h formulario web + ticket
Hostinger Lista de URL, correo electrónico 12h abuse@hostinger.com + formulario web
nameSILO Lista de URL, correo electrónico 6-12h abuse@namesilo.com + formulario web


How non-responsible providers respond

Proveedor

Formatos de pruebas aceptados

Latencia típica de eliminación

Canal de abuso

Cloudflare

Debe reproducir el phishing en vivo a través del formulario web.

Días, semanas, meses (si es que hay)

Solo formulario web, cualquier otra comunicación será rechazada con plantillas automáticas.


Recomendaciones

Para los reguladores

  • Aclarar que las CDN y los proxies inversos son proveedores de alojamiento a efectos de la DSA y la NIS2 cuando terminan el TLS y el contenido del proxy.

  • Aprovechar la aplicación de la NIS2. Utilizar inspecciones, multas y órdenes de cierre para los casos de incumplimiento persistente.

  • Exigir una vía rápida de señalización de confianza con acuerdos de nivel de servicio (SLA) de 24 horas y publicar registros de auditoría del tratamiento de los abusos.

Para empresas y SOC

  • Reevaluar a los proveedores de CDN durante las revisiones de riesgos de los proveedores de 2025; exigir pruebas escritas del cumplimiento de NIS2 y métricas de gestión de infracciones.

  • Bloquee o ponga en cuarentena los enlaces que terminan en pages.dev y workers.dev hasta que se verifique su seguridad.

  • Desvíe los subdominios de Cloudflare recién creados que suplantan su marca mediante el filtrado de DNS.

  • Actualice los manuales de respuesta a incidentes para incluir las obligaciones de la cadena de suministro de NIS2: documente la diligencia debida, conserve las pruebas de abuso y, si es necesario, cambie rápidamente de CDN.

Para Cloudflare

  • Publicar métricas de abuso en tiempo real por nivel de servicio.

  • Aceptar envíos masivos de CSV/JSON y proporcionar claves API a los informantes verificados.

  • Adoptar una política de «desactivar primero, apelar después» para las campañas de phishing altamente efímeras.

  • Documentar públicamente las medidas de cumplimiento de la NIS2, o perder el negocio de las empresas de la UE.

Conclusión

La visión de Cloudflare de «construir una Internet mejor» suena hueca mientras su infraestructura funciona como una plataforma de phishing llave en mano. En virtud de la NIS2, cada denuncia ignorada ya no es solo un problema de experiencia del usuario , sino una posible infracción normativa que puede acarrear multas en toda la cadena de suministro. Las empresas que siguen delegando el tráfico crítico a la infraestructura de Cloudflare sin exigir procesos de abuso transparentes y auditados se enfrentan ahora a un doble riesgo: credenciales comprometidas y sanciones por incumplimiento.

Es el momento de actuar , antes de que las primeras medidas de aplicación de la NIS2 sean noticia.