En 90 días, el programa de seguridad de WordPress recibió 2004 informes de vulnerabilidades y pagó por ellos más de 90.000 dólares. Es casi la mitad de todo lo que ha pagado desde 2017. Hasta ahora lo costeaba una sola entidad, Automattic. El lunes 5 de octubre de 2026, Mary Hubbard, directora ejecutiva de WordPress, escribió a los responsables de más de 30 empresas para pedirles que aporten.
Cuento esto a partir del artículo de The Repository del 8 de octubre de 2026, que cita el correo de Hubbard (The Repository, 8 de octubre de 2026), y de los anuncios de wordpress.org. No he visto el correo en sí. Comprobé las cifras y las citas en las fuentes el 9 de octubre de 2026.
Qué pidió Mary Hubbard a las empresas de hosting y plugins
El correo llegó por la tarde, hora UTC, a los directivos de empresas de hosting, de plugins y de seguridad. The Repository habla de “el lunes por la tarde, hora UTC” (traducción propia) en su texto del jueves 8 de octubre. La tesis principal: la IA ha abaratado la búsqueda de fallos.
“La IA había hundido el coste de encontrar, notificar y explotar vulnerabilidades”
Mary Hubbard, citada por The Repository, 8 de octubre de 2026, traducción propia
Según ella, el programa recibió en 90 días casi 2000 informes, más que nunca, “y el ritmo sigue subiendo” (traducción propia). The Repository revisó la página del programa en HackerOne: 2004 informes y más de 90.000 dólares en recompensas en 90 días, frente a algo más de 200.000 dólares pagados desde el inicio en abril de 2017.
“Casi la mitad de todo lo pagado por el programa desde su inicio se pagó en un solo trimestre, y la curva solo va en una dirección.”
Mary Hubbard, citada por The Repository, 8 de octubre de 2026, traducción propia
Hubbard añade que Automattic financió el programa al 100 %: cada recompensa, el triaje, la verificación, las correcciones y las versiones de seguridad coordinadas para todas las ramas soportadas hasta WordPress 4.7. Pide una de tres cosas: una aportación a un fondo común de recompensas, patrocinar personas para el triaje y las versiones, u otra fórmula acordada entre todos. Subraya que parte del aumento es investigación genuina que, gracias a las nuevas herramientas, avanza más rápido y mejora de verdad la seguridad. El problema, según ella, es la economía, no el programa: “Lo que está roto es la economía, no el programa” (traducción propia).
Qué empresas recibieron la petición de financiar la seguridad de WordPress
Al frente de la lista de destinatarios estaban GoDaddy, Newfold Digital y Hostinger. The Repository menciona a continuación:
| Grupo | Empresas |
|---|---|
| Hostings y registradores | SiteGround, IONOS, DigitalOcean, DreamHost, World Host Group, Kinsta, OVHcloud, group.one, Namecheap, Tucows, Pantheon, Porkbun |
| Plugins y productos | Elementor, Awesome Motive, Incsub (WPMU DEV), Rocketgenius (Gravity Forms), Rank Math, Brainstorm Force, Extendify |
| Agencias enterprise | Human Made, rtCamp |
| Seguridad | Wordfence, Patchstack, BlogVault |
Fuente: The Repository, 8 de octubre de 2026.
No recibió el correo WP Engine, que desde 2024 mantiene un litigio con Automattic, aunque en los agradecimientos de las versiones de seguridad 7.0.2 y 7.1.1 se mencionó a representantes de WP Engine. Tampoco estaba en la lista Nexcess.
Cómo respondieron las empresas de hosting y plugins
Las que respondieron a The Repository están a favor, pero quieren saber exactamente a qué se comprometen.
- Hostinger (Marco Chiesi): se plantea ceder a algunas de sus personas. Desde julio colabora con el equipo de seguridad y despliega reglas de WAF antes de que se publiquen los parches.
- Kinsta (Jon Penland): quiere un programa “clearly defined” (claramente definido) al que las empresas puedan sumarse.
- Awesome Motive (Syed Balkhi): ya patrocina a varios colaboradores de los equipos de seguridad y de plugins, pero señala que la petición es “quite open-ended”.
- Human Made (Tom Willmot): patrocina a John Blackbourn, que representa al equipo de seguridad a tiempo completo. La agencia ya intentó antes reunir a empresas en torno a un fondo de seguridad, “por desgracia, sin mucha acogida” (traducción propia).
- Patchstack (Oliver Sild): la empresa ha pagado de su bolsillo 600.000 dólares en recompensas desde 2022, pero nunca ha sido admitida en los equipos de seguridad y de plugins de WordPress. En su opinión, “este proceso necesita una reforma” (traducción propia).
GoDaddy, Newfold Digital y Wordfence no habían respondido cuando se publicó el texto.
WordPress 7.1.4: 22 vulnerabilidades y qué significan para tu web
Actualización, . WordPress 7.1.4 salió el 28 de octubre. La página de la versión cuenta 22 vulnerabilidades. La más grave es una condición de carrera en el proceso de actualización del núcleo que, según quien la reportó, Umut Bayram, podía llevar a ejecución remota de código. La mayoría de las demás son XSS almacenados que requieren al menos una cuenta de colaborador. Dos reportes se atribuyen a Anthropic. Las correcciones se han llevado a ramas antiguas, de la 7.0.8 a la 4.7.39, y las webs con actualizaciones automáticas en segundo plano reciben el parche solas.
Es la séptima versión de seguridad del núcleo desde julio. En el balance de dos meses de la Core Security Initiative, Rudy Faile escribe que el equipo ha recibido más de 3000 reportes este año, más que en los doce años anteriores juntos, y que el 73 % de los 109 pasos de una versión de seguridad ya está automatizado. A ese ritmo, dejar la actualización de seguridad para el fin de semana deja de ser un hábito seguro. En mis actualizaciones de WordPress las versiones de seguridad pasan primero por staging y después a producción.
Qué corrige WordPress 7.1.3 y quién reportó los fallos
Un día después del correo, el 6 de octubre de 2026, salió WordPress 7.1.3 con 7 correcciones de seguridad y otras 4 correcciones de errores. En el anuncio, junto a cada corrección se indica quién la notificó:
| Vulnerabilidad | Quién puede explotarla | Notificada por |
|---|---|---|
| XSS almacenado en la página Comentarios del panel, mediante comentarios pendientes | Cualquiera que deje un comentario, si un moderador (Editor o superior) hace clic en un enlace del comentario | Trail of Bits en colaboración con OpenAI |
Denegación de servicio en WP_Http::make_absolute_url() | Cuenta de Colaborador o superior | Anthropic |
| Inyección SQL de segundo orden en la exportación WXR | Administrador que hace una exportación, con un valor erróneo de _thumbnail_id ya en la base de datos | Anthropic |
| Un Autor podía fijar entradas (sticky) | Cuenta de Autor o superior | Anthropic |
| Divulgación de comentarios de entradas privadas y no publicadas | Cualquiera, sin iniciar sesión | Ananda Dhakal, Patchstack |
| XSS en las incrustaciones de Imgur | Cuenta de Colaborador o superior y una víctima que vea la entrada | Zhengyu Liu, Jingcheng Yang, Gavin Zhong |
Parámetros falsificables del hook {status}_{type} | Plugin que pasa a wp_insert_post() un estado o tipo de entrada sin sanear | Alex Concha, equipo de seguridad de WordPress |
Fuentes: quién notificó cada fallo, según WordPress.org, 6 de octubre de 2026; condiciones de explotación, según Patchstack, 6 de octubre de 2026.
Solo uno de los siete fallos funciona sin ninguna cuenta y sin intervención de la víctima: la fuga de comentarios de entradas privadas. Patchstack explica el mecanismo: en el feed de comentarios de una entrada concreta, WordPress primero recuperaba los comentarios y solo después comprobaba si el visitante podía ver la entrada. La comprobación ocultaba la entrada, pero no los comentarios, y los feeds no devuelven 404, así que los comentarios acababan en el feed. Tres de los otros seis requieren una cuenta de Colaborador o de Autor.
Cuatro de las siete notificaciones proceden de empresas que construyen modelos de IA o de sus socios. Es una buena ilustración de la tesis de Hubbard: hoy los fallos también los encuentra la IA, y alguien tiene que pagar por cada uno de ellos el triaje, la corrección y la versión para cada rama soportada. El anuncio indica que las correcciones se trasladan a todas las ramas cubiertas por parches de seguridad, actualmente hasta la 4.7, y se publicarán a medida que estén listas.
Correcciones de seguridad de WordPress 7.1.1 y 7.1.2
Según Patchstack, dos semanas antes de la 7.1.3 salió la 7.1.2, que corrigió una vulnerabilidad (CVE-2026-87902). Permitía a un visitante sin iniciar sesión provocar la inclusión de un archivo local y, con una configuración de PHP adecuada, llevaba a la ejecución remota de código (Patchstack, 6 de octubre de 2026).
Antes, en septiembre, Patchstack describió también una vulnerabilidad de ejecución remota de código corregida en la 7.1.1. Si tu web sigue en la 7.1.0, le faltan las correcciones de tres versiones consecutivas.
Qué es la Core Security Initiative de WordPress
El 28 de agosto de 2026 el equipo de seguridad anunció en make.wordpress.org la Core Security Initiative (Make WordPress Security, 28 de agosto de 2026). El anuncio vincula el “substantial increase” en el número de informes con el rápido avance de los modelos de IA de frontera. Lo describe como un buen problema, que aun así exige escalar el triaje, la verificación y la corrección.
La iniciativa afecta al núcleo de WordPress. No incluye plugins ni temas. Los informes los recibe el programa de HackerOne, y las vulnerabilidades de WordPress.com y de las apps móviles van aparte, por el programa de Automattic.
Cómo filtran Patchstack y Wordfence los informes de vulnerabilidades de plugins generados por IA
Las cifras de HackerOne cubren solo el núcleo. Los fallos en plugins y temas pasan por otros programas, y en ellos se ve la misma curva. En marzo de 2026 el Wordfence Bug Bounty Program recibió 1.718 informes de vulnerabilidades, un 59,4 % más que en febrero, de 321 investigadores activos, y pagó 62.174 USD en recompensas ese mes (Wordfence, informe de marzo de 2026). El informe no dice cuántos de esos envíos se escribieron con ayuda de IA.
Patchstack nombra la causa sin rodeos. El 29 de mayo de 2026 Dave Jong, responsable de investigación de seguridad de la empresa, escribió que desde el auge de la investigación asistida por IA, sobre todo en 2026, el programa recibe más informes de bajo impacto que apenas cumplen los criterios, más duplicados (una sola vulnerabilidad acumuló más de 20 envíos duplicados de investigadores distintos) e informes basados en suposiciones erróneas generadas por IA (Patchstack, 29 de mayo de 2026). Desde el 1 de junio de 2026 Patchstack:
- sacó del alcance el rol de Colaborador (Contributor), así que el fallo tiene que ser accesible para un invitado, Suscriptor, Cliente o un rol bajo similar,
- puso condiciones a cada clase de vulnerabilidad, por ejemplo el XSS debe afectar a todo el sitio o ser reflejado,
- limitó el fondo mensual de recompensas a los 5 mejores investigadores,
- veta durante una semana a quien envíe suposiciones erróneas generadas por IA o un informe no probado contra el plugin o tema real.
Las directrices publicadas a 13 de octubre de 2026 exigen además una prueba de concepto en texto paso a paso, con peticiones HTTP en bruto y payloads exactos, y un componente con al menos 1.000 instalaciones activas (directrices del bug bounty de Patchstack).
Para el autor de un plugin este filtro pesa más que el presupuesto del núcleo. Un informe que supera el triaje de la plataforma acaba igualmente en manos del autor, que tiene que reproducirlo y publicar una corrección, normalmente sin cobrar nada de las recompensas.
Quién gestiona las vulnerabilidades de plugins y los CVE en WordPress.org
El directorio de plugins tiene su propia vía. El Plugin Handbook pide a quien informa que contacte primero con el desarrollador y, solo si eso falla, escriba a [email protected], sin publicar el problema. El equipo de plugins actúa entonces sobre la ficha: la mayoría de los plugins se cierran a nuevas descargas hasta que se resuelve el problema. La misma página indica que el equipo no ayuda a solicitar CVE por falta de recursos (Plugin Handbook, Reporting plugin security issues, última modificación el 2 de enero de 2026).
Por eso los identificadores CVE de los plugins de WordPress vienen sobre todo de empresas de seguridad registradas como CVE Numbering Authorities. La lista de socios del programa CVE asigna a Wordfence las vulnerabilidades en plugins, temas y núcleo descubiertas por su equipo o comunicadas a él, a WPScan el núcleo, los plugins y los temas de WordPress, y a Patchstack las vulnerabilidades halladas por su equipo y por los participantes de su bug bounty (CVE Program, lista de socios).
Estas empresas pagan el triaje de plugins con sus propios ingresos y venden protección encima. Wordfence escribe que los usuarios de Premium, Care y Response reciben reglas de cortafuegos en tiempo real y los de la versión gratuita a los 30 días. Es la segunda respuesta a quién paga: en plugins, el coste del triaje ya recae en los proveedores de seguridad, y dos de ellos, Wordfence y Patchstack, están en la lista de Hubbard.
Qué exige la Cyber Resilience Act de la UE a los fabricantes de plugins de WordPress
Desde el 11 de septiembre de 2026 parte de este coste es también una obligación legal en la UE. El Reglamento de Ciberresiliencia, Reglamento (UE) 2024/2847, se aplica en su totalidad desde el 11 de diciembre de 2027, pero su artículo 71, apartado 2, adelantó el artículo 14 sobre notificación al 11 de septiembre de 2026 (Reglamento (UE) 2024/2847, EUR-Lex). Un fabricante que tenga conocimiento de una vulnerabilidad activamente explotada en su producto debe notificarla al CSIRT designado como coordinador y a ENISA a través de una plataforma única de notificación:
| Paso | Plazo según el artículo 14, apartado 2 |
|---|---|
| Alerta temprana | 24 horas desde que tiene conocimiento |
| Notificación de la vulnerabilidad | 72 horas desde que tiene conocimiento |
| Informe final | 14 días después de que haya una corrección o medida de mitigación |
El artículo 3, punto 13, define al fabricante como quien desarrolla un producto y lo comercializa con su propio nombre o marca, a cambio de un pago, para monetizarlo o de forma gratuita. Una empresa que vende un plugin premium con su marca encaja directamente en esa redacción. El artículo 13, apartado 6, añade que el fabricante que detecte una vulnerabilidad en un componente integrado, también de código abierto, debe comunicarla a quien mantiene ese componente y compartir la corrección. Incumplir los artículos 13 y 14 puede costar hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial, si esta cifra es superior (artículo 64, apartado 2). Las microempresas y pequeñas empresas quedan exentas de multas solo por incumplir el plazo de 24 horas de la alerta temprana (artículo 64, apartado 10).
Los administradores de software de código abierto (open-source software stewards), personas jurídicas que apoyan de forma sistemática software libre destinado a actividades comerciales, tienen un régimen más ligero: una política de ciberseguridad documentada (artículo 24) y ninguna multa administrativa (artículo 64, apartado 10, letra b). El reglamento no dice quién paga el triaje de ese administrador, que es la misma pregunta que el correo de Hubbard plantea a las empresas de su lista.
Qué debe hacer el dueño de una web en WordPress tras la 7.1.3
El correo de Hubbard no cambia nada en tu web de un día para otro. Pero las cifras de HackerOne y la lista de la 7.1.3 se traducen en varias cosas concretas:
- Instala la 7.1.3 si aún no lo has hecho. El anuncio recomienda actualizar de inmediato. Comprueba en Escritorio, Actualizaciones, que la web tiene de verdad la 7.1.3, aunque tengas activadas las actualizaciones automáticas.
- Las ramas antiguas reciben los parches más tarde. Según Patchstack, el día de la publicación las correcciones llegaron a las ramas desde la 6.6 en adelante, y las ramas de la 4.7 a la 6.5 aún las esperaban. Una web en la 7.1 estuvo protegida desde el primer día.
- Vacía la caché tras actualizar. Patchstack advierte de que la 7.1.3 no elimina las incrustaciones oEmbed guardadas en la base de datos, así que una incrustación maliciosa de Imgur añadida antes se sigue mostrando hasta que vacíes la caché.
- Revisa los roles de usuario. Patchstack lo recomienda expresamente, porque tres de los siete fallos requieren una cuenta de Colaborador o de Autor. Conviene eliminar, o rebajar los permisos de, las cuentas de antiguos autores y de agencias que hace tiempo dejaron de trabajar contigo.
- El núcleo no lo es todo. La Core Security Initiative no incluye plugins. Si hace tiempo que no revisas los tuyos, empieza por la auditoría de plugins desactualizados y CVE conocidos.
- Puede haber más versiones de seguridad. Hubbard escribe que el ritmo de informes sigue creciendo. Si actualizas una vez por trimestre, puedes saltarte varias versiones seguidas. Con un mantenimiento continuo de tu web WordPress, las actualizaciones se prueban en una copia y se aplican en días, no en meses.
Si quieres saber en qué estado está tu web ahora mismo, empieza por una auditoría de seguridad de WordPress.
Hasta cuándo deben las empresas comprometer financiación
Hubbard ofreció a las empresas interesadas los datos detallados del programa y escribió que quiere contar con “un primer grupo de contribuyentes a nuestro lado este trimestre” (traducción propia), es decir, antes de finales de diciembre de 2026. Por ahora ninguna empresa ha anunciado públicamente una cantidad concreta. Añadiré una actualización cuando alguna lo haga.
Con qué rapidez actualizar tras WordPress 7.1.3 y quién paga los parches en un contrato de mantenimiento Actualización 10.10.2026
A 10 de octubre de 2026 no encontré ningún compromiso público de las empresas de la lista, así que el cuadro de financiación de arriba sigue igual. El riesgo sí se puede precisar. Patchstack valora 7.1.3 así:
“Actualiza en cuanto puedas, pero no es una emergencia que obligue a dejarlo todo.”
Patchstack, WordPress 7.1.3 security release, 6 de octubre de 2026, traducción propia
Una de las siete correcciones funciona sin cuenta y sin acción de la víctima, y tres las notificó Anthropic. Para el dueño de una web, el ritmo es: parche del núcleo en pocos días, tras probarlo en una copia, no el próximo trimestre.
El dinero que pide Hubbard cubre recompensas y triaje en el núcleo. El trabajo en tu propia web (pruebas, despliegue, revisión de plugins) es un coste aparte que el contrato debe nombrar. Pregunta a quien lleve tu mantenimiento tres cosas: cuántos días después de una versión de seguridad aplica la actualización del núcleo, si la prueba antes en staging y si una versión fuera de ciclo entra en la cuota.
Última actualización: 13 de octubre de 2026.
