53 por ciento de los sitios WordPress con CVE sin parchear: lo que la auditoria GuardingWP 2026 demuestra realmente
Mas de la mitad. El primer informe State of WordPress Security 2026 de GuardingWP, extraido del escaneo de 424 instalaciones WordPress confirmadas en mas 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 situa al 93,2 por ciento sin cabeceras de seguridad modernas, al 55,9 por ciento filtrando la version de WordPress por la meta tag generator y al 35,8 por ciento sirviendo todavia XML-RPC.
Las cifras no sorprenden. Lo que sorprenderia seria un resultado por debajo del treinta por ciento, porque la estructura de la economia de plugins de WordPress devuelve esa tasa por defecto. Este articulo 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 articulo 21 apartado 2 letra d) y DORA articulo 28, con aplicacion en Espana coordinada por INCIBE y CCN-CERT y supervision financiera del Banco de Espana.
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 unica ficha de proveedor.
Lo esencial en un parrafo
- GuardingWP 2026 escaneo 424 instalaciones WordPress confirmadas en mas de 40 sectores. Los cuatro resultados principales son detectables desde una unica 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 economia de plugins con 20 a 40 proveedores terceros por instalacion, ciclos de parches no alineados y el dueno del sitio como integrador de ultima instancia.
- WordPress 7.0 anadio infraestructura de IA y por tanto claves API a la superficie de secretos del admin. Oliver Sild, de Patchstack, predijo publicamente una “absolute rush by hackers to steal API keys”.
- NIS2 articulo 21 apartado 2 letra d) y DORA articulo 28 ya codifican la cura: politica documentada de gestion de vulnerabilidades, cadencia de parches, evaluacion de proveedores, registro de acuerdos contractuales con terceros de TIC.
- La palanca que mueve a una organizacion WordPress del suspenso al aprobado en cumplimiento no es un plugin. Es un marco de controles.
Los numeros, con fuente
Las cuatro metricas principales del informe GuardingWP 2026 son observables desde fuera del sitio. Un escaner necesita solo la respuesta de la pagina de inicio y el estado HTTP de /xmlrpc.php para deducir cada una de ellas. Importa porque los auditores de cumplimiento parten cada vez mas de la evidencia externa, y la telemetria de Patchstack, GreyNoise y el Internet Archive son infraestructuras de medicion 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 numeros es distinta. CSP y HSTS aparecen en las buenas practicas de ENISA para la seguridad de sistemas expuestos a internet. La exposicion de XML-RPC esta senalada explicitamente en OWASP Top 10. Las CVE de plugin sin parchear se asignan directamente al articulo 21 de NIS2 sobre control de cadena de suministro. El informe GuardingWP no es una lista de curiosidades. Es la medicion de cuatro huecos de cumplimiento ya codificados.
Por que 53 por ciento es una cifra estructural
Un sitio WordPress tipico ejecuta entre veinte y cuarenta plugins. WordPress.org publica mas 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 esta coordinado. El dueno del sitio es el integrador de ultima instancia. Cuando CVE-2025-XYZW aterriza en el plugin A un martes, el dueno del sitio es la unica parte que puede decidir si parchea, si testea contra el resto de la stack y si el parche rompe el plugin B.
La economia de la situacion no favorece al integrador. Parchear veinte plugins al mes con test de regresión es trabajo de ingenieria. La mayoria de los sitios WordPress no tienen presupuesto para ese trabajo. Por eso la mayoria 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 funcion que el dueno puede describir en una frase, es una superficie de parches tratable. La disciplina cuesta mas al principio porque el equipo debe construir la funcion en codigo propio o vivir sin ella, pero el coste mensual de mantenerse al dia con los parches cae en proporcion.
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 explicita “aplicamos parches de seguridad dentro de X horas tras la publicacion del proveedor, primero en staging, luego en produccion”. Si el contrato no dice eso, la cadencia no existe, y el sitio esta estadisticamente en el 53 por ciento.
Que cambio WordPress 7.0
WordPress 7.0 “Armstrong” salio en la misma semana de publicacion que el informe GuardingWP. La versión 7.0 anadio 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. Tambien es un problema de fuga de costes.
El fundador de Patchstack, Oliver Sild, escribio publicamente en X el dia del lanzamiento: “there will be an absolute rush by hackers to steal API keys.”
Justin Nealey, escribiendo en su blog, senalo el dolor de cabeza practico asociado: el WP AI Client no tiene throttle integrado, y varios plugins compartiendo una clave API pueden agotar el limite de tokens en menos de un minuto. No es un adversario hipotetico, es una mala configuracion bienintencionada. Las dos formas de fuga de costes implican el mismo control: scoping de claves por conector, limites de tasa en la pasarela y no en el plugin, log de auditoria que saque a la superficie consumo inesperado de tokens dentro de un ciclo de facturacion.
La superficie de control esta bien entendida. Es la misma que un equipo financiero aplicaria a cualquier credencial facturable recien emitida. WordPress solo es inusual en que históricamente no ha tenido esta categoria de credencial en el admin.
Como lee NIS2 los datos de GuardingWP
La Directiva NIS2 (2022/2555), articulo 21, apartado 2, lista diez medidas tecnicas 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 instalacion WordPress con CVE de plugin sin parchear suspende la letra d) con independencia de si el plugin es individualmente critico, porque la entidad no ha evaluado ni gestionado el riesgo del proveedor.
La cura bajo NIS2 es procedimental. Incluye:
- Una politica documentada de gestion y divulgacion 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 conjuncion con la letra b).
- Una evaluacion de proveedores que cubra a los autores de plugins en tanto proveedores terceros de TIC, incluida su madurez de seguridad, su canal de divulgacion y su latencia de parches. Apartado 2 letra d).
- Un registro de acuerdos con terceros de TIC, que bajo DORA tiene ademas una obligacion explicita del articulo 28 para entidades financieras.
Un sitio WordPress puede pasar la lectura tecnica de NIS2 (es decir, no tener CVE de plugin sin parchear en el dia de la auditoria) y aun asi 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 ambito.
En Espana la aplicacion se articula a traves del INCIBE, referencia para el sector privado y la ciudadania, y del CCN-CERT para el sector publico, con obligacion de notificacion de incidentes para operadores de servicios esenciales y entidades importantes. La vertiente RGPD sigue bajo la AEPD, y el Banco de Espana supervisa DORA. Un perfil del 53 por ciento en la cartera de plugins de una entidad en el ambito KSC equivalente espanol no es solo riesgo operativo, es riesgo regulatorio claro.
Esa es la parte de la conversación que la mayoria de fabricantes de herramientas de seguridad evita. Vender un firewall es mas facil que vender un marco de controles. El marco de controles es lo que NIS2 realmente exige.
Como 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 credito, entidades de pago, aseguradoras, empresas de servicios de inversion, proveedores de servicios de criptoactivos y aproximadamente quince categorias adicionales listadas en el articulo 2. Para entidades espanolas, la supervision es del Banco de Espana.
El articulo 28 de DORA regula la gestion del riesgo de terceros de TIC. Los autores de los plugins WordPress del sitio publico de una entidad financiera entran en esa definicion. Del perfil GuardingWP se derivan dos consecuencias practicas.
Primero, la entidad debe mantener un registro de acuerdos contractuales con proveedores terceros de TIC (articulo 28 apartado 3). Este registro debe cubrir a los editores de plugins cuyo codigo se ejecuta en el sitio publico. Para la mayoria de las entidades financieras este registro no incluye actualmente en absoluto a los autores de plugins WordPress. La cura no es tecnica, es administrativa: extraer la lista de plugins activos, mapear cada plugin a su editor, anexar el canal de gestion de vulnerabilidades y la latencia de parches del editor, y anadir la entrada al registro.
Segundo, el articulo 28 apartado 5 exige que los acuerdos contractuales con proveedores terceros de TIC que presten funciones criticas o importantes incluyan “estrategias de salida, en particular el establecimiento de un periodo de transicion obligatorio adecuado”. Para un sitio WordPress que depende de un unico plugin especializado para un flujo critico (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. Tambien son lo que una auditoria DORA real parece.
Donde el informe GuardingWP es demasiado silencioso
Las cifras principales del informe estan bien fundamentadas, pero el informe minusvalora una cosa que el lector practico debe ver con claridad: la tasa del 53 por ciento se concentra en la larga cola de instalaciones de pequenos negocios y es mucho mas baja en instalaciones con proveedor gestionado bajo contrato que cubra explicitamente el parcheo de seguridad. No tenemos la segmentacion subyacente de GuardingWP, pero nuestra propia concentracion de sitios WordPress bajo contrato de mantenimiento se lee de un solo digito en tasa de CVE sin parchear en cualquier semana de auditoria.
La implicacion 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 deberia concluir “WordPress es inseguro”. Deberia concluir: “los sitios WordPress sin marco de controles son inseguros, y el tamano de la cola no gestionada es la mitad del mercado”.
Que cambia si se toma en serio WordPress 7.0
La salida de WordPress 7.0 con infraestructura IA es una funcion forzosa útil para la cola no gestionada, porque la adicion de claves API a la superficie del admin hace visible el caso de fuga de costes de una forma que XSS o la exfiltracion de credenciales almacenadas nunca lo fueron. Una persona de finanzas a la que no movio “puede tener una CVE sin parchear” se mueve con “la factura de tu proveedor IA del mes pasado fue tres digitos superior a lo habitual y no podemos justificar el trafico”.
La superficie de control que cierra el riesgo de la clave IA cierra tambien 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. - Supresion de la meta tag generator. Un filtro. Cierra la brecha del 55,9 por ciento.
- XML-RPC desactivado o con limite de tasa en el edge. Una regla de firewall o una linea de
.htaccess. Cierra la brecha del 35,8 por ciento. - Scoping de claves API, limite de tasa por conector, alerta de anomalia en consumo de tokens. Nueva superficie de control. Cierra el riesgo del 7.0 antes de que tenga escala.
No son tareas de ingenieria heroicas. Son partidas en un alcance de servicios gestionados.
Una lectura de profesional
Realizo auditorias de seguridad de sitios WordPress bajo jurisdicciones de la UE desde hace quince anos. El patron de la semana en 2026 es el mismo que en 2018: un sitio llega con veintiocho plugins, el dueno 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 descripcion fiel de ese patron. La cura que realmente funciona en un horizonte de un ano es la que a nadie le gusta:
- Auditar la lista de plugins. Elimina cada plugin cuya funcion el dueno 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 politica de gestion de vulnerabilidades. Ponlo por escrito. Refierete a ella por nombre en el contrato de mantenimiento.
- Anade 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 limites de tasa en la pasarela y alerta sobre anomalias en el consumo de tokens.
Los cuatro primeros son trabajo de cumplimiento bajo el articulo 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 mas útil que la comunidad de seguridad WordPress ha publicado en cinco anos, porque replantea un debate que llevaba demasiado tiempo atrapado en modo de comparacion de herramientas. La lectura correcta no es “pasate a Patchstack” o “instala Wordfence”. Es: la mitad del mercado no opera un marco de controles, los controles que cierran la brecha estan codificados en NIS2 y DORA, y el comprador en el extremo receptor de la regulacion 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 mas fuerte en anos 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 (pagina del informe)
- Directiva (UE) 2022/2555 sobre seguridad de redes y sistemas de información (NIS2), articulo 21
- Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero (DORA), articulo 28
- Patchstack
- ENISA: buenas practicas para la seguridad de sistemas expuestos a internet
- INCIBE - Instituto Nacional de Ciberseguridad
- CCN-CERT
- AEPD - Agencia Espanola de Proteccion de Datos
- Banco de Espana
- 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 articulo 28 riesgo de terceros de TIC: auditoria de proveedores de hosting y WAF WordPress
Ultima actualizacion: 2026-05-23
