Empieza por el entorno que realmente atiende el sitio

La corrección principal para las dos vulnerabilidades conocidas como PHP2Shell es actualizar PHP. El cuidado operativo consiste en identificar qué instalación necesita actualizarse y confirmar que el cambio llegó al servicio que recibe las solicitudes.

Este procedimiento es una verificación defensiva. No es necesario ejecutar un ataque para empezar a evaluar la exposición. Identificar el runtime, el paquete, la configuración y el origen de la actualización permite decidir sin provocar fallos en producción.

Comprueba el runtime web, además de la línea de comandos

La versión devuelta por php -v informa sobre el ejecutable invocado en el terminal. El sitio puede utilizar otro binario, una versión seleccionada en el panel del alojamiento o un contenedor propio. Comprueba el servicio y el pool asociados a la aplicación, incluyendo la ruta que realmente utiliza el servidor web. (PHP — opciones de línea de comandos)

Realiza esta comprobación mediante acceso administrativo restringido. Evita dejar una página phpinfo disponible públicamente: puede revelar versiones, rutas, configuración y variables del entorno. Si necesitas un diagnóstico temporal, limita el acceso y elimínalo después de verificar. (PHP — información expuesta por phpinfo)

Compara la instalación con una fuente confiable

En las versiones upstream, las correcciones para CVE-2026-109618 y CVE-2026-109619 se publicaron en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Los registros publicados por el propio PHP identifican esos límites en las respectivas series. (Registro CVE-2026-109618, registro CVE-2026-109619)

Si la distribución o el proveedor aplica backports, una versión aparentemente anterior puede incluir el parche. Comprueba el paquete completo, el repositorio de origen y el comunicado de seguridad del mantenedor. Conserva esa evidencia. Un número aislado o un resultado genérico de un escáner no cierra el análisis.

Para PHP sin soporte upstream, confirma la cobertura real del proveedor y planifica la migración. Actualizar el framework o los plugins no demuestra que el intérprete que ejecuta la aplicación esté corregido.

Aplica el cambio al servicio correcto

Antes del cambio, dispón de una copia recuperable, un procedimiento de reversión y una validación de compatibilidad proporcional al sistema. Eso ayuda a ejecutar una actualización urgente sin descubrir durante el cambio que nadie sabe restaurar el servicio.

En instalaciones mediante paquetes, utiliza el canal confiable de la distribución o del alojamiento y reinicia o recarga los servicios de forma que todos los workers antiguos sean sustituidos. Confirma que el procedimiento realmente terminó los procesos anteriores.

En Docker, obtén la imagen corregida o reconstruye la aplicación sobre una base actualizada. Después, recrea los contenedores que utilizan esa imagen. Descargar una imagen nueva no sustituye automáticamente un contenedor ya en ejecución. Docker informó de la actualización de las imágenes oficiales para estas vulnerabilidades. (Docker — imágenes PHP actualizadas, Docker — recreación de contenedores)

Verifica todas las instancias y registra la finalización

Repite la comprobación en las réplicas, los pools adicionales y los servicios que incorporan su propio PHP. El entorno puede responder mediante distintas instancias detrás de un balanceador. Corregir solo una deja incompleta la entrega. (NCSC-NL — inventario y verificación)

Después del cambio, confirma el runtime activo, realiza comprobaciones de salud y valida autenticación, formularios, cargas e integraciones relevantes. Registra el paquete o la imagen, la fecha, el responsable y los resultados. El criterio de finalización debe demostrar qué está ejecutándose, además de mostrar que un comando terminó sin errores.

Si existen indicios de compromiso, trata la investigación por separado. Aplicar el parche no elimina automáticamente cambios indebidos ni sustituye el análisis de credenciales y registros.

Incluye la precaución adicional del 23 de octubre

El aviso del 23/10/2026 recomienda session.upload_progress.enabled=0 hasta el próximo bugfix para una configuración de sesión poco habitual, seguida como CVE-2026-115560. Consulta las condiciones en el aviso. (PHP — actualización sobre sesiones)

Aplica la configuración en php.ini o en el pool/servidor, antes del análisis de la petición, y reinicia todos los workers. Cambiarla solo mediante ini_set() en la aplicación no basta. (PHP — aplicación de la mitigación de sesión)

Las fuentes técnicas de este artículo se consultaron el 23 de octubre de 2026. Sigue los avisos del proyecto y de tu proveedor: las nuevas orientaciones deben incorporarse al procedimiento, incluso después de la primera actualización.

El laboratorio mostrado en el vídeo

El vídeo utiliza un laboratorio con Apache, PHP y Docker para explicar la identificación y corrección del problema. Su aplicación práctica en cada empresa empieza por conocer el propio entorno y termina con la confirmación de la actualización. (Ver el vídeo en Instagram)