53 por ciento de los sitios WordPress con CVE sin parchear: lo que la auditoría GuardingWP 2026 demuestra realmente
Más de la mitad. El primer informe State of WordPress Security 2026 de GuardingWP, extraído del escaneo de 424 instalaciones WordPress confirmadas en más de cuarenta sectores, indica que el 53 por ciento de los sitios ejecuta al menos un plugin que arrastra una CVE conocida sin parchear. El mismo informe sitúa al 93,2 por ciento sin cabeceras de seguridad modernas, al 55,9 por ciento filtrando la versión de WordPress por la meta tag generator y al 35,8 por ciento sirviendo todavía XML-RPC.
Las cifras no sorprenden. Lo que sorprendería sería un resultado por debajo del treinta por ciento, porque la estructura de la economía de plugins de WordPress devuelve esa tasa por defecto. Este artículo lee los datos de GuardingWP como prueba de que la cura no es un mejor firewall, sino los controles de cadena de suministro ya escritos en NIS2 artículo 21 apartado 2 letra d) y DORA artículo 28, con aplicación en España coordinada por INCIBE y CCN-CERT y supervisión financiera del Banco de España.
Este texto convive con nuestros pilares sobre NIS2 y DORA en WordPress: la stack de cumplimiento 2026 y sobre cadena de suministro de plugins WordPress, y complementa el trabajo sobre WCAG, BFSG y EAA, porque los equipos de compras agrupan hoy accesibilidad, seguridad y resiliencia en una única ficha de proveedor.
Lo esencial en un párrafo
- GuardingWP 2026 escaneó 424 instalaciones WordPress confirmadas en más de 40 sectores. Los cuatro resultados principales son detectables desde una única respuesta HTTP por sitio.
- 53 por ciento de los sitios con al menos una CVE de plugin sin parchear. 93,2 por ciento sin cabeceras modernas. 55,9 por ciento con fuga de versión. 35,8 por ciento con XML-RPC abierto.
- La tasa del 53 por ciento no es descuido del usuario. Es el resultado por defecto de una economía de plugins con 20 a 40 proveedores terceros por instalación, ciclos de parches no alineados y el dueño del sitio como integrador de última instancia.
- WordPress 7.0 añadió infraestructura de IA y por tanto claves API a la superficie de secretos del admin. Oliver Sild, de Patchstack, predijo públicamente una “absolute rush by hackers to steal API keys”.
- NIS2 artículo 21 apartado 2 letra d) y DORA artículo 28 ya codifican la cura: política documentada de gestión de vulnerabilidades, cadencia de parches, evaluación de proveedores, registro de acuerdos contractuales con terceros de TIC.
- La palanca que mueve a una organización WordPress del suspenso al aprobado en cumplimiento no es un plugin. Es un marco de controles.
Los números, con fuente
Las cuatro métricas principales del informe GuardingWP 2026 son observables desde fuera del sitio. Un escáner necesita solo la respuesta de la página de inicio y el estado HTTP de /xmlrpc.php para deducir cada una de ellas. Importa porque los auditores de cumplimiento parten cada vez más de la evidencia externa, y la telemetría de Patchstack, GreyNoise y el Internet Archive son infraestructuras de medición permanentes.
| Resultado | Cuota de las 424 instalaciones |
|---|---|
| Al menos un plugin con CVE conocida sin parchear | 53 por ciento |
| Sin cabeceras modernas (CSP, HSTS, X-Content-Type, Referrer-Policy) | 93,2 por ciento |
| Fuga de la versión de WordPress por meta tag generator | 55,9 por ciento |
| Endpoint XML-RPC expuesto | 35,8 por ciento |
Para el lector regulado en la UE, la referencia para cada uno de los cuatro números es distinta. CSP y HSTS aparecen en las buenas prácticas de ENISA para la seguridad de sistemas expuestos a internet. La exposición de XML-RPC está señalada explícitamente en OWASP Top 10. Las CVE de plugin sin parchear se asignan directamente al artículo 21 de NIS2 sobre control de cadena de suministro. El informe GuardingWP no es una lista de curiosidades. Es la medición de cuatro huecos de cumplimiento ya codificados.
Por qué 53 por ciento es una cifra estructural
Un sitio WordPress típico ejecuta entre veinte y cuarenta plugins. WordPress.org publica más de 60 000 plugins, con una larga cola de autores sin equipos de seguridad financiados. El ciclo de parches del plugin A y del plugin B no está coordinado. El dueño del sitio es el integrador de última instancia. Cuando CVE-2025-XYZW aterriza en el plugin A un martes, el dueño del sitio es la única parte que puede decidir si parchea, si testea contra el resto de la stack y si el parche rompe el plugin B.
La economía de la situación no favorece al integrador. Parchear veinte plugins al mes con test de regresión es trabajo de ingeniería. La mayoría de los sitios WordPress no tienen presupuesto para ese trabajo. Por eso la mayoría de los sitios WordPress no se parchean. La tasa del 53 por ciento es el equilibrio del mercado.
Hay dos salidas de este equilibrio, y solo una es duradera.
La primera vía es encoger la stack de plugins. Un sitio WordPress con ocho plugins, todos bajo mantenimiento activo, todos delimitados individualmente a una función que el dueño puede describir en una frase, es una superficie de parches tratable. La disciplina cuesta más al principio porque el equipo debe construir la función en código propio o vivir sin ella, pero el coste mensual de mantenerse al día con los parches cae en proporción.
La segunda vía es externalizar la cadencia de parches a un proveedor gestionado que realmente lo hace. Es lo que entregan los hostings WordPress gestionados serios y las agencias serias, donde el contrato dice de forma explícita “aplicamos parches de seguridad dentro de X horas tras la publicación del proveedor, primero en staging, luego en producción”. Si el contrato no dice eso, la cadencia no existe, y el sitio está estadísticamente en el 53 por ciento.
Qué cambió WordPress 7.0
WordPress 7.0 “Armstrong” salió en la misma semana de publicación que el informe GuardingWP. La versión 7.0 añadió el AI Services Registry y la Abilities API, lo que significa que la superficie del admin guarda ahora claves API para proveedores de modelos alojados (Anthropic, OpenAI), pasarelas IA (Vercel) y endpoints autoalojados. Estas claves tienen un lado facturable. Una credencial de admin comprometida ha dejado de ser solo un problema de integridad de contenido. También es un problema de fuga de costes.
El fundador de Patchstack, Oliver Sild, escribió públicamente en X el día del lanzamiento: “there will be an absolute rush by hackers to steal API keys.”
Justin Nealey, escribiendo en su blog, señaló el dolor de cabeza práctico asociado: el WP AI Client no tiene throttle integrado, y varios plugins compartiendo una clave API pueden agotar el límite de tokens en menos de un minuto. No es un adversario hipotético, es una mala configuración bienintencionada. Las dos formas de fuga de costes implican el mismo control: scoping de claves por conector, límites de tasa en la pasarela y no en el plugin, log de auditoría que saque a la superficie consumo inesperado de tokens dentro de un ciclo de facturación.
La superficie de control está bien entendida. Es la misma que un equipo financiero aplicaría a cualquier credencial facturable recién emitida. WordPress solo es inusual en que históricamente no ha tenido esta categoría de credencial en el admin.
Cómo lee NIS2 los datos de GuardingWP
La Directiva NIS2 (2022/2555), artículo 21, apartado 2, lista diez medidas técnicas y organizativas que las entidades esenciales e importantes deben aplicar. La letra d), con las palabras de la propia directiva, exige “la seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos”. Una instalación WordPress con CVE de plugin sin parchear suspende la letra d) con independencia de si el plugin es individualmente crítico, porque la entidad no ha evaluado ni gestionado el riesgo del proveedor.
La cura bajo NIS2 es procedimental. Incluye:
- Una política documentada de gestión y divulgación de vulnerabilidades que la entidad efectivamente sigue. Apartado 2 letra b).
- Una cadencia de parches y actualizaciones con un tiempo objetivo para aplicar correcciones calificadas como CVE. Apartado 2 letra f) en conjunción con la letra b).
- Una evaluación de proveedores que cubra a los autores de plugins en tanto proveedores terceros de TIC, incluida su madurez de seguridad, su canal de divulgación y su latencia de parches. Apartado 2 letra d).
- Un registro de acuerdos con terceros de TIC, que bajo DORA tiene además una obligación explícita del artículo 28 para entidades financieras.
Un sitio WordPress puede pasar la lectura técnica de NIS2 (es decir, no tener CVE de plugin sin parchear en el día de la auditoría) y aun así suspender la lectura procedimental si la entidad no puede mostrar los documentos. La tasa del 53 por ciento sugiere que los documentos no existen para la mitad de los sitios en ámbito.
En España la aplicación se articula a través del INCIBE, referencia para el sector privado y la ciudadanía, y del CCN-CERT para el sector público, con obligación de notificación de incidentes para operadores de servicios esenciales y entidades importantes. La vertiente RGPD sigue bajo la AEPD, y el Banco de España supervisa DORA. Un perfil del 53 por ciento en la cartera de plugins de una entidad en el ámbito KSC equivalente español no es solo riesgo operativo, es riesgo regulatorio claro.
Esa es la parte de la conversación que la mayoría de fabricantes de herramientas de seguridad evita. Vender un firewall es más fácil que vender un marco de controles. El marco de controles es lo que NIS2 realmente exige.
Cómo lee DORA los datos de GuardingWP para entidades financieras
El Reglamento DORA (2022/2554) es directamente aplicable desde el 17 de enero de 2025. Se aplica a entidades de crédito, entidades de pago, aseguradoras, empresas de servicios de inversión, proveedores de servicios de criptoactivos y aproximadamente quince categorías adicionales listadas en el artículo 2. Para entidades españolas, la supervisión es del Banco de España.
El artículo 28 de DORA regula la gestión del riesgo de terceros de TIC. Los autores de los plugins WordPress del sitio público de una entidad financiera entran en esa definición. Del perfil GuardingWP se derivan dos consecuencias prácticas.
Primero, la entidad debe mantener un registro de acuerdos contractuales con proveedores terceros de TIC (artículo 28 apartado 3). Este registro debe cubrir a los editores de plugins cuyo código se ejecuta en el sitio público. Para la mayoría de las entidades financieras este registro no incluye actualmente en absoluto a los autores de plugins WordPress. La cura no es técnica, es administrativa: extraer la lista de plugins activos, mapear cada plugin a su editor, anexar el canal de gestión de vulnerabilidades y la latencia de parches del editor, y añadir la entrada al registro.
Segundo, el artículo 28 apartado 5 exige que los acuerdos contractuales con proveedores terceros de TIC que presten funciones críticas o importantes incluyan “estrategias de salida, en particular el establecimiento de un periodo de transición obligatorio adecuado”. Para un sitio WordPress que depende de un único plugin especializado para un flujo crítico (entrega de documento firmado, adaptador KYC, ensamblaje del PDF de informe regulatorio), la estrategia de salida debe existir por escrito. Rara vez existe.
No son controles glamurosos. Son papeleo. También son lo que una auditoría DORA real parece.
Dónde el informe GuardingWP es demasiado silencioso
Las cifras principales del informe están bien fundamentadas, pero el informe minusvalora una cosa que el lector práctico debe ver con claridad: la tasa del 53 por ciento se concentra en la larga cola de instalaciones de pequeños negocios y es mucho más baja en instalaciones con proveedor gestionado bajo contrato que cubra explícitamente el parcheo de seguridad. No tenemos la segmentación subyacente de GuardingWP, pero nuestra propia concentración de sitios WordPress bajo contrato de mantenimiento se lee de un solo dígito en tasa de CVE sin parchear en cualquier semana de auditoría.
La implicación no es que los hostings WordPress gestionados y las agencias centradas en seguridad sean perfectos. Es que el 53 por ciento de equilibrio es una media de mercado que mezcla dos poblaciones muy distintas. Un comprador que lea el informe no debería concluir “WordPress es inseguro”. Debería concluir: “los sitios WordPress sin marco de controles son inseguros, y el tamaño de la cola no gestionada es la mitad del mercado”.
Qué cambia si se toma en serio WordPress 7.0
La salida de WordPress 7.0 con infraestructura IA es una función forzosa útil para la cola no gestionada, porque la adición de claves API a la superficie del admin hace visible el caso de fuga de costes de una forma que XSS o la exfiltración de credenciales almacenadas nunca lo fueron. Una persona de finanzas a la que no movió “puede tener una CVE sin parchear” se mueve con “la factura de tu proveedor IA del mes pasado fue tres dígitos superior a lo habitual y no podemos justificar el tráfico”.
La superficie de control que cierra el riesgo de la clave IA cierra también gran parte del resto de los resultados GuardingWP, porque los controles se solapan:
- Cabeceras de seguridad modernas (CSP, HSTS, X-Content-Type, Referrer-Policy) en el edge. Un Cloudflare Worker o un bloque
.htaccess. Cierra la brecha del 93,2 por ciento. - Supresión de la meta tag generator. Un filtro. Cierra la brecha del 55,9 por ciento.
- XML-RPC desactivado o con límite de tasa en el edge. Una regla de firewall o una línea de
.htaccess. Cierra la brecha del 35,8 por ciento. - Scoping de claves API, límite de tasa por conector, alerta de anomalía en consumo de tokens. Nueva superficie de control. Cierra el riesgo del 7.0 antes de que tenga escala.
No son tareas de ingeniería heroicas. Son partidas en un alcance de servicios gestionados.
Una lectura de profesional
Realizo auditorías de seguridad de sitios WordPress bajo jurisdicciones de la UE desde hace quince años. El patrón de la semana en 2026 es el mismo que en 2018: un sitio llega con veintiocho plugins, el dueño no puede listar lo que hacen ocho de ellos, y la carga de test de regresión para parchear todo en un ciclo excede el presupuesto. La tasa GuardingWP es una descripción fiel de ese patrón. La cura que realmente funciona en un horizonte de un año es la que a nadie le gusta:
- Auditar la lista de plugins. Elimina cada plugin cuya función el dueño no pueda describir en una frase.
- Sustituye los dos o tres plugins que sobrevivan pero tengan canales de mantenimiento estancados.
- Establece una cadencia documentada de parches y una política de gestión de vulnerabilidades. Ponlo por escrito. Refiérete a ella por nombre en el contrato de mantenimiento.
- Añade un registro de acuerdos con terceros de TIC que refleje la lista activa de plugins y se actualice con cada alta o baja de plugin.
- Para instalaciones en WordPress 7.0, delimita cada clave de proveedor IA por conector, aplica límites de tasa en la pasarela y alerta sobre anomalías en el consumo de tokens.
Los cuatro primeros son trabajo de cumplimiento bajo el artículo 21 de NIS2. El quinto es la nueva clase de control introducida por 7.0. Ninguno de los cinco se compra como producto a un proveedor. Es como aparece el profesional de WordPress en el trabajo.
Argumento de cierre
El informe GuardingWP 2026 es el documento individual más útil que la comunidad de seguridad WordPress ha publicado en cinco años, porque replantea un debate que llevaba demasiado tiempo atrapado en modo de comparación de herramientas. La lectura correcta no es “pásate a Patchstack” o “instala Wordfence”. Es: la mitad del mercado no opera un marco de controles, los controles que cierran la brecha están codificados en NIS2 y DORA, y el comprador en el extremo receptor de la regulación de la UE en 2026 es quien tiene la palanca para forzar los controles dentro del contrato de proveedor.
Para el lector desde una agencia WordPress, este es el momento comercial más fuerte en años para vender el marco, no la herramienta. La cifra del 53 por ciento es el titular del siguiente pitch de proveedor.
Fuentes
- GuardingWP, State of WordPress Security 2026 (página del informe)
- Directiva (UE) 2022/2555 sobre seguridad de redes y sistemas de información (NIS2), artículo 21
- Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero (DORA), artículo 28
- Patchstack
- ENISA: buenas prácticas para la seguridad de sistemas expuestos a internet
- INCIBE - Instituto Nacional de Ciberseguridad
- CCN-CERT
- AEPD - Agencia Española de Protección de Datos
- Banco de España
- OWASP Top 10 2021
Textos relacionados en este sitio
- Pilar: NIS2 y DORA en WordPress: la stack de cumplimiento 2026
- Cadena de suministro de plugins WordPress 2026: cuatro backdoors en un mes
- WCAG 2.2, BFSG y Ley Europea de Accesibilidad: la stack de cumplimiento 2026 para WordPress
- Auditoria de seguridad WordPress
- DORA artículo 28 riesgo de terceros de TIC: auditoría de proveedores de hosting y WAF WordPress
Última actualización: 2026-05-23
