PHP2Shell y Docker: reconstruya sus imágenes de PHP y WordPress

Una actualización de WordPress, un composer update o una nueva versión de Nextcloud sustituyen archivos de la aplicación. El intérprete PHP es un programa instalado en la imagen Docker, igual que el sistema Debian o Alpine que lo rodea. Mientras la imagen no cambie, PHP no cambia, por muchas actualizaciones que reciba la aplicación.

La segunda trampa es el reinicio. docker restart reinicia el contenedor existente, es decir, la misma imagen. docker compose up -d no busca una versión más reciente cuando ya existe en el servidor una imagen con ese nombre: reutiliza la copia local. Solo un pull o un build --pull, seguido de la recreación del contenedor, cambia el intérprete.

Los dos fallos y los comandos apt o dnf se explican en nuestra guía de actualización de PHP. Aquí se trata de la imagen Docker y de la prueba de que es la correcta.

php -v consulta el programa de línea de comandos, no el proceso que responde a las peticiones. La constante PHP_SAPI indica cuál habla: cli en línea de comandos, fpm-fcgi para PHP-FPM, apache2handler para Apache con mod_php. En una imagen única, las dos versiones casi siempre coinciden. La diferencia aparece en tres situaciones habituales con Docker: un docker compose run arranca un contenedor nuevo, es decir, desde la imagen local más reciente, mientras el servicio web sigue en la antigua; un contenedor cli de mantenimiento se construyó sobre otra etiqueta que el servicio web; un proxy inverso reenvía a un contenedor distinto del que usted inspecciona.

La prueba más fiable sigue siendo la petición HTTP: sigue el camino de un visitante y lee PHP_VERSION en el proceso que responde. El binario FPM se comprueba como complemento con docker exec <contenedor> php-fpm -v.

Una etiqueta de rama como php:8.3-fpm avanza en el siguiente pull: pasa a apuntar a la versión corregida. Una etiqueta exacta como php:8.3.36-fpm se queda en su versión, y una referencia por huella (@sha256:…) nunca se mueve. La documentación de docker image pull es explícita: con una huella, Docker no obtiene ninguna reconstrucción, correcciones de seguridad incluidas, hasta que usted cambie la huella.

Las etiquetas corregidas de la imagen oficial php llegaron a Docker Hub durante el día y la noche del 21 de octubre de 2026 (UTC), para las variantes FPM de las ramas 8.5, 8.4, 8.3 y 8.2. Las imágenes oficiales de WordPress php8.3-fpm, php8.4-fpm y php8.3-apache se republicaron el 22 de octubre de 2026 de madrugada (UTC), y las de Nextcloud el mismo día. Una imagen descargada antes de esos momentos es, por tanto, la antigua, aunque el nombre sea idéntico. Compruebe estas fechas en la página de cada etiqueta. La rama 8.2 recibe su corrección pero llega al fin de vida el 31 de diciembre de 2026: planifique su sustitución.

Para una imagen construida en casa a partir de FROM php:8.3-fpm, la secuencia son tres comandos: docker compose build --pull --no-cache, luego docker compose up -d --force-recreate, y por último la comprobación de la versión servida. Cada uno responde a una trampa concreta.

--pull es la opción que cambia la versión de PHP: pide a Docker que busque una versión más reciente de la imagen base en lugar de reutilizar la del servidor. Sin ella, el FROM se resuelve con la copia local y la construcción termina con el intérprete antiguo, sin un solo mensaje.

--no-cache reejecuta todas las capas, incluidas apt-get y composer install, lo que renueva también las bibliotecas del sistema y las dependencias. No hace falta para cambiar de PHP, porque cuando cambia la imagen base las capas siguientes se reconstruyen solas. Sirve cuando una capa en caché congela un paquete que quiere renovar.

--force-recreate recrea los contenedores aunque Compose considere que su configuración y su imagen no han cambiado. Así se elimina la duda sobre lo que está en marcha.

Reconstruir sus imágenes con cada corrección es un calendario que mantener, no un gesto único. En un VPS con acceso root, ese calendario es suyo, y nuestra guía para instalar Docker en un VPS sienta la base de trabajo.

Una etiqueta de WordPress combina una versión de WordPress, una versión de PHP y una variante, por ejemplo php8.3-apache o php8.3-fpm. La rama de PHP la elige el nombre de la etiqueta. Cambiar la versión de WordPress, o dejar que las actualizaciones automáticas actúen en el volumen de datos, no toca esa rama. Para obtener el PHP corregido hay que volver a descargar la etiqueta con docker compose pull y recrear el servicio. La variante Apache es la predeterminada y carga PHP como mod_php: es la que el proyecto PHP considera más expuesta, con un exploit demostrado antes de que se ejecute código de la aplicación. Trátela con prioridad.

Nextcloud sigue el mismo principio, en dos variantes: apache incluye un Apache completo, fpm necesita un servidor web delante. La documentación de la imagen describe la actualización como un reemplazo: descargar la imagen, tirar el contenedor antiguo, arrancar el nuevo. El código de Nextcloud y sus datos viven en el volumen /var/www/html, que la recreación del contenedor no borra. Vea también nuestra guía de WordPress en VPS y la de Nextcloud.

Con Octane y FrankenPHP no hay PHP-FPM: el servidor de aplicaciones incorpora el intérprete. Las imágenes oficiales de FrankenPHP se basan en las imágenes oficiales de PHP, y su etiqueta combina la versión de FrankenPHP, la de PHP y el sistema, con la forma dunglas/frankenphp:<version>-php8.4-trixie. El proyecto las reconstruye en cada versión y, cada día a las 4 h UTC, si existen nuevas imágenes oficiales de PHP. Su FROM dunglas/frankenphp solo recibe la corrección si reconstruye su imagen con --pull.

La trampa propia de Octane es el worker. Octane arranca la aplicación una vez y la mantiene en memoria: php artisan octane:reload reinicia con cuidado los workers para cargar el código desplegado. Es el gesto correcto tras un despliegue de código, pero no sustituye al intérprete, que sigue siendo el de la imagen en curso. Lo mismo ocurre con un kill -USR2 o una recarga de PHP-FPM lanzada en el contenedor antiguo: relanzan los mismos archivos, los de la imagen antigua. Para cambiar de PHP, recree el contenedor, incluidos los de los workers de colas y el planificador. Vea nuestra guía de Laravel Octane en VPS.

Las fuentes: los anuncios de seguridad y versiones de PHP, docker compose up, docker compose build, el atributo pull_policy, docker image pull, la imagen php, la imagen wordpress, la imagen de Nextcloud, FrankenPHP con Docker y Laravel Octane.