Saltar al contenido principal

PHP2Shell: comprueba el entorno que sirve la web y revisa el aviso sobre sesiones

Las versiones de seguridad de PHP del 21 de octubre corrigen dos fallos críticos. Un aviso más específico del día 23 añade una revisión de configuración para algunas aplicaciones.

Una carcasa de servidor plateada sin marca y un destornillador sobre una mesa, con bastidores al fondo.
TechKili · Ilustración editorial generada con IA, Cloudflare Workers AI FLUX.2 klein.
Compartir este artículo:
En este artículo

Los responsables de webs que respondan a PHP2Shell deben comprobar el entorno de ejecución de PHP que atiende sus peticiones, aunque el gestor de contenidos ya esté actualizado. PHP publicó las correcciones el 21 de octubre de 2026; un aviso distinto sobre sesiones, limitado a condiciones concretas y publicado el día 23, también merece revisión antes de cerrar el trabajo.

La noticia de The Verge del 22 de octubre motivó este seguimiento. La orientación técnica procede de los avisos del proyecto PHP y del Centro Nacional de Ciberseguridad británico, NCSC; TechKili no ha realizado pruebas de explotación.

Localiza el entorno de ejecución detrás de la aplicación

Las dos vulnerabilidades afectan a la gestión de la memoria de las peticiones en PHP. CVE-2026-109618 implica un estado interno incompleto tras un error de falta de memoria; CVE-2026-109619 afecta a un estado que puede sobrevivir a la memoria de una petición. Ambas pueden permitir ejecutar código remotamente sin autenticación.

Por tanto, el mantenimiento necesario alcanza una capa inferior al código de la propia web. El primer aviso documenta un ataque funcional contra Apache mod_php antes de que se ejecute el código de la aplicación. También considera susceptible a PHP-FPM a partir del análisis del código, aunque indica que no se había demostrado una explotación completa de ese fallo en FPM. Que las pruebas difieran según el modo de ejecución no exime de aplicar las correcciones.

El anuncio de PHP identifica como versiones corregidas PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones y los proveedores de soporte prolongado pueden ofrecer correcciones adaptadas a sus paquetes. Consulta su aviso además del número de versión; PHP 8.1 y las ramas anteriores ya no reciben actualizaciones regulares del proyecto.

En un alojamiento gestionado, pide al proveedor que identifique el entorno corregido que atiende el tráfico web. Para un equipo de infraestructura, una constancia útil del trabajo relaciona cada servicio con el paquete que utiliza y confirma que sus procesos trabajadores ejecutan la compilación actualizada. Revisar únicamente la instalación de PHP de la línea de comandos puede dejar esa cuestión sin resolver.

Interpreta el aviso sobre sesiones del 23 de octubre dentro de sus límites

El aviso informativo de PHP del 23 de octubre describe otra vía poco probable de ejecución remota de código, identificada como CVE-2026-115560. Requiere que siga activado el progreso de carga de sesiones y que se produzca un cambio inusual del serializador configurado, de php_binary o php_serialize a php, durante la ejecución y antes de llamar a session_start().

PHP aconseja session.upload_progress.enabled=0 hasta la siguiente versión regular de corrección de errores. Según el aviso, las aplicaciones que nunca cambian el serializador durante la ejecución pueden mantener la función activada. Si ya se desactivó siguiendo las instrucciones del 21 de octubre, PHP indica que debe mantenerse así; esa medida no requiere ninguna actuación adicional.

Este seguimiento debe evaluarse junto con la actualización del entorno. Afirmar de forma general que todas las webs corregidas siguen siendo explotables iría más allá de las condiciones descritas por PHP.

Separa el cierre de la exposición del análisis de incidentes

La orientación del NCSC del 21 de octubre prioriza localizar las instalaciones de PHP, actualizar los sistemas expuestos a internet y seguir los avisos de proveedores cuyos productos incluyan PHP. Cuando no sea posible actualizar o mitigar con rapidez, aconseja valorar la desconexión de los sistemas afectados e investigar indicios de intrusión.

Para los operadores, esto supone conservar dos registros: la prueba de que se ha atendido el entorno vulnerable y cualquier investigación de lo sucedido antes del cambio. Una actualización correcta no demuestra que un servicio previamente expuesto nunca sufriera una intrusión. Del mismo modo, el anuncio de una vulnerabilidad no prueba que una web concreta haya sido atacada.

Fuentes