El estado de la seguridad WordPress en 2026: lecciones de 10.000 auditorías
Datos agregados y anonimizados — los números que todo freelance y agencia debería conocer antes de hablar de seguridad con sus clientes.
- El 72 % de los sitios WordPress exponen públicamente su número de versión — una corrección trivial que elimina una señal de focalización clave para los atacantes
- Las vulnerabilidades de plugins representan el 52 % de todos los problemas de seguridad WordPress identificados en las auditorías
- La mayoría de las correcciones toman menos de 30 minutos — el problema no es la complejidad técnica, sino la visibilidad
Al auditar miles de sitios WordPress, emergen patrones. No teorías — cifras. URLs reales, configuraciones reales, errores reales que se repiten de manera predecible de un sitio a otro.
Este artículo presenta datos agregados y anonimizados del análisis de sitios WordPress en 2026. El objetivo no es señalar a los propietarios de sitios, sino documentar el estado real de la seguridad WordPress en la práctica — lejos de los discursos de marketing y las listas genéricas.
Para los freelancers y las agencias web, estas cifras son oro. Transforman una conversación abstracta sobre "seguridad" en argumentos factuales y concretos, difíciles de ignorar para un cliente potencial.
Panorama general: WordPress, objetivo principal de la web
WordPress representa el 62,8 % del mercado de CMS en 2026. Es a la vez su fortaleza y su debilidad: la omnipresencia de WordPress lo convierte en el objetivo número uno de los actores maliciosos automatizados.
Las actualizaciones automáticas del núcleo de WordPress han mejorado significativamente la seguridad del núcleo desde WordPress 5.5. La gran mayoría de las instalaciones del núcleo están ahora actualizadas. El problema se ha desplazado — hacia plugins, temas y configuraciones.
La realidad de los sitios auditados: la mayoría son "suficientemente seguros" en el sentido de que aún no han sido comprometidos. Pero "aún no comprometido" no es lo mismo que "seguro." Los vectores de ataque están abiertos, simplemente esperando que un bot automatizado los encuentre.
El alojamiento juega un papel importante. Los sitios en alojamiento compartido de bajo coste muestran sistemáticamente más problemas de configuración que los de alojamiento gestionado o VPS dedicado. La correlación es fuerte y constante.
Los 5 problemas de seguridad más frecuentes
Entre todos los tests de seguridad ejecutados en nuestras auditorías, cinco problemas reaparecen de manera estadísticamente dominante. Aquí están los números, con lo que significan en la práctica.
1. Versión de WordPress expuesta — 72 % de los sitios
La etiqueta meta generator, el archivo readme.html y la cabecera X-Powered-By suelen revelar la versión exacta de WordPress instalada. Para un atacante, es el primer filtro: "este sitio usa WP 6.4.2, aquí están los CVEs conocidos para esa versión." Corrección: eliminar la etiqueta generator en functions.php, bloquear readme.html e install.php.
2. Plugins obsoletos con CVEs conocidos — 48 % de los sitios
Casi la mitad de los sitios auditados tienen al menos un plugin con una vulnerabilidad conocida y documentada en bases de datos CVE. Tiempo mediano desde que el parche disponible fue lanzado: 47 días. En otras palabras: la corrección existía desde hace 47 días de media, y nadie la había aplicado.
3. Cabeceras de seguridad ausentes — 65 % de los sitios
Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy — estas cabeceras HTTP están ausentes en dos tercios de los sitios WordPress auditados. Sin embargo, su configuración solo requiere unas pocas líneas en .htaccess o la configuración nginx. La relación esfuerzo/protección es excepcionalmente favorable.
4. XML-RPC habilitado — 78 % de los sitios
XML-RPC es una API heredada de WordPress que permite la ejecución remota de comandos. Está habilitada por defecto y raramente deshabilitada. Resultado: el 78 % de los sitios exponen un vector de ataque de fuerza bruta que puede ejecutar miles de intentos de inicio de sesión en una sola solicitud HTTP mediante el método system.multicall.
5. Listado de directorios activo — 23 % de los sitios
En uno de cada cuatro sitios WordPress, la navegación por directorios está habilitada en el servidor. Esto permite a cualquiera listar el contenido de /wp-content/uploads/, /wp-content/plugins/ y otras carpetas sensibles. Es una línea en el .htaccess: Options -Indexes.
SSL y HTTPS: casi ahí, pero no del todo
Rendimiento y seguridad: dos caras del mismo problema
Un ángulo a menudo descuidado: los sitios lentos y los sitios inseguros tienden a ser los mismos sitios. No es una coincidencia — es una correlación causal.
Un TTFB alto (Time To First Byte superior a 1 segundo) indica típicamente un alojamiento compartido de bajo coste sobrecargado. Estos alojamientos también suelen tener configuraciones PHP y de servidor por defecto que no aplican las mejores prácticas de seguridad: expose_php activado, open_basedir demasiado permisivo, sin ModSecurity.
Las páginas pesadas — más de 4 MB — son a menudo señal de un sitio con mantenimiento mínimo. Y un sitio que no se actualiza desde hace 6 meses tiene, de media, 3 veces más probabilidad de tener plugins con CVEs conocidos que un sitio actualizado regularmente.
En resumen: cuando auditas el rendimiento de un sitio, también obtienes señales sobre su nivel de mantenimiento — y por tanto sobre su nivel de seguridad. Por eso Orilyt combina los tests de rendimiento y seguridad en una auditoría unificada.
La brecha de mantenimiento: el verdadero problema
Entre los sitios auditados, una proporción significativa no había sido actualizada desde hace más de 6 meses. Plugins, temas, núcleo de WordPress — sin actualizaciones durante al menos 180 días.
La correlación entre la ausencia de contrato de mantenimiento y las puntuaciones de seguridad bajas es fuerte y constante. Los sitios con un proveedor activo tienen puntuaciones de seguridad significativamente mejores — no porque el proveedor haga milagros, sino porque las actualizaciones regulares eliminan mecánicamente la gran mayoría de las vulnerabilidades conocidas.
Para los freelancers, este dato es un argumento comercial directo: "Sin un contrato de mantenimiento, tu sitio tiene X % de probabilidad de tener una vulnerabilidad conocida sin parche en los próximos 6 meses." No es una hipótesis — es un número basado en datos reales.
Los clientes que han sufrido un ataque o un hackeo son casi universalmente receptivos. Los que nunca han tenido problemas son más difíciles de convencer. Los datos agregados hacen tangible el riesgo antes de que se materialice.
Lo que esto significa para freelancers y agencias
Cada estadística de este artículo es un punto de partida para una conversación con un cliente. La diferencia entre un freelance que dice "tu sitio no es seguro" y otro que dice "el 72 % de los sitios WordPress exponen su versión, y el tuyo es uno de ellos — esto es lo que significa en la práctica" es enorme.
Los datos transforman una opinión en un hallazgo factual. Y los hallazgos factuales, documentados y listos para presentar, cierran contratos. Eso es exactamente lo que Orilyt produce para cada auditoría: no una puntuación genérica, sino tests individuales con recomendaciones FIA (Hecho, Impacto, Acción) listas para pegar en un informe para el cliente.
La oportunidad concreta: el mantenimiento recurrente. Una auditoría revela problemas. Los problemas requieren mantenimiento. El mantenimiento genera ingresos recurrentes. El ciclo es simple, pero necesita iniciarse con datos que den al cliente una razón para actuar.
Las cifras de este artículo no están pensadas para asustar — están pensadas para educar. Un cliente educado comprende el valor de tu experiencia. Y un cliente que comprende el valor de tu experiencia se convierte en un cliente que paga por ella.
La lista de las 5 correcciones prioritarias
Si necesitas priorizar, estas son las 5 acciones con mayor impacto de seguridad en relación al tiempo invertido.
- Ocultar la versión de WordPress: eliminar la etiqueta meta generator, bloquear readme.html e install.php en .htaccess
- Deshabilitar XML-RPC: una línea en functions.php — add_filter('xmlrpc_enabled', '__return_false')
- Añadir cabeceras de seguridad: X-Frame-Options, X-Content-Type-Options, Referrer-Policy en .htaccess o wp-config
- Actualizar plugins y temas: activar actualizaciones automáticas para versiones menores, programar las mayores
- Desactivar el listado de directorios: añadir Options -Indexes en el .htaccess raíz
La seguridad WordPress en 2026: una oportunidad, no una fatalidad
El estado de la seguridad WordPress en 2026 no es catastrófico — pero está lejos de ser satisfactorio. La gran mayoría de los problemas identificados en las auditorías son problemas conocidos, documentados, con correcciones simples y rápidas.
El verdadero problema no es técnico. Es un problema de visibilidad y priorización. Los propietarios de sitios no saben que su versión está expuesta. Nunca han oído hablar de XML-RPC. No saben que les faltan cabeceras de seguridad.
Ahí es donde los freelancers y las agencias tienen un papel crucial. No como vendedores del miedo, sino como traductores — convirtiendo el riesgo técnico en lenguaje de negocio. Y para traducir, necesitas datos. Orilyt proporciona los datos.