En resumen: En proveedores cloud y PaaS, el parche no lo aplica automáticamente el proveedor. Si él gestiona el entorno de ejecución de PHP, lo actualiza, pero a menudo solo con el siguiente despliegue. Si construye usted mismo imágenes o builds, o si opera la plataforma por su cuenta, debe reconstruir y desplegar. Lo que cuenta siempre es el entorno de ejecución que su sitio web sirve en este momento.
Actualización de PHP en PaaS: ¿de quién es el entorno de ejecución?
Los servicios de plataforma, en la jerga PaaS (Platform as a Service), liberan a las empresas de la operación de servidores. Usted sube el código y la plataforma lo construye y lo opera. Con PHP2Shell, esto genera una incertidumbre típica: ¿a quién le corresponde en realidad actualizar PHP?
Vercel lo resume en su boletín sobre PHP2Shell: 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 del despliegue que realmente responde a las peticiones. Si ese entorno está parcheado depende de quién lo proporciona y de cuándo se construyó por última vez.
Cuatro modelos de explotación comparados
Las denominaciones de los proveedores varían. Para la cuestión del parche, la mayoría de las ofertas se pueden asignar a uno de estos modelos:
| Modelo | ¿Quién actualiza PHP? | Qué debe hacer usted |
|---|---|---|
| Entorno de ejecución gestionado por el proveedor | Proveedor | Obtener confirmación y, en su caso, volver a desplegar para que se aplique el nuevo entorno |
| Entorno de ejecución basado en build (buildpack) | El proveedor ofrece una versión nueva, su build la fija | Lanzar un build nuevo y comprobar la versión en el registro del build |
| Imagen de contenedor propia | Usted | Reconstruir la imagen con PHP corregido y desplegarla |
| Plataforma operada por usted | Usted, para la plataforma y las aplicaciones | Parchear la plataforma y cada aplicación por separado |
Muchas empresas usan varios modelos a la vez, por ejemplo un entorno gestionado para el sitio web y contenedores propios para herramientas internas. Por eso cada aplicación necesita su propia respuesta.
Hay una trampa en la palabra «gestionado». Aunque el proveedor mantenga el entorno de ejecución, una aplicación ya desplegada suele seguir funcionando con el nivel con el que se construyó. La versión nueva solo se aplica entonces en el siguiente build o despliegue. Además, algunas plataformas mantienen accesibles despliegues antiguos o entornos de vista previa en direcciones propias. Por ello, no pregunte solo si el proveedor ha parcheado, sino también desde cuándo sus instancias en ejecución usan el parche y qué ocurre con los despliegues antiguos.
Qué dicen Vercel y Coolify sobre PHP2Shell
Dos proveedores han hecho públicas sus indicaciones. Son instructivas porque nombran con claridad los límites de sus propias medidas de protección.
Vercel, según su propio boletín, activó antes de la publicación reglas de protección en su Web Application Firewall (WAF), un filtro para peticiones web. Se aplican automáticamente a las funciones PHP en Vercel y a las peticiones que Vercel reenvía a servidores PHP externos. A la vez, Vercel exige actualizar de inmediato el entorno de ejecución de PHP a una versión corregida. Los despliegues en contenedores deben reconstruirse con una imagen base de PHP actualizada y desplegarse. Las peticiones que eluden Vercel y van directamente a un servidor PHP externo no están cubiertas por el WAF.
Coolify, una plataforma que se puede operar por cuenta propia, estaba según su propio aviso afectada: todas las ramas de la versión 4. Como primeros niveles corregidos, Coolify indica 4.0.1, 4.1.3, 4.2.1, 4.3.24 y 4.4.7, y recomienda 4.4.7. Importa la precisión añadida: la actualización de Coolify no actualiza las aplicaciones PHP que usted opera con ella. Sus entornos de ejecución o imágenes debe actualizarlos por separado y reconstruirlos o desplegarlos. Según Coolify, esto vale también para los clientes de Coolify Cloud y también detrás de Cloudflare, porque las reglas de Cloudflare solo revisan el tráfico que pasa por Cloudflare.
Qué logran las reglas de Cloudflare lo sitúa el artículo Reglas de protección de Cloudflare contra PHP2Shell.
Cómo comprobar el entorno de ejecución que sirve
Los siguientes pasos funcionan con independencia del proveedor. Apuntan a un justificante, no a una sensación.
- Enumerar todos los entornos: producción, staging, despliegues de vista previa y servicios en segundo plano como los workers de colas. Cada entorno puede tener un entorno de ejecución distinto.
- Leer la versión del entorno de ejecución por entorno: en la consola del proveedor, en el registro del build o en el archivo de configuración del proyecto.
- Comprobar la fecha del último despliegue: si es anterior al 21 de octubre de 2026, con alta probabilidad sigue funcionando el entorno antiguo, salvo que el proveedor confirme expresamente otra cosa.
- Mirar en la instancia en ejecución: si la plataforma ofrece una consola, el siguiente comando muestra la versión de la instancia.
- Incluir los servidores PHP externos: los servidores a los que la plataforma reenvía peticiones necesitan su propia actualización y no deberían ser accesibles directamente desde Internet.
# En la consola de la instancia en ejecución (si el proveedor la ofrece)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Se esperan 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o un backport confirmado por el proveedor. Tenga en cuenta que la línea de comandos de una instancia no siempre usa el mismo entorno de ejecución que el proceso web. Para la comprobación, no cree ningún archivo phpinfo accesible públicamente. Cómo interpretar correctamente el número de versión y el nivel de backport lo describe Comprobar la versión de PHP y el nivel de parcheo.
Un despliegue nuevo no elimina el software malicioso que haya llegado antes a almacenamientos persistentes como volúmenes de subida o la base de datos. Esas áreas debe revisarlas por separado.
Dejar por escrito la responsabilidad
PHP2Shell muestra lo poco clara que suele ser la frontera entre plataforma y cliente. Anote para cada aplicación quién proporciona el entorno de ejecución, quién reconstruye ante avisos de seguridad y cómo anuncia el proveedor los parches. A ello pertenece también quién tiene acceso a la consola de la plataforma cuando hay prisa y quién puede lanzar un build nuevo fuera del horario laboral.
Para su propia documentación basta una tabla breve por aplicación: plataforma, modelo de explotación, rama de PHP, fecha del último build, responsable. Quien tenga esta lista a mano en el siguiente aviso se ahorra los días que muchos equipos pasaron buscando después del 21 de octubre. En las aplicaciones en contenedores, forma parte de ella quién mantiene la imagen base; los antecedentes los explica PHP en contenedores.
Para servidores gestionados sin carácter de PaaS valen preguntas similares, que hemos resumido en Servidor gestionado: aclarar la responsabilidad.
¿Cómo ayuda PHP SOS en concreto?
- Asignar: asignamos cada una de sus aplicaciones a un modelo de explotación y aclaramos quién proporciona el entorno de ejecución de PHP.
- Acreditar: comprobamos el entorno de ejecución, la fecha del build y el despliegue por entorno y documentamos el resultado.
- Reconstruir y desplegar: mediante el servicio de parcheo de PHP actualizamos imágenes y builds y los desplegamos de forma controlada.
- Cerrar brechas: comprobamos si los servidores PHP externos son directamente accesibles y restringimos el acceso.
Preguntas frecuentes
¿Parchea PHP automáticamente mi proveedor de PaaS?
Depende del modelo. Si el proveedor gestiona el entorno de ejecución, lo actualiza, pero a menudo solo para los despliegues nuevos. Si construye usted mismo las imágenes o los builds, debe reconstruir y volver a desplegar. Pida que le confirmen el nivel para su aplicación.
¿Basta el WAF de mi proveedor de plataforma frente a PHP2Shell?
No. Vercel y Coolify escriben expresamente que las reglas de protección no sustituyen la actualización del entorno de ejecución de PHP. Además, solo actúan sobre el tráfico que pasa por la plataforma.
¿Debo volver a desplegar tras el parche?
A menudo, sí. Para despliegues en contenedores, Vercel indica reconstruir con una imagen base de PHP actualizada y hacer un nuevo despliegue. En plataformas basadas en build, el entorno de ejecución queda fijado en el build; solo un build nuevo asume el parche.
Uso Coolify. ¿Basta la actualización de Coolify?
No. Según el aviso de Coolify, la actualización solo actualiza el propio Coolify. Los entornos de ejecución de PHP o las imágenes de contenedor de sus aplicaciones debe actualizarlos por separado y reconstruirlos o volver a desplegarlos.