FROM php:8.1-apache. Me encontré esa línea dos veces la semana pasada, en dos repositorios que nadie del equipo actual tocaba desde 2023, y las dos imágenes seguían respondiendo peticiones tan tranquilas el 22 de octubre, un día después de que el proyecto PHP publicara los parches para CVE-2026-109618 y CVE-2026-109619. Apache con mod_php, nada menos, justo la configuración que el equipo de PHP señaló como la más peligrosa. Los responsables de esos repos tuvieron una suerte que dudo que volvamos a ver. Core no se quedó en 8.2.35, 8.3.36, 8.4.27 y 8.5.12. También sacó parches mínimos de código fuente para 7.4, 8.0 y 8.1, tres ramas que ya habían salido del ciclo normal de soporte.

Eso merece un agradecimiento sincero, y también una lectura honesta. Alguien en php-src dedicó horas de emergencia a un código del que se había despedido formalmente, para que los equipos que nunca planificaron una actualización tuvieran una salida. Si tu plan para el próximo bug crítico del motor da por hecho, sin decirlo, que core volverá a hacerlo, estás planificando sobre un favor. Para la mayoría, la lección de PHP2Shell está en el calendario de actualizaciones, semanas antes de que se abra cualquier canal de incidentes.

Fíjate en lo que te da realmente un parche de código fuente: un diff. Para convertirlo en algo que corra en producción necesitas una build funcional del propio PHP, todas las extensiones que compilas contra él y alguien que todavía recuerde qué flags de configure usaba la imagen original. He visto a un equipo perder una tarde entera porque pdo_pgsql no enlazaba con su 8.0 compilado a mano. Y los equipos que mantienen un pipeline de builds de PHP en buen estado son, casi por definición, los que rara vez siguen en 8.1.

La objeción más fuerte merece que la escuchemos con justicia, porque es buena. Una cadena de versión antigua no convierte un servidor en negligente. Las distribuciones y los proveedores de LTS aplican backports de seguridad a sus paquetes sin subir al número de upstream, y el propio anuncio de PHP remitía a esos proveedores. Una máquina que muestra algo que parece prehistórico puede estar perfectamente cubierta por su proveedor, y yo nunca le diría a una empresa con una distro empresarial con soporte que entre en pánico por la salida de php -v.

Donde ese argumento deja de funcionar es en la diferencia entre un contrato y una costumbre. Un backport implica un proveedor con nombre, un aviso publicado y una referencia de paquete que puedes pegar en un ticket. Una imagen base fijada en 2023 y nunca reconstruida no tiene nada de eso. Solo parece estable porque todavía no se ha roto nada, que es exactamente el aspecto que tenía el 20 de octubre.

Lo que de verdad te cuesta la imagen rancia es velocidad. Cloudflare informó de tráfico de ataque, y de atacantes retocando sus payloads para esquivar sus reglas, y aun así pidió a sus clientes que parchearan PHP en lugar de fiarse del WAF. ENISA fue más allá: sugirió desconectar de la red las aplicaciones expuestas a internet si no se podían aplicar los parches, y advirtió de que PHP se esconde dentro de productos cuyos usuarios ni saben que está ahí. Aislar es la jugada para cuando no puedes desplegar. En una rama con soporte y con actualizaciones menores rutinarias, todo esto fue un martes aburrido: cambiar 8.3.35 por 8.3.36, dejar que corra la CI, desplegar e irse a comer. En 8.1 fue un proyecto de compilación con el reloj en contra.

Así que mi propuesta es aburrida a propósito. Deja que un bot abra la PR de la versión de parche cada vez que core publique una, y fusiónala esa misma semana salvo que los tests digan lo contrario. Ten una regla escrita sobre cuánto te permites quedarte por detrás de la rama con soporte más antigua, y trata saltártela como un bug con responsable. Haz los saltos de versión mayor dolorosos en un sprint tranquilo que elijas tú, porque la alternativa es hacerlos bajo un número de CVE y con los clientes mirando. Nada de esto es ingenioso. Simplemente convierte el próximo PHP2Shell de una emergencia en una línea del changelog, y evita que malgastemos la buena voluntad de quienes mantienen el runtime del que dependemos todos.

Esto es lo que de verdad me gustaría leer en los comentarios: ¿cuánto se ha quedado tu carga de producción más antigua por detrás de la rama de PHP con soporte más reciente ahora mismo y, siendo sincero, cuánto tardarías en tener una build parcheada sirviendo tráfico si el próximo aviso saliera mañana por la mañana?