La semana pasada WordPress anunció que ya no basta con revisar plugins nuevos antes de entrar en el directorio: ahora cada actualización pasa por un filtro automático antes de llegar a tu panel. Suena bien. Suena como progreso. Pero cuando lees el comunicado oficial y lo cruzas con lo que comenta la prensa técnica, empiezas a ver los agujeros que el proyecto no quiere discutir en público.
El 9 de septiembre, el equipo de plugins de WordPress.org publicó que las releases con puntuación de riesgo alta se bloquean automáticamente en cuanto termina la revisión de seguridad. Ya no depende de que alguien del equipo esté despierto a las tres de la mañana. La versión comprometida nunca sale por la API de actualizaciones. Genial, ¿no? Pues sí, hasta que te das cuenta de que cómo se calcula esa puntuación es una caja negra.
El sistema lleva meses en marcha de forma gradual. Desde el 5 de junio, cada plugin y tema entra en una ventana de espera de seis horas antes de distribuirse. Durante ese tiempo, varios modelos de IA junto con Jetpack Scan analizan los cambios del código, cruzan resultados y asignan un score de seguridad. Cuanto más alto, más peligroso. Si supera el umbral, bloqueo automático y email a los committers del plugin explicando los hallazgos.
El ejemplo que ponen ellos mismos es el de un backdoor detectado el 28 de julio en un plugin con unas 20.000 instalaciones activas. La versión maliciosa nunca llegó a distribuirse porque aún estaba en cooldown. Wordfence avisó al equipo de plugins y cerraron la descarga en 26 minutos. Historia de éxito, titulares en Help Net Security y todo el mundo aplaudiendo. Lo que no te cuentan con el mismo detalle es qué pasa cuando el sistema se equivoca al revés.
Porque el propio anuncio admite que los falsos positivos no son cero. Varias herramientas cruzadas reducen el ruido, dicen, pero no lo eliminan. Y aquí está el problema: si eres desarrollador de un plugin legítimo y tu release queda bloqueada un viernes por la tarde, tu negocio se para seis horas como mínimo —más el tiempo que tardes en entender qué disparó la alarma, corregirlo y volver a publicar— sin saber exactamente qué línea de código molestó a la IA. No hay un informe público del modelo. No hay apelación descrita paso a paso. Solo un email con findings y la instrucción de arreglar y republicar.
En mi experiencia gestionando webs con decenas de plugins de terceros, la mayoría de los clientes no distingue entre «WordPress ha bloqueado una actualización peligrosa» y «WordPress ha roto mi tienda porque el plugin de pagos no se actualizó». Para ellos es lo mismo: algo dejó de funcionar y nadie sabe por qué. El ecosistema asume que los committers son desarrolladores con tiempo y paciencia para depurar alertas opacas. La realidad de muchas agencias es otra: un plugin de facturación bloqueado puede significar incumplir normativa o perder ventas durante horas.
Tampoco me convence el timing de este anuncio. WordPress 7.1.1 RC1 salió el 10 de septiembre, con release final prevista para el 17. Es una actualización de mantenimiento, bugfixes y regresiones del ciclo 7.1. Mientras tanto, el foco mediático va a la seguridad automatizada de plugins, que es importante, pero no resuelve el problema de fondo: millones de sitios siguen corriendo plugins abandonados que no reciben updates desde hace años y que nunca pasarán por este filtro porque ya están instalados.
El filtro protege el canal de distribución oficial. No protege tu servidor si instalaste un zip de hace tres años que nadie mantiene. Es como poner un detector de metales en la puerta del estadio pero dejar entrar a quien ya tiene la bomba dentro desde 2022. La medida es necesaria; lo que me molesta es presentarla como si cerrara el problema de seguridad de WordPress cuando en realidad cierra una ventana muy concreta: releases nuevas en wordpress.org.
Lo que más me inquieta es la dependencia de IA para decisiones que afectan a la cadena de suministro de software. Varios modelos, cruce de resultados, Jetpack Scan… suena robusto en un blog post. Pero no conocemos los pesos, los umbrales exactos ni cómo evolucionarán cuando un atacante empiece a optimizar malware para quedar justo por debajo del score de bloqueo. La seguridad por oscuridad funciona hasta que alguien la mapea. Y en un ecosistema abierto como WordPress, alguien siempre la mapea.
Help Net Security resume bien el procedimiento para desbloquear: revisar los findings, corregir, publicar nueva release y esperar otra ventana de seis horas si pasa el filtro. Eso puede ser aceptable para un plugin de widgets. Para uno que gestiona pagos, reservas médicas o datos personales bajo RGPD, seis horas de parálisis forzada no es un detalle menor. El proyecto prioriza no distribuir código malicioso —correcto— pero externaliza el coste operativo a quien desarrolla y a quien mantiene el sitio, sin compensación ni SLA.
Tampoco veo conversación sobre auditoría independiente del propio sistema. ¿Quién verifica que los modelos no degraden con el tiempo? ¿Qué pasa si Jetpack Scan tiene un día malo y empieza a bloquear releases limpias en masa? El comunicado dice que los committers reciben email, pero no menciona transparencia pública de bloqueos, estadísticas de falsos positivos ni un registro consultable. Comparemos con npm, PyPI o incluso la App Store: todos tienen fricción en reviews, pero al menos hay procesos documentados y, en muchos casos, vías de apelación humanas.
No estoy diciendo que WordPress deba volver al modelo anterior, donde una actualización podía llegar a medio millón de sitios antes de que alguien la revisara manualmente. Eso era insostenible y el incidente de julio lo demuestra. Lo que digo es que han sustituido un cuello de botella humano por uno algorítmico sin explicar suficientemente las reglas del juego. Y en un CMS que mueve el 43% de la web, «confía en la IA y corrige si te equivocamos» no me parece una respuesta madura.
Si gestionas sitios WordPress —y apuesto a que sí, si lees esto—, el consejo práctico que saco hoy no es desactivar updates. Sería una estupidez. Pero sí merece la pena revisar qué plugins críticos tienes, si alguno depende de releases frecuentes y si tu proveedor de mantenimiento tiene un plan B cuando una actualización no llegue porque quedó bloqueada en wordpress.org. Staging, copias de seguridad antes de updates manuales, monitorizar el changelog del plugin… lo de siempre, pero ahora con una variable nueva que no controlas.
WordPress avanza hacia una gobernanza más automatizada mientras lanza 7.1.1 para corregir bugs del ciclo anterior. Dos velocidades: parches de core en días y un ecosistema de plugins que ahora depende de scores opacos. No me cuadra del todo. Me parece un paso adelante en contención de daños, pero lejos de la transparencia que el mercado —desarrolladores, agencias, pymes— necesitaría para confiar sin reservas.
Si mañana tu plugin de reservas o tu pasarela de pago queda bloqueada seis horas porque una IA leyó «riesgo alto» en código que tú no escribiste, ¿tienes ya un plan para seguir operando sin romper la confianza de tus clientes, o confías en que WordPress te mandará un email suficientemente claro para arreglarlo antes de que alguien note que la web falla?