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 única ficha de proveedor.
Lo esencial en un parrafo
- 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 instalacion, ciclos de parches no alineados y el dueño del sitio como integrador de ultima instância.
- 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 métricas principales del informe GuardingWP 2026 son observables desde fuera del sitio. Un escaner 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 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 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 ultima instância. 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 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 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 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 está 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 día 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 está 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 está 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 día 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 más 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 código 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 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 unico 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. Tambien son lo que una auditoria DORA real parece.
Donde el informe GuardingWP es demasiado silencioso
Las cifras principales del informe están 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 más 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 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”. 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 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 exfiltracion 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 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 línea 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 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 descripcion fiel de ese patrón. 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 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 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 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 quién 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 (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
