Todas las notas

PHP php2shell: ¿dónde corre PHP en tu infraestructura?

5 min de lecturaRedactado con IA, editado y aprobado por Mat Caniglia

PHP corrigió el 21 de octubre dos fallas de ejecución remota sin autenticación. El desafío es encontrar el PHP que corre, incluido el de terceros.

El 21 de octubre de 2026, PHP publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para cerrar dos fallas críticas, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código remoto sin autenticación en cualquier PHP que atienda requests web. Lo difícil es encontrar PHP en imágenes de proveedores, appliances y apps de terceros, y reemplazar lo que siga en 8.1 o menos.

¿Qué pasó el 21 de octubre con PHP?

El proyecto PHP sacó cuatro versiones de parche el 21 de octubre de 2026 para cerrar dos fallas críticas que dejan a un atacante sin autenticar ejecutar código en el servidor. CISA publicó una alerta ese mismo día y pidió parchear de inmediato. El Centro Canadiense de Ciberseguridad emitió su propia alerta y la actualizó el 23 de octubre.

Las dos fallas son de tipo use after free y circulan con el apodo php2shell. Según el centro canadiense, están afectadas todas las versiones de 8.5, 8.4, 8.3 y 8.2 anteriores a las corregidas.

Cuando salieron las alertas no había explotación activa reportada. Igual, el centro canadiense menciona reportes de fuentes abiertas sobre una prueba de concepto pública, y avisa que eso puede cambiar rápido. Conviene tomar esta calma como algo pasajero.

El 23 de octubre el proyecto PHP informó un tercer problema, CVE-2026-115560, que las versiones del 21 no resuelven. Necesita una configuración poco común. La aplicación tiene que cambiar el serializador de sesión al handler php en tiempo de ejecución antes de iniciar la sesión, con el progreso de subida todavía habilitado. La mitigación provisoria es session.upload_progress.enabled=0, que el proyecto ya había recomendado para CVE-2026-109619.

¿Qué instalaciones de PHP están expuestas?

Está expuesta toda instalación de PHP que atienda requests web. El centro canadiense nombra PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto PHP considera a mod_php el caso de mayor riesgo, porque un exploit demostrado se dispara con un request sin autenticar antes de que corra cualquier código de la aplicación.

Ese detalle ordena el triage. En un host con mod_php, el middleware del framework, la validación de entradas y el login de la app nunca llegan a actuar. Primero van los servidores mod_php expuestos a internet, después el resto del PHP público, y al final las apps web internas.

Las versiones 8.1 y anteriores no reciben arreglo del proyecto PHP. Para esas quedan dos caminos: un backport confirmado por el proveedor o la migración a una rama con soporte.

¿Dónde se esconde PHP en tu infraestructura?

PHP suele estar escondido en software que nadie del equipo asocia con PHP. CISA advierte que muchas veces viene como componente de otro producto y no se ve a simple vista. El centro canadiense pide identificar productos de terceros, appliances y contenedores que lo traigan adentro.

Una forma práctica de partir la búsqueda es por quién controla la actualización.

Dónde corre PHP Cómo encontrarlo Cómo se parchea
Hosts que administrás vos Corré php -v para cada versión y listá lo que hay en /etc/php Actualizá todas las versiones instaladas y reiniciá PHP-FPM y los workers que quedan corriendo
Imágenes de contenedor Buscá un binario php en las capas o en los SBOM, incluidas imágenes base viejas clavadas a un tag Reconstruí sobre una base corregida y hacé deploy de nuevo, porque los contenedores que ya corren siguen con el binario viejo
Appliances y apps de proveedores Preguntale a cada proveedor si el producto trae PHP y en qué versión Update del proveedor, o aislamiento de red hasta que exista
Hosting administrado y paneles de gestión de servidores Leé las notas del proveedor sobre cómo instala y actualiza PHP Depende del proveedor, así que confirmalo en vez de suponerlo
PHP 8.1 o anterior Cualquier host o imagen que reporte 8.1 o menos Backport del proveedor o salto a 8.2 o superior

Las actualizaciones automáticas de seguridad sirven solo si cubren el paquete del que vino PHP. Si PHP llegó desde un repo de terceros, un build propio o un bundle de proveedor, puede que esas actualizaciones ni lo toquen. Un host puede parecer al día y seguir corriendo un build vulnerable. La única forma de saberlo es mirar la versión que está corriendo.

¿Qué tan difícil es el parche y qué puede salir mal?

En un host que controla el equipo, el parche es un upgrade de paquetes y un reinicio del servicio. Los procesos PHP persistentes, como los workers de colas, también hay que reiniciarlos. Cualquier proceso más viejo que el upgrade se trata como no parcheado hasta que reinicie.

Los paquetes pueden llegar tarde respecto del release de upstream, según quién los compile. Revisá la versión candidata antes de actualizar y la que corre después. Un deploy en verde no prueba nada si el gestor de paquetes bajó el build viejo.

Donde no se pueda parchear ya, el centro canadiense sugiere aislar de las redes públicas las aplicaciones expuestas a internet hasta aplicar el arreglo. Saltear todo esto deja a un atacante externo ejecutando código en el servidor web, con las credenciales, el acceso a datos y el alcance de red que tenga ese host.

Qué revisar esta semana

Ponele un tope de cinco días hábiles, arrancando hoy.

Día uno: armá el inventario. Consultá hosts, registries de contenedores y SBOMs buscando cualquier binario o paquete de PHP, y listá cada producto de proveedor que sirva una interfaz web. Marcá cuáles dan a internet y cuáles siguen con mod_php.

Día dos: pasá el PHP expuesto a internet a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, empezando por los hosts con mod_php. Reiniciá PHP-FPM, Apache y cada worker PHP que quede corriendo. Confirmá la versión que corre en cada host.

Día tres: reconstruí las imágenes de contenedor sobre bases corregidas y desplegalas. Poné session.upload_progress.enabled=0 en todos lados, salvo en apps que necesiten el progreso de subida y nunca cambien el serializador de sesión en runtime.

Día cuatro: pedile a cada proveedor cuyo producto trae PHP la versión incluida y una fecha de arreglo. Aislá cualquier appliance expuesto a internet que no tenga una respuesta creíble.

Día cinco: cerrá el hueco de 8.1 y anteriores. Confirmá que un backport del proveedor cubra los dos CVE o agendá un upgrade con fecha. Después revisá los logs de servidores web y endpoints desde el 21 de octubre, buscando procesos, archivos, cuentas o conexiones salientes inesperadas vinculadas a PHP o al servidor web.

Fuentes