El lunes WordPress actualizó las reglas de su programa de divulgación de vulnerabilidades. El viernes anterior anunció la Core Security Initiative. En el medio, agosto dejó a medio ecosistema con plugins rotos y parches de emergencia. Yo no soy de conspiraciones, pero cuando un proyecto anuncia que va a usar IA para encontrar fallos y al mismo tiempo le dice a los investigadores que muchos informes ya no son elegibles, me pica la curiosidad.
La iniciativa tiene tres pilares con nombres que suenan a presentación de consultora: mejorar el proceso de releases de seguridad, vaciar el backlog de informes abiertos y «crush vulnerabilities with AI» — sí, en inglés, porque el comunicado oficial no se molesta en traducirlo. La idea es usar escaneo asistido por IA para encontrar vulnerabilidades antes de que lo hagan atacantes o investigadores externos. En paralelo, el equipo de seguridad admite que el volumen de informes ha crecido «de forma sustancial» porque los modelos de IA hacen más fácil analizar código. Más ojos, dicen. Es un buen problema de tener. Hasta que lees la letra pequeña del lunes.
Porque el lunes 1 de septiembre, John Blackbourn publicó en Make/Security que los informes que requieran un rol que solo puede conceder un administrador ya no serán elegibles, salvo que demuestren una escalada de alta severidad. Lo mismo para vulnerabilidades que exijan autenticación con un rol concreto: si no hay escalada de impacto alto, fuera. El mensaje es claro: queremos que os centréis en fallos explotables sin autenticación o con usuarios de bajo privilegio, como Suscriptores.
En abstracto, tiene sentido. Si recibes cientos de informes generados con ayuda de IA, necesitas filtrar ruido. Pero piénsalo desde la trinchera de quien mantiene webs de clientes: la mayoría de los plugins vulnerables que he visto en producción requieren exactamente eso — un editor, un shop manager, alguien con permisos que no debería poder ejecutar código. ¿Vas a decirle a un cliente que su tienda WooCommerce no tiene un problema de seguridad porque el atacante necesita estar logueado como shop manager? No te lo compra nadie.
Lo que me choca es el timing. WordPress acaba de pasar por julio con el parche de emergencia 7.0.2, agosto con el RCE de Imagick en 7.0.4 y septiembre con la polémica de WordPress 7.1 rompiendo sitios en plena WordCamp US. El ecosistema sangra por plugins abandonados — algo de lo que ya hemos hablado aquí — y ahora el Core dice que va a usar IA para encontrar fallos proactivamente mientras reduce el canal por el que la comunidad reporta los que la IA no ve. Simetría bonita en un slide, contradicción incómoda en la práctica.
La tercera pilar, la de IA ofensiva a favor de la defensa, me genera más preguntas que respuestas. Según Cybersecurity News, las herramientas buscarán patrones de XSS, escalada de privilegios, manejo inseguro de archivos y SSRF. Pero la misma fuente reconoce que la IA no sustituye a investigadores humanos: hace falta alguien que verifique si el fallo es explotable, determine severidad, cree el parche y lo pruebe. O sea, el mismo cuello de botella que la iniciativa promete resolver, pero ahora con más informes descartados por política.
En inglés, la conversación va por otro tono. Search Engine Journal habla de «code red moment» porque la IA baja la barrera para criminales. En foros de seguridad comentan que si OpenAI acaba de clasificar Astra en umbral crítico de ciberseguridad — un modelo que encuentra zero-days por su cuenta — el mismo tipo de herramientas que WordPress quiere usar para defenderse es el que acelerará los ataques contra plugins desactualizados. La iniciativa del Core no menciona plugins. Solo Core y Gutenberg. Tu problema sigue siendo tuyo.
Lo que sí me parece sensato es el primer pilar: un proceso de release de seguridad más automatizado y con mejor testing end-to-end. Cualquiera que vivió el despliegue caótico de parches en agosto entiende por qué. Si cuando encuentras un fallo tardas tres semanas en sacar el fix porque el pipeline de QA es frágil, da igual cuánta IA tengas escaneando el repositorio. El fix llega tarde y el backlog crece. Eso es mecánica, no futurología.
El segundo pilar — llevar los informes abiertos a cero — es ambicioso y necesario, pero no veo números. ¿Cuántos informes hay en cola? ¿Cuántos llevan más de 90 días? El comunicado de Make/Security promete contratar más gente y buscar voluntarios, lo cual es bien, pero sin métricas públicas no sabremos si funciona o si es otro anuncio post-WordCamp que se diluye en el invierno.
Y aquí está mi principal sospecha: WordPress está reaccionando a un tsunami de informes generados con IA — muchos de baja calidad, eso es obvio — estrechando las reglas de divulgación justo cuando anuncia que usará IA para encontrar fallos internamente. El mensaje implícito para investigadores independientes y empresas de seguridad es «dejad de mandarnos ruido, que ahora lo hacemos nosotros». El mensaje para agencias y pymes es «confiad en que el Core se protege a sí mismo». Ninguno de los dos me tranquiliza si gestionas cincuenta sitios con plugins de terceros que no entran en el programa de HackerOne del Core.
No digo que la iniciativa sea mala. Digo que llega incompleta y mal explicada. Si vas a usar IA para escanear código, publica qué herramientas, qué cobertura y qué SLA de respuesta. Si vas a filtrar informes, explica cómo tratarás vulnerabilidades en el ecosistema de plugins, que es donde realmente sangran los sitios de mis clientes. Y si pides a la comunidad que se enfoque en fallos de alto impacto, no anuncies la iniciativa la misma semana en que 7.1 rompe compatibilidad en producción: la credibilidad no se repone con un post en Make.
En mi experiencia, la seguridad de WordPress no falla en el Core — que también falla, pero es menos frecuente — sino en la cadena larga de plugins premium abandonados, themes con código ofuscado y hosting compartido sin WAF. La Core Security Initiative no menciona esa cadena. Resuelve un problema real del equipo de mantenimiento, pero no el que te despierta a las tres de la mañana cuando un cliente te llama porque su tienda muestra contenido japonés de casinos.
¿Significa esto que deberías dejar de reportar vulnerabilidades? No. Significa que leas las nuevas directrices del programa antes de enviar nada a HackerOne, que no asumas que un informe válido hace seis meses lo sigue siendo hoy, y que no confíes en que la IA del Core vaya a proteger tu stack de plugins. Actualiza, monitoriza, y si puedes, presupuesta un WAF decente. Lo de siempre, vaya.
Lo que me gustaría saber — y aquí es donde me quedo con la mosca detrás de la oreja — es si este movimiento es el principio de un WordPress Core más cerrado en seguridad o solo un parche organizativo. Porque si la tendencia es «menos informes externos, más escaneo interno», en un escenario donde modelos como Astra pueden encontrar exploits sin supervisión humana, la ventaja la tendrán quien tenga acceso a esas herramientas. Y eso no suele ser la pyme que mantiene su web con un plugin de caché y fe.
Si tu proveedor de mantenimiento te propone un plan de seguridad WordPress que solo incluye actualizaciones automáticas del Core pero no revisión de plugins ni monitorización de integridad, ¿lo aceptarías sabiendo que el propio proyecto acaba de admitir que el volumen de vulnerabilidades supera su capacidad de respuesta?