Introducción
WordPress.org retiene hoy cada nuevo lanzamiento de plugin hasta seis horas antes de que llegue a las actualizaciones automáticas. Patchstack mide en cinco horas la mediana del tiempo entre la divulgación pública de una vulnerabilidad y su explotación masiva. Ambas cifras llevan en el registro público desde julio y nadie las ha puesto una al lado de la otra.
En resumen
- Seis horas es la espera actual de un lanzamiento de plugin o tema dentro de la iniciativa Protect the Shire. Arrancó el 5 de junio de 2026 con hasta 24 horas y se redujo a seis antes del 18 de julio de 2026.
- Cinco horas es la mediana hasta la explotación masiva de una vulnerabilidad de alto impacto, según el informe Patchstack, State of WordPress Security in 2026, del 25 de febrero de 2026.
- El 46 por ciento de las vulnerabilidades no tiene parche en el momento de la divulgación pública. La cifra procede del mismo informe y cambia el sentido de las dos anteriores.
- El registro público no dice si un parche de seguridad queda exento de la espera. El anuncio habla de cada nuevo lanzamiento y no establece distinción.
- La reducción a seis horas se anunció solo en Slack. Los autores de plugins se enteraron al lanzar.
- 11 334 nuevas vulnerabilidades en el ecosistema en 2025, un 42 por ciento más que el año anterior, y las fácilmente explotables subieron un 113 por ciento.
- El 12 por ciento de los ataques conocidos a WordPress lo detienen las configuraciones habituales de alojamiento y WAF. Esa cifra recorta el consejo que yo mismo doy más abajo.
De dónde salió la espera
En abril de 2026 salieron del directorio, de una sola vez, treinta y un plugins de una misma marca. Todos llevaban una puerta trasera. No se forzó nada: alguien compró los plugins en Flippa, heredó con ellos el acceso SVN y publicó una única actualización maliciosa disfrazada de parche de compatibilidad con WordPress 6.8.2.
Conviene descomponer el ataque en pasos, porque cada uno es legal por separado y solo juntos forman un compromiso. Comprar un plugin en un marketplace es legal. Heredar con él la cuenta del repositorio entra dentro de las reglas, porque así es un cambio de propietario. Publicar una actualización es el acto normal de un autor. Etiquetarla como parche de compatibilidad para una versión concreta de WordPress resulta creíble, porque esos parches salían de hecho en aquel momento. El alcance se reportó en hasta 400 000 sitios.
Ningún eslabón de la cadena parece sospechoso por sí solo, y ese es el punto. Un control basado en quién publica el código no tenía nada que detectar, porque lo publicó el propietario legítimo. Lo único detectable era lo que había dentro.
Este es un ataque a la cadena de suministro en su forma más pura, y el directorio no tenía respuesta, porque todo el modelo de confianza se apoyaba en que quien tiene acceso de commit es quien dice ser. Protect the Shire responde exactamente a ese escenario. Entre el commit y la distribución inserta una ventana en la que un análisis automático y una persona pueden mirar lo que está a punto de salir hacia millones de instalaciones.
Como respuesta a aquel ataque, la espera tiene sentido, y quiero decirlo claramente antes de pasar a la objeción. Seis horas entre un commit malicioso y la actualización automática son seis horas que antes no existían.
Dónde estas seis horas dejan de ayudar
La espera es neutral respecto al contenido del lanzamiento. No sabe si dentro va una función nueva, la corrección de una errata o un parche para una vulnerabilidad bajo explotación activa. El anuncio del 5 de junio habla de cada nuevo lanzamiento y no establece ninguna distinción. Tampoco encontré una fuente que describa una vía acelerada para lanzamientos de seguridad.
Quiero ser preciso aquí, porque es en este punto donde resulta fácil escribir algo falso. No afirmo que no exista una vía acelerada. Afirmo algo más débil y comprobable: no está documentada donde un autor de plugin la buscaría, es decir, en el anuncio y en las publicaciones públicas posteriores. Para un autor que acaba de recibir un informe de vulnerabilidad y prepara un lanzamiento de emergencia, una vía no documentada equivale en la práctica a ninguna vía.
Y ahí aterriza la segunda cifra. Patchstack sitúa en cinco horas la mediana hasta la explotación masiva de una vulnerabilidad de alto impacto, contadas desde la divulgación pública. Mediana, no media, así que la mitad de los casos va más rápido.
Poner las dos cifras una al lado de la otra exige cuidado, porque miden cosas distintas. Seis horas son un retraso en la distribución de una actualización. Cinco horas son el tiempo entre la divulgación y el ataque a escala. No se superponen con exactitud, y no afirmo que cada parche llegue una hora tarde. Afirmo que la ventana de protección del directorio es del mismo orden de magnitud que la ventana de ataque, y con esa proporción retener un lanzamiento deja de ser gratis.
La cifra que cambia las dos anteriores
El mismo informe de Patchstack indica que el 46 por ciento de las vulnerabilidades no tenía parche en el momento de la divulgación pública.
Esa cifra desplaza toda la discusión. En casi la mitad de los casos no hay nada que retener, porque todavía no existe lanzamiento. La espera no cuesta nada ahí, pero tampoco aporta nada, y lo único que protege un sitio es una capa que no espera al directorio: una regla de WAF, una función desactivada, un plugin desactivado.
En la práctica, el debate sobre las seis horas abarca algo más de la mitad de los casos. Para el resto la pregunta es otra, y el directorio no es parte en ella.
La escala que hace que seis horas importen
Seis horas suenan inofensivas hasta que se contrastan con el número de eventos que atraviesan esa ventana.
Patchstack contó 11 334 nuevas vulnerabilidades en el ecosistema WordPress en 2025, un 42 por ciento más que el año anterior. Son, de media, más de treinta al día. El aumento de volumen por sí solo sería llevadero si creciera de forma uniforme, pero no lo hace: las vulnerabilidades clasificadas como fácilmente explotables subieron un 113 por ciento interanual, es decir, se más que duplicaron.
Juntas, estas dos cifras cambian la naturaleza del problema. No es que haya más agujeros. Es que la parte que más crece es la que se explota sin esfuerzo, o sea, a escala y por máquina. Con ese perfil, una mediana de cinco horas hasta la explotación masiva deja de ser una curiosidad estadística y pasa a describir un día normal.
Bajo esa luz, una espera en el directorio es una de las pocas palancas que funcionan a escala. Un análisis automático que mira cada lanzamiento escala mejor que cualquier proceso que dependa de que un autor de plugin o un administrador reaccione a tiempo. Por eso considero que la dirección es correcta, y la discusión es solo si la ventana debe seguir ciega al contenido del lanzamiento.
Una corrección a mi propio consejo
Escribí arriba que hay que construir una capa que no espere al directorio, y señalé una regla de WAF. El mismo informe de Patchstack contiene una cifra que recorta ese consejo con fuerza, y no la voy a enterrar.
En pruebas de intrusión, las configuraciones habituales de alojamiento y WAF bloquearon el 12 por ciento de los ataques conocidos y explotados activamente específicos de WordPress, y el 26 por ciento de un conjunto de prueba más amplio. Ocho de cada diez ataques reales atraviesan lo que la mayoría de las agencias considera su capa de protección.
La distinción que salva el consejo es concreta y merece nombrarse. Un WAF genérico de alojamiento filtra patrones genéricos, intentos burdos de inyección SQL y escaneos de rutas. Una vulnerabilidad en un plugin concreto rara vez se parece a un ataque genérico. Parece una petición válida a un endpoint válido, con un parámetro puesto de una forma que el autor no previó. Una regla genérica no ve eso.
Una regla escrita contra un CVE concreto y ya divulgado es otra cosa, lo que el sector llama parcheo virtual. No necesita entender una clase de ataque, le basta la firma de este caso. Esa es la capa a la que me refería, y quiero ser preciso: el objetivo no es tener un WAF, sino tener un proceso para añadir una regla en horas desde la divulgación. Tener simplemente un WAF vale menos de lo que se supone.
Cabe además una salvedad honesta sobre la fuente. Patchstack vende parcheo virtual, así que una cifra que muestra débiles a los WAF genéricos le conviene. Eso no la hace falsa, y la metodología está descrita en el informe como pruebas de intrusión contra un conjunto conocido de exploits. Solo significa que la cifra debe leerse sabiendo quién la publica. Lo menciono para que nadie tenga que descubrirlo por su cuenta.
El lado del autor del plugin, que es la mitad del problema
Hasta aquí he escrito desde la posición de quien mantiene sitios ajenos. El autor de un plugin tiene el mismo problema invertido, y su versión es más dura, porque es él quien está contra el reloj.
El escenario es este. Recibes un informe de vulnerabilidad, normalmente a través de un programa de bug bounty o directamente de un investigador. Acordáis una fecha de divulgación, preparas el parche, pruebas, publicas el lanzamiento. Hasta junio de 2026 pasaban minutos entre el commit y la distribución. Ahora pasan hasta seis horas, y no existe forma documentada públicamente de acortarlo.
La consecuencia práctica es que la fecha acordada con el investigador necesita margen. Si acuerdas la divulgación para el lunes a las nueve, el lanzamiento tiene que salir el domingo por la noche, no el lunes a las ocho. Frente a una mediana de cinco horas hasta la explotación masiva, esa hora es real.
La segunda consecuencia tiene que ver con las guardias. El desarrollador Lopo lo resumió mejor que nadie: descubrir solo después del lanzamiento que había que reorganizar turnos para acompañar el despliegue. Quien publica un plugin con medio millón de instalaciones necesita a alguien mirando los reportes en las horas en que la actualización se propaga de verdad. Con una ventana móvil y no anunciada públicamente, eso no se planifica.
La tercera es más sutil. La espera cambia lo que significa un número de versión. Hasta ahora, publicar la 2.4.1 significaba que la 2.4.1 estaba en circulación. Ahora significa que lo estará, y mientras tanto lo que circula es la 2.4.0, es decir, la versión vulnerable de la que ya se sabe públicamente que es vulnerable. Las notas de lanzamiento tienen que contemplarlo, o “corregido en 2.4.1” será verdadero y engañoso a la vez.
Gandalf, o la confianza desplazada, no eliminada
La espera, por sí sola, no comprueba nada. Cuenta lo que ocurre durante ella, y en el anuncio ese papel recae en un análisis automático llamado Gandalf.
Conviene fijarse en qué cambió realmente en el modelo de confianza. Hasta abril, el directorio confiaba en quien tuviera el acceso SVN. Después de abril se sabe que ese acceso a veces se compra junto con el plugin, así que la confianza se retiró de ese lugar. No se eliminó, se desplazó a un análisis automático que juzga el contenido del lanzamiento.
Es la mejor solución, y lo digo claramente, porque un análisis automático no se compra en Flippa. Pero abre dos preguntas nuevas que el registro público no responde.
La primera es sobre los errores en sentido contrario. Un escáner que deja pasar un lanzamiento malicioso es el problema evidente. Un escáner que bloquea un lanzamiento legítimo es el problema más silencioso y, para el autor, más doloroso, porque no se sabe a quién recurrir ni cuánto tardará. No encontré ninguna descripción de un procedimiento de apelación.
La segunda es cuánto tarda el propio análisis. Si tarda veinte minutos, la ventana de seis horas es un noventa y cinco por ciento de margen y no de trabajo, y la propuesta de omitir la espera con resultado limpio resuelve prácticamente todo el problema. Si tarda cinco horas, es al revés. Esa única cifra cambia la conclusión y no está publicada.
Slack no es un canal de anuncios
La reducción de 24 a seis horas entró sin publicación pública. Ajay D’Souza la descubrió al lanzar un plugin antes del 18 de julio de 2026. Enrico Battocchi preguntó directamente cómo iban a enterarse de tales cambios y si habría una publicación. Un desarrollador llamado Lopo describió el coste operativo.
Este es un problema separado de la espera en sí y, en mi opinión, el más grave. Un autor de plugin planifica un lanzamiento de emergencia en torno a un retraso conocido. Si el retraso cambia sin aviso, la planificación se rompe en ambos sentidos. Unas veces esperas más de lo presupuestado, otras sale antes y nadie acompaña el despliegue.
Existe una propuesta en borrador para omitir la espera cuando el análisis Gandalf no encuentra nada. La versión analizada deja entonces de esperar y empieza a servirse. Eso resolvería la mayor parte del problema, porque un análisis limpio es la abrumadora mayoría de los lanzamientos. La propuesta está en revisión y no se ha implementado.
Qué hacer del lado del sitio
Si mantienes sitios de clientes, la espera en el directorio es una variable que no controlas. Hay cuatro que sí controlas.
No desactives las actualizaciones automáticas como reacción a este cambio. Es el reflejo más común y es lo contrario de lo que sostienen las cifras. La espera cuesta horas. Hacer clic a mano cuesta días y, en seis idiomas y decenas de sitios, cuesta semanas. Como la mitad de los fallos críticos se explota en las primeras 24 horas, tu propio tiempo de respuesta es el riesgo mayor.
Ayuda mirar la aritmética. La espera añade como mucho seis horas. Actualizar a mano una vez por semana da un retraso medio de unas ochenta y cuatro horas, catorce veces más. Incluso actualizar a mano cada día da una media de doce horas, todavía el doble de la ventana del directorio. Quien argumenta que la espera es demasiado arriesgada y por eso pasa al modo manual cambia seis horas por varias decenas.
Construye el proceso para añadir una regla, no solo el WAF. Tras la corrección de más arriba, este consejo se lee distinto de lo habitual. Tener un WAF de alojamiento detiene el doce por ciento de los ataques conocidos a WordPress, según las pruebas de Patchstack. El valor está en poder añadir una regla para un CVE concreto y recién divulgado en cuestión de horas. Es la diferencia entre un producto y un procedimiento, y aquí decide el procedimiento.
Ten por cliente una lista de los plugins críticos para el negocio y sabe cuál puedes apagar durante una hora. Desactivar un plugin de formularios hasta que llegue el parche es barato. Desactivar una pasarela de pagos no lo es. Esa distinción pertenece a un documento escrito antes del incidente, no durante. En la práctica es una columna en una hoja de cálculo, rellenada una vez al dar de alta el sitio.
Sabe por dónde te vas a enterar de una vulnerabilidad antes de enterarte por la monitorización. El canal de información cuenta aquí tanto como la capa técnica, porque frente a una mediana de cinco horas la diferencia entre saberlo por la mañana o por la noche es la diferencia entre un parche y un incidente. Un feed de vulnerabilidades leído a diario es más barato que cualquier herramienta y marca el techo de lo rápido que puedes reaccionar siquiera.
Qué no arregla este cambio
Conviene decir con claridad qué no toca la espera, porque es fácil sobrevalorarla.
No toca los plugins de fuera del directorio. Un plugin premium comprado directamente al autor o en un marketplace se actualiza por su propio canal, y ningún periodo de espera lo cubre. Una tienda WooCommerce típica corre varios de esos, a menudo los más sensibles, porque tocan pagos, envíos y datos de clientes.
Tampoco toca temas y plugins instalados a mano desde un archivo ZIP, ni el código del plugin de funcionalidades del propio cliente. Y es justo ahí donde suele estar la mayor deuda, en código escrito de forma apresurada y no tocado en años.
Por último, no toca el caso en que el problema no es el código en absoluto, sino la configuración: permisos demasiado amplios, una cuenta de administrador sin segundo factor, una clave de API en un repositorio. El directorio no tiene ningún papel ahí, y la proporción de estos casos en los incidentes reales es alta.
Lo que no sé
Tres cosas quedan abiertas, porque no tengo fuente para ellas y no voy a adivinar.
No sé si los lanzamientos de seguridad tienen una vía acelerada que no esté documentada públicamente. No sé cuánto tarda de verdad un análisis Gandalf completo, así que no sé qué parte de las seis horas es trabajo y qué parte es margen. No sé cuándo, ni si, se implementará la propuesta de omitir la espera con un análisis limpio.
En cuanto alguna de ellas se documente públicamente, actualizaré este artículo y fecharé el cambio.
Fuentes
- Protect The Shire, WordPress News, 5 de junio de 2026
- Patchstack, State of WordPress Security in 2026, 25 de febrero de 2026
- La reducción a seis horas y la reacción de los desarrolladores
Última verificación: 10 de agosto de 2026.
