En resumen: la cadena de suministro de un sitio web va desde el proyecto PHP, pasando por la distribución y el proveedor de alojamiento, hasta el CMS, los plugins, la agencia y los servicios integrados. Para la seguridad TI cuenta cada eslabón, porque un parche solo llega a su sitio web cuando todos lo han transmitido. Quien anota la cadena, fija para cada eslabón un responsable y una prueba, y limita los accesos, la vuelve robusta.
Un parche y su largo viaje
El 21 de octubre de 2026 a las 14:00 UTC, el proyecto PHP publicó las correcciones de PHP2Shell. Con ello no quedó cerrada la vulnerabilidad en ni un solo sitio web. Primero tuvieron que incorporar las correcciones a sus paquetes distribuciones como Debian, Ubuntu o la familia RHEL; según los informes, algunos backports se entregaron el mismo día. Después, los proveedores de alojamiento y los administradores tuvieron que instalar esos paquetes y reiniciar todos los procesos de PHP. Solo entonces quedó protegido el sitio web correspondiente.
Cada eslabón de esta cadena puede retrasar. Y de cada uno depende una organización distinta con sus propias prioridades. Quien no sabe cómo es su cadena no puede decir dónde está el parche en ese momento.
Algunas cadenas tienen eslabones adicionales que casi nadie conoce. Muchos servidores Debian y Ubuntu no obtienen PHP de la distribución, sino del repositorio de Ondřej Surý en sury.org, una fuente de terceros muy extendida. Según los informes, ha puesto a disposición compilaciones para todas las ramas, de la 5.6 a la 8.5. Eso es útil, pero no es el archivo de seguridad de Debian: quien usa esta fuente depende de otro eslabón, con su propio ritmo y su propia responsabilidad. Si un servidor está configurado así lo muestra la lista de fuentes de paquetes, y esa información debe formar parte de la documentación de la cadena.
Los eslabones de la cadena de suministro, de un vistazo
La tabla siguiente muestra los eslabones típicos de un sitio web PHP y lo que puede exigir de cada uno.
| Eslabón | Riesgo típico | Qué debería establecer |
|---|---|---|
| Proyecto PHP | vulnerabilidad en el intérprete, fin del soporte | versión compatible en uso, plan para el fin del soporte |
| Distribución o fuente de terceros | falta el backport o llega tarde | fuente de paquetes conocida, avisos de seguridad suscritos |
| Proveedor de alojamiento o servicio de plataforma | actualización sin reinicio, sin información | obligación de actualizar, reiniciar, acreditar y notificar |
| Fabricante del CMS | vulnerabilidad en el núcleo | canal de actualización, persona responsable |
| Proveedor de plugins y temas | extensiones abandonadas o inseguras | solo plugins mantenidos de fuentes oficiales |
| Agencia o desarrollador | accesos amplios, responsabilidad poco clara | accesos personales, encargos por escrito |
| Scripts y servicios externos | código ajeno en el navegador, fuga de datos | lista, versiones fijas, finalidad comprobada |
Dos ejemplos de la semana de PHP2Shell muestran con qué facilidad se pasa por alto un eslabón. Vercel señala que no basta con actualizar el entorno de desarrollo local, el código de la aplicación o los plugins; lo decisivo es el entorno de ejecución de PHP que realmente sirve las páginas. Coolify aconseja actualizar por separado el entorno de ejecución de PHP de cada aplicación, también detrás de Cloudflare. Y, según los informes, WordPress.org no prevé una actualización propia contra PHP2Shell porque la vulnerabilidad está en el intérprete. Quien espera al CMS espera en vano.
Hacer visible la cadena: cinco pasos
Así pone orden en las dependencias de sus sitios web:
- Anotar la cadena de cada sitio web: desde el entorno de ejecución de PHP hasta los scripts externos, con el nombre del proveedor o de la persona.
- Fijar la responsabilidad de cada eslabón: ¿quién instala las actualizaciones, quién comprueba, quién informa a quién?
- Acordar las pruebas: ¿qué se considera hecho? En el entorno de ejecución de PHP, por ejemplo, el estado del paquete y el reinicio, como se describe en Cómo preguntar a su proveedor de alojamiento por el estado del parche.
- Limitar los accesos: cada agencia y cada proveedor recibe solo los derechos que necesita, con cuentas personales.
- Planificar vías alternativas: ¿qué hacer si un eslabón falla, por ejemplo si un proveedor de plugins abandona o un proveedor de servicios no es localizable?
Pregunte a cada proveedor cómo le informará de vulnerabilidades críticas. Quien solo responde cuando se le pregunta es, en una situación como la de PHP2Shell, un riesgo para su calendario. Deje la respuesta por escrito.
Plugins y extensiones: el punto menos transparente
En muchos sitios web, la mayor parte de la cadena de suministro es invisible: plugins y temas que se han ido añadiendo con los años. Cada uno procede de un proveedor distinto, con su propio ritmo en las actualizaciones de seguridad. Algunos proveedores abandonan su producto sin anunciarlo. Otras extensiones se obtienen de fuentes no oficiales y nunca reciben actualizaciones.
Aquí ayuda una regla sencilla: cada plugin necesita una finalidad, un proveedor que lo mantenga y una fuente de obtención oficial. Si falta alguno de ellos, pasa a la lista de sustitución. Algo similar vale para los servicios integrados, como proveedores de pago, sistemas de reservas, ventanas de chat o herramientas de análisis. Aportan código propio a su página o reciben datos de sus visitantes. Anote qué servicios están integrados, quién los encargó y si todavía se necesitan. Un script olvidado de un proveedor con el que hace tiempo que no existe contrato es un eslabón sin responsable.
Cómo mantener plugins y paquetes actualizados de forma duradera lo describe Mantener las dependencias actualizadas: Composer, npm y plugins.
Cadena de suministro, contratos y NIS2
Para las empresas incluidas en el ámbito de NIS2, la seguridad de la cadena de suministro forma parte expresa de la gestión de riesgos, y por tanto también las relaciones con proveedores y suministradores. Los detalles figuran en NIS2 y seguridad de los servidores web. Pero incluso sin obligación legal vale esto: las tareas externalizadas siguen siendo su riesgo. Por eso los resultados de los cinco pasos deben incorporarse a los contratos con la agencia, el proveedor de alojamiento y los proveedores de servicios; qué puntos conviene regular allí lo describe Contratos con proveedores de TI: regular con claridad las obligaciones de seguridad. Esta página es información general y no constituye asesoramiento jurídico.
¿Cómo ayuda PHP SOS en concreto?
- Trazamos con usted la cadena de suministro de cada sitio web, desde el entorno de ejecución de PHP hasta los scripts externos.
- Revisamos el estado de mantenimiento y el origen de plugins, temas y paquetes, y recomendamos sustitutos donde haga falta.
- Acordamos con el proveedor de alojamiento y la agencia quién es responsable de qué eslabones y qué pruebas se entregan.
- Donde un eslabón está sin cubrir, lo asumimos de forma permanente mediante un contrato de mantenimiento de seguridad.
Conclusión: la seguridad de un sitio web es tan fuerte como el eslabón más lento de su cadena de suministro. Quien conoce la cadena y vincula cada eslabón con un responsable y una prueba sabe, en caso de emergencia, dónde está el parche.
Preguntas frecuentes
¿Qué significa cadena de suministro en un sitio web?
Todos los implicados de cuyo trabajo depende la seguridad de su sitio web: el proyecto PHP, la distribución de Linux, el proveedor de alojamiento o servicio de plataforma, el fabricante del CMS, los proveedores de plugins y temas, la agencia y los servicios integrados, como proveedores de pago o scripts externos.
¿Soy responsable si un proveedor no instala los parches?
La responsabilidad sobre su propio sitio web y los datos que contiene suele seguir siendo suya, aunque haya externalizado tareas. Por eso las responsabilidades deberían estar claras por contrato y comprobarse. Para la valoración jurídica son competentes el abogado y el delegado de protección de datos.
¿Basta con que el proveedor de alojamiento actualice PHP?
Para el entorno de ejecución de PHP en el proveedor, sí, siempre que además reinicie todos los procesos y lo acredite. Si partes de su aplicación se ejecutan en otro lugar, por ejemplo en contenedores, en servicios de plataforma o en un segundo servidor, hay que actualizar allí cada entorno de ejecución por separado.
¿Cómo reconozco plugins de riesgo?
Son señales de alarma que lleven mucho tiempo sin actualizaciones, un proveedor sin contacto de seguridad reconocible, la obtención desde fuentes no oficiales y funciones que ya nadie usa. Estos plugins deberían sustituirse o eliminarse.