En resumen: La imagen oficial de PHP en Docker Hub existe en muchos tags que combinan versión, variante (por ejemplo cli, fpm, apache) y sistema base. Un tag es un puntero que se mueve a niveles nuevos tras las reconstrucciones; solo el digest designa exactamente un nivel. Frente a PHP2Shell necesita una imagen con PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, comprobada con php -v, y una reconstrucción de sus propias imágenes sobre ella.
Por qué el tag por sí solo dice poco
Muchos equipos escriben en su Dockerfile una línea como FROM php:8.3-fpm y luego se olvidan. Funciona mientras nadie pregunte qué versión de PHP se está ejecutando en realidad. Desde PHP2Shell, todo el mundo pregunta.
La respuesta no está en el Dockerfile. Un tag como 8.3-fpm apunta, en el momento de la descarga, al nivel más reciente de esa rama. Si la imagen se descargó antes del 21 de octubre y no se ha renovado desde entonces, contiene una versión vulnerable aunque hoy el tag apunte a un nivel corregido. Según las directrices de las Docker Official Images, las imágenes se reconstruyen activamente, también ante correcciones de seguridad. Pero su nivel local no se ve afectado por ello.
El procedimiento completo, desde la reconstrucción hasta el contenedor recreado, lo describe Parchear PHP en contenedores Docker. Aquí se trata de la cuestión previa: ¿qué imagen es la correcta y cómo acredita su nivel?
Tags de imágenes Docker de PHP: cómo están formados
Los tags se componen de hasta tres partes. Docker Hub muestra ejemplos como php:8.2-cli, php:8.2-fpm-alpine o php:8.4.27-zts-alpine3.24.
| Componente | Ejemplo | Significado |
|---|---|---|
| Indicación de versión | 8.4.27 o 8.4 |
la versión completa permanece en este nivel; la indicación de rama se mueve con los parches nuevos |
| Variante | cli, fpm, apache, zts |
modo de funcionamiento de PHP en el contenedor |
| Sistema base | alpine3.24, bookworm, trixie |
versión de Alpine o Debian subyacente |
Las variantes no son equivalentes ante PHP2Shell. fpm ejecuta PHP-FPM, apache ejecuta PHP como módulo de Apache, es decir, mod_php. El equipo de PHP clasifica este modo de funcionamiento como el más alto, porque allí se demostró un exploit antes de que se ejecute siquiera código de la aplicación. Más información en Por qué mod_php está especialmente expuesto. La variante cli está pensada para tareas de línea de comandos.
El sistema base también tiene consecuencias. Las imágenes Alpine son pequeñas, pero usan una biblioteca C distinta de la de las imágenes Debian; algunas extensiones o bibliotecas precompiladas se comportan allí de otra manera. Por ello, no cambie el sistema base de pasada con la actualización de seguridad, sino quédese al principio con lo que conoce su aplicación.
Importante para entenderlo: en la imagen oficial, PHP no procede de los paquetes de la distribución base. Docker Hub describe que las fuentes de PHP están en la imagen y que las extensiones se incorporan mediante scripts auxiliares como docker-php-ext-install. Una actualización de paquetes del sistema base en su propio Dockerfile no cambia, por tanto, la versión de PHP. Lo único determinante es sobre qué nivel de la imagen oficial construye usted.
Tag o digest: qué cambia y cuándo
Un digest es una suma de comprobación sobre el contenido de una imagen, escrita como sha256: con una larga cadena de caracteres. Cambia con cada reconstrucción. Por eso sirve como justificante: quien conoce el digest sabe exactamente qué nivel se está ejecutando.
En la práctica ha dado buen resultado un reparto del trabajo:
- En el Dockerfile usar el tag de rama, por ejemplo
php:8.4-fpm, para que una reconstrucción reciba automáticamente el parche más reciente de esa rama. - En el despliegue usar el digest de su propia imagen ya construida, para que quede claro qué se entrega.
- En la documentación anotar ambos: tag, digest y la versión comprobada con
php -v.
Quien en cambio fija un tag de versión completo como 8.3.35-fpm, nunca recibe un parche automáticamente. Puede ser deseado, pero exige un proceso que suba el tag con cada aviso de seguridad.
PHP2Shell: comprobar una imagen antes de usarla
Los siguientes comandos descargan una imagen y leen información. No modifican ningún contenedor en ejecución.
# Descargar el nivel actual del tag de rama
docker pull php:8.4-fpm
# ¿Qué versión de PHP hay en la imagen?
docker run --rm php:8.4-fpm php -v
# Mostrar el digest de la imagen descargada
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Consultar digest y plataformas directamente en el registro
docker buildx imagetools inspect php:8.4-fpm
La consulta con imagetools muestra en las imágenes multiplataforma un digest superior y, debajo, uno propio por plataforma, por ejemplo linux/amd64 o linux/arm64. Documente el digest que sus servidores descargan realmente y tenga en cuenta que los equipos de desarrollo con otra arquitectura reciben un digest de plataforma distinto.
Si php -v no muestra al menos la versión corregida de la rama, la imagen está obsoleta o procede de una caché intermedia. Compruebe entonces si su entorno usa un espejo de registro que sirve niveles antiguos.
Para PHP 8.1 y anteriores, el proyecto PHP ya no ofrece versiones oficiales. Por ello, una imagen oficial de esas ramas no puede contener una versión corregida regular. Los tags que ya no se mantienen siguen disponibles según las directrices de Docker, pero ya no se actualizan.
Según Docker Hub, la imagen incluye php.ini-development y php.ini-production y recomienda encarecidamente la versión de producción para el uso productivo. Sus propios ajustes los coloca como archivo en $PHP_INI_DIR/conf.d/, también los valores provisionales de php.net.
Errores típicos al elegir la imagen
- Variante por costumbre: se elige la variante apache porque arranca fácilmente, aunque fpm con un servidor web separado sería posible.
- Sin reconstrucción de las propias imágenes: la imagen base está actualizada, la imagen de aplicación construida a partir de ella no.
- Builds de varias etapas pasados por alto: en un Dockerfile con varias líneas
FROMsolo se ajusta una. - Imágenes secundarias olvidadas: los workers, los contenedores cron y las herramientas de administración usan tags propios.
- Apostar solo por
latest: el tag no dice nada sobre rama y variante y puede saltar inesperadamente con una rama principal nueva.
Cómo automatizar las reconstrucciones para que una imagen obsoleta ni siquiera esté mucho tiempo en marcha lo describe CI/CD: reconstruir automáticamente las imágenes de PHP. Los fundamentos de PHP en contenedores los explica PHP en contenedores.
¿Cómo ayuda PHP SOS en concreto?
- Revisar el inventario: leemos qué tags, digests y versiones de PHP hay en sus imágenes y contenedores en ejecución.
- Valorar la variante: comprobamos si mod_php es necesario o si fpm con un servidor web separado reduce el riesgo.
- Reconstruir y acreditar: con el servicio de parcheo de PHP reconstruimos las imágenes sobre una base corregida y documentamos tag, digest y versión.
- Anclar el proceso: configuramos Dockerfiles y despliegues para que el próximo parche llegue de forma planificable.
Preguntas frecuentes
¿Cuál es la diferencia entre tag y digest?
Un tag como php:8.4-fpm es un nombre que, tras cada reconstrucción, puede apuntar a un nivel nuevo. Un digest es una suma de comprobación que designa exactamente un nivel inmutable. Para justificantes y despliegues reproducibles, el digest es el dato más fiable.
¿Qué tag contiene la corrección de PHP2Shell?
Están corregidos PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Un tag con el número de versión completo indica directamente el nivel. Con tags más cortos como 8.4-fpm, compruebe con php -v, tras descargar, qué versión contiene realmente.
¿Existe una imagen oficial parcheada para PHP 8.1?
El proyecto PHP ya no ofrece versiones oficiales para la 8.1 y anteriores. Por ello, una imagen oficial de esas ramas no puede contener una versión corregida regular. Planifique el cambio a una rama compatible.
¿Es la variante apache más arriesgada que fpm?
La variante apache ejecuta PHP como módulo de Apache, es decir, mod_php. El equipo de PHP clasifica este modo de funcionamiento como el más alto en PHP2Shell. Ambas variantes necesitan la actualización; con mod_php hay que darse especial prisa.