Si mantienes sitios en WordPress, estos últimos meses te han sonado a trompeta: núcleo que se actualiza en cadena, plugins con avisos rojos y listados de vulnerabilidades que parecen el parte meteorológico. Yo no te voy a vender la paz: el problema no es solo técnico, es de expectativas. Mucha gente sigue tratando WordPress como un “Word” con hosting y en realidad es un sistema que vive en internet, es decir, en el frente.
El propio proyecto publicó el aviso de WordPress 6.9.4 como release de seguridad, con el matiz incómodo de que no todos los arreglos de versiones anteriores habían quedado bien aplicados. Traducción para quien administra: no es paranoia, es que el parche anterior a veces no fue el parche. Eso te obliga a leer el changelog y no confiar en el botón verde como si fuera un ritual mágico.
En paralelo, los informes agregados de vulnerabilidades en el ecosistema (plugins y temas) siguen mostrando un patrón que ya conocemos: hay mucho código de terceros, muchas superficies de ataque y una parte del catálogo que no se actualiza con la misma disciplina que el núcleo. SolidWP, en su informe del 1 de abril de 2026, cuenta 225 vulnerabilidades divulgadas en abierto, con parche disponible para 134 plugins y temas, y 91 casos sin fix en ese momento. No hace falta ser alarmista: hace falta ser realista. Si tu negocio depende de un formulario, de un mapa o de un plugin de membresía, tu riesgo no es “abstracto”, es el acceso al panel, al checkout o a los datos de clientes.
¿Que es lo que más me molesta del discurso comercial? Que te venden “WordPress fácil” y te ocultan el mantenimiento continuo. Un hosting decente te pone PHP a punto y backups, pero no puede firmar por ti la lista de plugins que instalaste en 2019 porque “había un tutorial en YouTube”. La responsabilidad es tuya si eres el dueño del sitio; si eres quien lo mantiene para un cliente, la responsabilidad es tuya en la práctica aunque el contrato diga otra cosa, porque el daño reputacional no lo paga el PDF.
Mi recomendación, sin florituras: inventario mínimo de plugins con dueño claro (quién lo actualiza y cada cuánto), entorno de pruebas para lo que no sea trivial, y política de actualizaciones que no sea “cuando me acuerdo un domingo”. Si el núcleo pide actualizar por seguridad, la conversación interna no debería ser “¿lo hago?”, sino “¿en que orden y con que comprobación?”. A veces la respuesta correcta es parar cinco minutos y leer la nota de la release, no darle a actualizar entre reunión y reunión.
Y sí, el debate de fondo es incómodo: WordPress sigue siendo una herramienta excelente para publicar y vender, pero la seguridad no es un extra de marketing. Es horas, procesos y, a veces, dejar de instalar extensiones que nadie en el equipo sabe mantener. Si te duele leer esto, imagínate explicarle a un cliente que su web cayó por un plugin abandonado que seguía ahí porque “siempre había funcionado”.
La documentación oficial del núcleo para la 6.9.4 detalla los fallos corregidos (entre ellos, un tema serio en la librería externa getID3 y un bypass de autorización en notas). No te pido que memorices CVEs: te pido que entiendas que “actualizar el núcleo” no es cosmética, es cerrar ventanas que en otro software llamarías incidente. En mi experiencia, el cuello de botella no suele ser WordPress en sí, sino la mezcla de plantilla comprada, cinco plugins de terceros y cero tiempo para probar en staging.
Fuentes
- WordPress 6.9.4 Release — WordPress News
- Version 6.9.4 — Documentation — WordPress.org
- WordPress Vulnerability Report — April 1, 2026 — SolidWP
Si mañana tu cliente te dijera que solo puede pagar el hosting “básico” pero quiere el mismo SLA de seguridad que un sitio enterprise, ¿qué le cortarías primero: plugins, funcionalidades o le subirías el presupuesto de mantenimiento sin negociar?