Tu página web funciona, aparece el candado de HTTPS en el navegador y has activado Cloudflare. Incluso ves estadísticas de ataques bloqueados en su panel. Todo parece estar bajo control.
Pero ¿eso significa que tu WordPress está realmente protegido?
No necesariamente.
Cloudflare puede filtrar solicitudes peligrosas antes de que lleguen al servidor. Es una medida valiosa, especialmente contra determinados ataques automatizados y vulnerabilidades conocidas. Sin embargo, no reemplaza las actualizaciones de WordPress, la seguridad del hosting ni el mantenimiento de los plugins.
Hay un detalle todavía más importante. Si alguien puede conectarse directamente al servidor que aloja tu página sin atravesar Cloudflare, podría evitar una parte de esas protecciones.
Para comprender los riesgos no necesitas ser programador. Te explicamos qué revisar y cómo reconocer las situaciones que requieren ayuda técnica.
¿Qué protege Cloudflare en una página WordPress?
Cuando una persona visita una web que utiliza el proxy de Cloudflare, su solicitud normalmente llega primero a la red de Cloudflare y después, cuando es necesario, al servidor donde está instalado WordPress.
Ese servidor se conoce como servidor de origen.
Cloudflare puede ofrecer distintas medidas de protección, entre ellas filtrado de tráfico sospechoso, mitigación de ataques de denegación de servicio y reglas específicas para aplicaciones web.
Una de sus herramientas es el WAF, sigla de Web Application Firewall o firewall de aplicaciones web.
Imagina que tienes una tienda con un control de acceso en la entrada. El WAF funciona de manera parecida: examina determinadas solicitudes antes de permitirles llegar a la aplicación.
El inconveniente aparece cuando ese control no cubre todos los accesos o cuando el problema ya está dentro de la tienda.
Un plugin vulnerable, una contraseña robada o un archivo malicioso que quedó en el servidor necesitan medidas adicionales.
Por eso es más correcto hablar de varias capas de seguridad que de una sola protección definitiva.
El caso de WordPress en 2026: Cloudflare bloqueó ataques, pero también pidió actualizar
El 17 de julio de 2026, WordPress publicó la versión 7.0.2 para corregir dos problemas graves de seguridad.
Uno de ellos permitía manipular determinadas consultas a la base de datos. Se identifica como CVE-2026-60137.
El otro, CVE-2026-63030, podía combinarse con el primero para conseguir ejecución remota de código en determinadas instalaciones afectadas.
En términos sencillos, un atacante podía aprovechar esos defectos para intentar que un servidor ejecutara instrucciones que nunca debió aceptar.
Cloudflare anunció ese mismo día que había desplegado reglas de bloqueo para proteger a los sitios cuyo tráfico pasara por su WAF.
Las medidas también llegaron a usuarios de su plan gratuito, dentro del alcance de las reglas publicadas.
Sin embargo, la compañía fue clara: esas protecciones reducían la exposición mientras los administradores actualizaban WordPress. No corregían el código vulnerable instalado en el servidor.
WordPress también publicó correcciones para determinadas ramas anteriores, como 6.9.5 y 6.8.6, según las vulnerabilidades que afectaban a cada una.
El 21 de julio, CISA incorporó ambos identificadores a su catálogo de vulnerabilidades explotadas conocidas.
Más recientemente, en septiembre de 2026, Cloudflare volvió a publicar una protección de emergencia para otra vulnerabilidad de WordPress que podía permitir la lectura indebida de archivos del servidor.
La lección es sencilla. Aunque un proveedor implemente defensas rápidamente, el propietario de una web debe comprobar que su instalación recibió las correcciones y que las medidas siguen funcionando.
1. Comprueba que tu dominio realmente pasa por Cloudflare
Utilizar Cloudflare como proveedor DNS no significa que todas las conexiones estén protegidas por su proxy.
Dentro de la sección DNS existen registros que pueden estar configurados como Proxied, representados habitualmente mediante una nube naranja, y otros como DNS only, identificados con una nube gris.
Cuando un registro web está en modo DNS only, las solicitudes a ese nombre no atraviesan el proxy HTTP de Cloudflare y no reciben las protecciones correspondientes del WAF.
Esto puede tener una explicación legítima.
Por ejemplo, algunos servicios técnicos y de correo necesitan configuraciones DNS diferentes. No todos los registros deben llevar nube naranja.
Lo importante es identificar cuáles corresponden a la página principal y sus subdominios web.
Qué puedes revisar: entra al panel de Cloudflare, abre DNS y comprueba el estado de los registros de tu página.
Qué debes evitar: cambiar registros de correo, servicios administrativos o aplicaciones desconocidas simplemente para que todos aparezcan con nube naranja.
Si no sabes qué servicio utiliza una dirección, consulta primero al administrador del hosting.
2. La IP real del servidor podría seguir expuesta
Este es uno de los riesgos menos comprendidos.
Cloudflare puede ocultar la dirección IP del servidor de origen cuando los visitantes consultan un dominio protegido. Pero esa dirección podría conocerse por otros medios.
Entre las posibles fuentes están los registros DNS antiguos, un subdominio sin proxy o ciertos servicios instalados en el mismo equipo.
Cloudflare reconoce este problema en su documentación oficial sobre protección del origen.
Supongamos que tu web usa Cloudflare, pero el servidor sigue aceptando conexiones web directas desde cualquier lugar de internet.
Si alguien conoce la dirección IP y consigue que el servidor atienda una solicitud destinada al sitio, puede existir una ruta que no atraviese el WAF de Cloudflare.
Eso no significa que conocer una IP sea equivalente a hackear un servidor. El riesgo está en que las protecciones que esperabas aplicar a todo el tráfico podrían no intervenir.
¿Cómo se evita?
En servidores administrados, una estrategia habitual consiste en restringir el acceso web al origen para que solo acepten conexiones de Cloudflare y de otros sistemas expresamente autorizados.
Existen opciones más avanzadas, como Authenticated Origin Pulls, que permite comprobar mediante certificados que determinadas solicitudes HTTPS proceden del intermediario autorizado.
Cloudflare también ofrece Tunnel, que utiliza conexiones salientes desde el servidor y puede evitar la exposición directa del servicio web en determinadas arquitecturas.
No todas estas opciones son adecuadas para cualquier hosting.
En un servidor cPanel compartido, por ejemplo, podrían alojarse numerosos dominios y servicios de clientes con necesidades diferentes.
No bloquees direcciones IP ni cierres puertos por tu cuenta si desconoces la arquitectura. Una restricción mal aplicada podría interrumpir webs, correo, paneles administrativos o integraciones.
Para un propietario de WordPress, la comprobación correcta consiste en preguntar al proveedor si el acceso directo al origen está restringido y cómo se protegen los servicios que no pasan por Cloudflare.
3. Revisa si las reglas del WAF están activas
No basta con que el sitio utilice el proxy.
Las protecciones disponibles dependen de las reglas, del plan y de las excepciones configuradas.
En julio de 2026, Cloudflare publicó reglas para dos vulnerabilidades críticas de WordPress y explicó que los propietarios de planes Pro, Business o Enterprise debían comprobar que las reglas administradas estuvieran habilitadas.
En los planes gratuitos se aplicaron las protecciones correspondientes mediante el conjunto de reglas gratuito.
Existe otra posibilidad que suele pasar desapercibida: una regla puede estar configurada para registrar solicitudes sin bloquearlas.
El modo de registro permite observar determinados comportamientos, pero no necesariamente impide que la solicitud llegue a WordPress.
También pueden existir excepciones que omitan parte de las verificaciones.
Qué revisar en el panel
Abre la sección de seguridad de Cloudflare y examina los eventos disponibles.
Comprueba si se están aplicando acciones de bloqueo o desafío, si existen excepciones amplias y si alguna regla importante quedó configurada únicamente para registrar.
Ten en cuenta que una cifra elevada de solicitudes bloqueadas no demuestra por sí sola que tu web haya estado comprometida.
Muchos bots realizan exploraciones automatizadas sobre numerosos sitios.
Del mismo modo, la ausencia de eventos no garantiza que nunca existió un riesgo. Puede depender del periodo consultado y de los registros disponibles en tu plan.
4. Mantén actualizados WordPress, plugins y temas
Un firewall puede interceptar determinados ataques, pero no sustituye la corrección del software.
WordPress está formado por el núcleo de la aplicación, los temas que controlan su presentación y los plugins que agregan funcionalidades.
Cada componente tiene su propio ciclo de mantenimiento.
Una tienda WooCommerce, por ejemplo, puede utilizar complementos de pagos, envíos, formularios y facturación. Si alguno presenta una vulnerabilidad, el riesgo no desaparece automáticamente porque el dominio utilice Cloudflare.
Desde el escritorio de WordPress puedes revisar las actualizaciones pendientes.
También conviene identificar extensiones que ya no utilizas. Un plugin desactivado pero conservado en el servidor puede continuar representando una superficie de riesgo, dependiendo de su código y de la vulnerabilidad.
El manual oficial de seguridad de WordPress recomienda eliminar complementos innecesarios y utilizar fuentes confiables.
Antes de realizar cambios importantes, conserva un respaldo verificable y revisa la compatibilidad del sitio.
Si administras una tienda, procura probar las actualizaciones en un entorno separado cuando el riesgo de interrupción lo justifique.
5. Comprueba la versión de PHP y la seguridad del hosting
WordPress no funciona por sí solo.
Necesita un servidor web, PHP para ejecutar su código y una base de datos para almacenar gran parte de su información.
Por eso una instalación de WordPress completamente actualizada todavía puede depender de componentes vulnerables o mal configurados.
En octubre de 2026, la investigación sobre PHP2Shell volvió a demostrar por qué importa el software que se encuentra debajo de la aplicación.
Cloudflare publicó mitigaciones para esas vulnerabilidades de PHP, pero la protección definitiva también requiere las correcciones correspondientes del intérprete.
Si utilizas hosting con cPanel, puedes consultar qué versión PHP está seleccionada y pedir al proveedor que confirme el mantenimiento de sus paquetes.
No asumas que un número de versión aparentemente antiguo significa necesariamente que falta un parche: determinados proveedores incorporan correcciones de seguridad mediante backports, manteniendo una versión base con modificaciones de seguridad.
Lo importante es disponer de información verificable sobre los paquetes instalados y las correcciones aplicadas.
Para comprender mejor este caso, puedes consultar nuestra investigación sobre PHP2Shell y las vulnerabilidades de PHP.
6. No confundas HTTPS con protección completa del servidor
El candado del navegador indica que existe una conexión HTTPS con el sitio al que estás accediendo.
Cuando utilizas Cloudflare, debes considerar dos conexiones diferentes.
La primera conecta al visitante con Cloudflare. La segunda conecta Cloudflare con el servidor de origen.
Si está activado el modo Flexible, la comunicación entre Cloudflare y el origen se realiza mediante HTTP.
En Full, puede existir cifrado hacia el origen, pero Cloudflare no valida completamente la identidad del certificado presentado.
En Full (strict), Cloudflare exige un certificado de origen válido según sus requisitos y verifica que corresponda al nombre del servidor solicitado.
Por eso Cloudflare recomienda utilizar Full (strict) cuando sea posible.
No obstante, cambiar directamente ese ajuste sin preparar el certificado del servidor puede provocar errores de conexión, como el 526.
Si no administras el servidor, solicita a tu proveedor que confirme el modo de cifrado, la validez del certificado de origen y la compatibilidad con las aplicaciones existentes.
7. Protege las cuentas administrativas y los accesos de trabajo
Los ataques no siempre comienzan buscando una vulnerabilidad en WordPress.
En ocasiones, el problema está en una contraseña comprometida, una computadora infectada o una cuenta administrativa que conserva más permisos de los necesarios.
El propio manual de seguridad de WordPress recuerda que un equipo utilizado para administrar una web también debe mantenerse protegido.
Revisa quiénes tienen acceso al escritorio, qué funciones utilizan y si siguen necesitando privilegios administrativos.
Cuando esté disponible, activa un segundo factor de autenticación y utiliza contraseñas únicas.
Si una agencia o un desarrollador necesita colaborar temporalmente, es preferible asignar el nivel de acceso adecuado en lugar de compartir una cuenta principal.
Cloudflare puede agregar controles a determinadas páginas administrativas, pero no reemplaza la protección de las credenciales ni la revisión de usuarios dentro de WordPress.
8. Verifica tus copias de seguridad y dónde se almacenan
Imagina que alguien consigue modificar archivos importantes, eliminar contenidos o afectar la base de datos.
Aunque Cloudflare haya bloqueado muchas otras solicitudes, necesitarás una forma de recuperar la información.
Una copia de seguridad debe incluir los componentes que realmente necesitas restaurar.
En WordPress eso normalmente comprende los archivos, las imágenes y la base de datos. También deben considerarse configuraciones especiales y servicios adicionales si forman parte del proyecto.
No es conveniente guardar el único respaldo dentro de una carpeta que pueda descargarse públicamente.
Por ejemplo, dejar una copia de base de datos en el directorio público puede introducir un riesgo adicional si el servidor permite acceder a ella.
Pregunta a tu proveedor dónde conserva las copias, cada cuánto tiempo se realizan y si ha probado su restauración.
También es recomendable disponer de una copia independiente del servidor principal cuando la importancia de la información lo justifique.
En nuestro artículo ¿Tu hosting tiene copias de seguridad? explicamos cómo evaluar los respaldos internos y externos, sus límites y las pruebas de recuperación.
9. Revisa señales de intrusión, no solamente ataques bloqueados
Un contador de solicitudes bloqueadas en Cloudflare no ofrece una fotografía completa de lo que ocurre dentro de WordPress.
Conviene observar también los registros del servidor y el comportamiento de la aplicación.
Algunas señales que merecen investigación son la aparición de administradores desconocidos, plugins que nadie recuerda haber instalado, cambios inesperados de archivos o redirecciones hacia páginas ajenas.
También pueden resultar relevantes los errores repetidos, los procesos inusuales y las modificaciones no autorizadas en contenidos o configuraciones.
Ninguno de esos síntomas demuestra por sí solo que exista una infección. Deben examinarse junto con otras evidencias.
Si sospechas que WordPress ya fue comprometido, evita borrar archivos desconocidos a ciegas.
Eliminar una pieza de malware sin entender cómo ingresó el atacante puede dejar abierta la misma vía de acceso.
Antes de limpiar o actualizar un sitio comprometido, conviene preservar evidencias, preparar respaldos y definir una recuperación segura.
Qué revisar primero si no tienes conocimientos técnicos
No necesitas convertirte en administrador de servidores para empezar.
Puedes realizar una primera comprobación con las siguientes prioridades:
Prioridad
Qué comprobar
A quién corresponde
Alta
Actualizaciones de WordPress, temas y plugins
Propietario o encargado de la web
Alta
Estado del proxy y reglas WAF de Cloudflare
Administrador de Cloudflare
Alta
Acceso directo al servidor de origen
Proveedor de hosting o administrador
Alta
Existencia y recuperación de backups
Proveedor y propietario
Media
Modo SSL/TLS y certificado del origen
Proveedor o administrador
Media
Usuarios y permisos de WordPress
Administrador de WordPress
Media
Versión PHP y correcciones de seguridad
Proveedor de hosting
Continua
Revisión de alertas y registros
Responsable técnico
Si tienes un hosting compartido, no intentes aplicar configuraciones de firewall que corresponden al servidor completo.
Un mismo equipo puede alojar muchos clientes. Una modificación global necesita evaluar su impacto sobre todos ellos.
Lo más útil es pedir al proveedor información clara sobre los controles instalados y las responsabilidades de mantenimiento.
¿Cloudflare gratis es suficiente para proteger WordPress?
El plan gratuito proporciona protecciones útiles, incluidas determinadas reglas administradas y mecanismos para mitigar tráfico malicioso.
Pero la pregunta correcta no es si un plan gratuito es bueno o malo.
La pregunta es qué riesgos necesitas controlar y si tu configuración realmente cubre esos escenarios.
Una página corporativa pequeña, una tienda que procesa pedidos y una aplicación con información sensible pueden requerir medidas diferentes.
Pagar por un plan superior tampoco corrige automáticamente un plugin vulnerable, una contraseña robada o un servidor mal administrado.
Las funciones adicionales pueden ayudar, pero requieren configuración y una estrategia de seguridad coherente.
Cloudflare y WordPress funcionan mejor como capas complementarias
Cloudflare puede ser una barrera importante frente a muchos ataques web. Sus intervenciones durante las vulnerabilidades de WordPress de julio y septiembre de 2026 muestran el valor de contar con protecciones que se actualizan rápidamente.
Pero ninguna capa de seguridad debe convertirse en una excusa para descuidar las demás.
El propietario necesita una instalación actualizada, cuentas protegidas, copias recuperables y un proveedor que mantenga correctamente el servidor.
El administrador técnico debe asegurarse de que el tráfico esperado atraviese las medidas de seguridad y de que no existan accesos directos innecesarios.
Y cuando se detecte un incidente, es necesario investigar qué sucedió realmente, no limitarse a comprobar cuántas solicitudes bloqueó el firewall.
Si utilizas WordPress y no sabes si tu configuración cumple estas condiciones, comienza por pedir una revisión de los nueve puntos anteriores.
La seguridad no consiste en tener más herramientas instaladas. Consiste en saber qué protege cada una, dónde termina su responsabilidad y cómo se complementan cuando aparece un problema.