El 22 de septiembre de 2026, WordPress publicó un parche para una falla crítica en su núcleo. Tres días después, la agencia de ciberseguridad de Estados Unidos (CISA) confirmó que ya se estaba explotando. En muchas empresas de retail, nadie habría recibido ese aviso, porque nadie sabe quién actualiza el sitio de campañas. Las landings de temporada, los formularios que alimentan el CRM y los scripts de medición los construyó una agencia cuyo contrato ya terminó; marketing cree que el sitio es de TI y TI cree que es de marketing. Mientras tanto, el sitio sigue en línea y recibe datos de clientes todos los días, con la versión de PHP y los plugins del día del lanzamiento.
La seguridad web del sitio comercial es una decisión de dirección. Cada plugin, cada script de un tercero y cada librería de PHP, npm o Composer es un proveedor que entra a tu sitio sin contrato. Si ninguna persona concreta responde por los parches, el riesgo lo absorbe la empresa sin saberlo.
Porque recibe datos personales, se conecta al CRM y ejecuta código de muchos terceros, y casi siempre queda sin responsable después del lanzamiento. Las vulnerabilidades informáticas aparecen en el software que usa el sitio aunque nadie lo toque. Sin parches, el sitio acumula fallas conocidas y públicas.
El caso de WordPress lo muestra con detalle. La versión 7.1.2 corrigió una falla que, bajo ciertas condiciones, permitía a un atacante sin autenticación llegar a ejecutar código en el servidor. El 25 de septiembre, CISA agregó esa falla, CVE-2026-87902, a su catálogo de vulnerabilidades explotadas activamente. Un sitio que aplica parches una vez al mes queda expuesto casi todo ese plazo.
Lo mismo pasa con otros gestores de contenido y frameworks. El 20 de marzo de 2026, CISA agregó al mismo catálogo fallas de Craft CMS y de Laravel Livewire, dos piezas comunes en sitios a la medida.
Son la puerta que menos se vigila. En junio de 2024, Sansec reportó que el servicio polyfill.io, un script que muchos sitios cargaban desde un dominio externo, empezó a inyectar código malicioso en más de 100 mil sitios. Las empresas afectadas no tocaron su código; el dominio del script había cambiado de manos meses antes.
En septiembre de 2025, BleepingComputer reportó que paquetes de npm muy usados, como chalk y debug, fueron secuestrados tras un phishing a su mantenedor; el código malicioso corría en el navegador de los visitantes. Ese mismo mes, CISA alertó sobre Shai-Hulud, un gusano que comprometió cientos de paquetes de npm. En noviembre de 2025, PostHog publicó el análisis de cómo una segunda ola de ese ataque llegó a sus SDK de analítica.
En 2026 siguieron los casos: CISA alertó en abril sobre versiones comprometidas de axios, Cloudsmith documentó en mayo el reemplazo malicioso de un paquete PHP de Intercom en Packagist, StepSecurity reportó la reescritura de paquetes de laravel-lang en Composer y Datadog describió en agosto el gusano ChainDrop, que comprometió cientos de paquetes de npm. Estos ataques no eligen víctima: llegan a quien use el paquete comprometido.
El OWASP Top 10:2025, publicado en noviembre de 2025, incluye la categoría A03, fallas en la cadena de suministro de software. La seguridad de aplicaciones ya considera como riesgo central el código que tu sitio hereda de terceros, además del que escribe tu equipo.
Llevado al comité: tu sitio depende de cientos de piezas que tu equipo no escribió, y alguien tiene que saber cuáles son y cuándo hay que actualizarlas.
También pesa la base. Según php.net, PHP 8.1 dejó de recibir parches de seguridad el 31 de diciembre de 2025, y PHP 8.2 los recibe solo hasta el 31 de diciembre de 2026. Un sitio montado en 2022 que nadie actualizó probablemente ya corre en una versión sin soporte.
Son cuatro decisiones, y ninguna existe sin una firma de la dirección. Un inventario de lo que corre en el sitio, con plugins, scripts de terceros, librerías y versión de PHP. Una persona interna responsable de los parches, que siga ahí cuando el integrador se vaya. Un plazo en días para aplicar parches críticos, escrito en el contrato del proveedor. Y una partida anual de mantenimiento.
La partida de mantenimiento es la que casi nunca se aprueba, porque el presupuesto se arma para el lanzamiento. Por eso, en la selección de proveedores de software, el contrato tiene que cubrir lo que pasa después del arranque.
Tratar el sitio como «cosa de la agencia» funciona hasta que la agencia termina su contrato y el sitio sigue en línea. Haz la prueba: pregunta quién recibe hoy la alerta cuando sale un parche crítico.
¿Y los formularios? Si alimentan el CRM, un sitio comprometido es una vía hacia tus datos de clientes, y las obligaciones de datos personales aplican a toda la cadena. Las integraciones merecen el mismo cuidado que cuando se conecta un CRM nuevo a sistemas legados. En retail, además, las landings de temporada se lanzan con prisa, cada campaña agrega sus scripts de medición y, al terminar, nadie los retira. Cada uno sigue cargando en el navegador de tus clientes, con acceso a lo que escriben en los formularios; retirar lo que ya no se usa reduce el inventario y el riesgo al mismo tiempo.
Ya, si no sabes quién es el responsable de los parches. Después, al menos cada trimestre y cada vez que una alerta de CISA o del proveedor toque algo de tu inventario. En ciberseguridad para empresas medianas, esta parte operativa es la que veo abandonada con más frecuencia.
Si ya tienes un centro de excelencia de CRM, ese equipo puede asumir el inventario y la responsabilidad de los parches.
Esta semana, yo preguntaría: ¿tenemos el inventario de lo que corre en el sitio?, ¿qué persona responde por los parches?, ¿cuántos días tarda nuestro proveedor en aplicar un parche crítico y dónde lo dice el contrato?, y ¿cuánto presupuesto tenemos este año para mantener el sitio? La primera respuesta que sea «no sé» es la primera tarea.
Son actualizaciones que corrigen vulnerabilidades conocidas en el software. Cuando se publica un parche, la falla se vuelve pública, así que el tiempo para aplicarlo importa.
Los parches críticos deben aplicarse en días, según el plazo que fijes en el contrato. Las actualizaciones normales pueden agruparse en una revisión mensual o trimestral, con un inventario al día.
La empresa, aunque lo haya construido una agencia. Por eso debe haber un responsable interno designado y un proveedor con obligaciones de parches por contrato.
Si quieres revisar tu caso con alguien que no vende la plataforma, agenda una conversación.