PHP2Shell: medidas de seguridad en servidores empresariales
La respuesta a PHP2Shell empieza por actualizar y reiniciar PHP en el servicio web en producción. Si se sospecha una intrusión, primero hay que conservar las pruebas. Incluso después de aplicar el parche, es necesario revisar los registros y cambiar las credenciales.
Comprueba el uso de PHP en los servidores en producción y los productos que lo llevan integrado.
Si sospechas una intrusión, aísla el servidor y conserva las pruebas antes de reiniciarlo.
Instala una versión corregida o aplica las medidas temporales oficiales hasta la actualización.
Reinicia los servicios que ejecutan PHP y comprueba que el parche se haya aplicado en el servicio web en producción.
Revisa los registros anteriores y cambia las credenciales de los servidores expuestos.
La respuesta a PHP2Shell comienza por comprobar dónde se usa PHP y aplicar las versiones corregidas. Después de actualizar, reinicie los servicios que lo ejecutan. Si sospecha de una intrusión, conserve las pruebas antes de reiniciar. Incluso después de aplicar el parche, es necesario revisar los registros y cambiar las credenciales.
Las versiones y la configuración se basan en el aviso de KISA del 22 de octubre de 2026 y en el aviso adicional de PHP del 23 de octubre.
¿Qué tipo de vulnerabilidad es PHP2Shell?
PHP2Shell es una vulnerabilidad de PHP que permite ejecutar código en el servidor sin autenticación. Se trata de un problema de gestión de memoria durante el procesamiento de solicitudes por el servidor web. El éxito del ataque depende del entorno de ejecución y de la configuración.
Categoría | Identificador | Naturaleza del problema
Problema en el tratamiento de la falta de memoria | CVE-2026-109618 | Procesamiento de datos internos incompletos en situaciones de falta de memoria
Problema de estado residual entre solicitudes | CVE-2026-109619 | Uso, en solicitudes posteriores, de un estado que apunta a memoria liberada
KISA indica que ambas vulnerabilidades tienen una gravedad de 9.2 puntos en CVSS. Si el ataque tiene éxito, es posible instalar una webshell o filtrar información de clientes. Una webshell es un archivo que se usa de forma maliciosa para controlar un servidor a distancia. El ataque también puede derivar en la alteración del sitio web y la intrusión en la red interna.
KISA informó de filtraciones de información e intentos de ataque antes de la distribución del parche. Los investigadores publicaron el proceso de descubrimiento de las vulnerabilidades con ayuda de IA. El problema está en el propio PHP y no se limita a un producto concreto para sitios web. Pautas de respuesta de KISA para empresas, Explicación de PHP2Shell de los investigadores
Orden de actuación según la situación
El orden de actualización y conservación de pruebas cambia según haya sospechas de intrusión. En las tareas habituales de aplicación de parches, se hacen pruebas antes de actualizar y reiniciar. Si sospecha de una intrusión en un servidor, aíslelo primero.
Estado actual | Primera medida | Medida posterior
Servidor expuesto a Internet sin indicios de intrusión | Revisar la compatibilidad y aplicar la versión corregida | Reiniciar, comprobar la versión que se ejecuta y revisar los registros
Detección de una webshell o de conexiones sospechosas | Aislar de la red y notificar el incidente | Conservar las pruebas y después tomar medidas de recuperación
Servidor que no se puede actualizar de inmediato | Aplicar la configuración temporal oficial y limitar las solicitudes antes de que lleguen a PHP | Establecer un calendario de aplicación del parche y aplicarlo
Servidor en el que tampoco se pueden aplicar medidas temporales | Valorar el bloqueo del acceso externo o la suspensión temporal | Decidir si se reanuda el servicio después de aplicar el parche
Entorno gestionado por un proveedor de alojamiento o un fabricante | Confirmar con la empresa responsable si se han aplicado las medidas | Obtener pruebas de que los cambios están activos en el entorno de ejecución
El reinicio después de actualizar sirve para ejecutar el código corregido. Durante la respuesta a un incidente, el reinicio se pospone para conservar las pruebas. Aunque se trate del mismo servidor, si hay sospechas de intrusión, siga este último orden.
Cómo comprobar dónde se usa PHP
Revise tanto el inventario de activos como los servidores que están en funcionamiento. Si solo revisa el sitio web principal, puede pasar por alto servidores que han quedado fuera de la gestión. También debe comprobar los equipos y contenedores que incluyen PHP.
· Haga una lista de los sitios web y sistemas expuestos a Internet.
· Revise los sitios desarrollados por terceros y los sitios antiguos.
· Revise los servidores de eventos y de pruebas, y las páginas de administración.
· Compruebe si las interfaces de administración de los equipos y las soluciones incluyen PHP.
· Revise las imágenes de contenedores y los contenedores en ejecución.
· Anote la versión de PHP y la persona responsable de la gestión de cada entorno.
Si usa un servicio de alojamiento, pida al proveedor que confirme si ha aplicado el parche. Para el PHP incluido en equipos, compruebe las actualizaciones del fabricante. Revise también los sistemas internos, pero actúe primero sobre los servidores expuestos a Internet.
Versiones corregidas de PHP y criterios de fin de soporte
La versión corregida de la rama 8.5 indicada en el aviso oficial de PHP es 8.5.12. El texto original de KISA indica la misma versión. Esto no significa que haya que esperar a 8.5.13 para aplicar el parche.
Rama utilizada | Versión que corrige ambas vulnerabilidades | Criterio de actuación
PHP 8.5 | 8.5.13 o posterior | Comprobar la última versión de seguridad de esta rama
PHP 8.4 | 8.4.27 o posterior | Comprobar la última versión de seguridad de esta rama
PHP 8.3 | 8.3.36 o posterior | Comprobar la última versión de seguridad de esta rama
PHP 8.2 | 8.2.35 o posterior | Preparar la migración a una rama superior junto con la aplicación del parche
PHP 8.1 o anterior | Soporte de seguridad ordinario finalizado | Migrar a una rama con soporte o comprobar los parches del proveedor
La tabla se basa en las versiones corregidas anunciadas el 21 de octubre de 2026. Los paquetes de las distribuciones pueden mantener el mismo número de versión visible. En ese caso, compruebe en el historial de cambios si se han corregido ambos CVE. Aviso de versiones de seguridad de PHP
El soporte de seguridad de PHP 8.2 finaliza el 31 de diciembre de 2026. KISA recomienda migrar a PHP 8.3 o posterior. Antes de migrar, pruebe la compatibilidad de las aplicaciones. Calendario de soporte de PHP
El soporte de seguridad ordinario de PHP 8.1 y versiones anteriores ya ha terminado. Los parches de las distribuciones o de los proveedores de soporte a largo plazo deben comprobarse por separado. Los parches del código fuente para versiones antiguas publicados en esta ocasión tampoco significan que se reanude el soporte ordinario.
Cómo actualizar y reiniciar
Después de sustituir los archivos de instalación, es necesario reiniciar los servicios que ejecutan PHP. Los procesos existentes pueden seguir ejecutando el código que permanece en memoria. Si sospecha de una intrusión, conserve las pruebas antes de hacer las tareas siguientes.
· Revise el efecto del parche sobre las funciones existentes.
· Compruebe la compatibilidad del servicio en un entorno de pruebas.
· Aplique los paquetes corregidos, empezando por los servidores expuestos a Internet.
· Reinicie todos los servicios que ejecutan PHP.
· En entornos de contenedores, vuelva a desplegarlos con la imagen corregida.
· Compruebe que los cambios están activos en el PHP que procesa las solicitudes web reales.
Entre los servicios que deben reiniciarse están PHP-FPM y Apache mod_php. Revise también php-cgi, FrankenPHP y LiteSpeed. Si el servidor tiene varios entornos PHP, debe comprobar cada uno.
php -v muestra la versión de PHP que se ejecuta en la línea de comandos. Puede ser distinta de la que usa el servicio web. No dé por terminada la actualización basándose solo en la salida de la línea de comandos.
Criterios de configuración temporal antes de actualizar
Las medidas temporales sirven para reducir algunas vías de ataque. No resuelven todas las vulnerabilidades. Si no puede aplicar la configuración, valore bloquear el acceso externo.
¿Cómo se aplica la configuración de memory_limit?
La recomendación temporal oficial para esta vulnerabilidad es memory_limit=-1. Este valor elimina el límite de uso de memoria del propio PHP. No lo considere una configuración de funcionamiento habitual.
Eliminar el límite reduce determinadas vías que provocan falta de memoria. Esta configuración no impide que se produzcan fallos reales de asignación de memoria. También debe valorar límites de tamaño de las solicitudes y medidas de gestión de recursos. Aviso sobre la vulnerabilidad de falta de memoria de PHP
Parámetro | Medida temporal oficial | Qué comprobar al aplicarla
memory_limit | Establecer en -1 | Aplicar la configuración de administrador para impedir que la aplicación la cambie
session.upload_progress.enabled | Establecer en 0 | Usar una ubicación de configuración que se aplique antes del procesamiento de las solicitudes
post_max_size | Ejemplo de 8M si no se necesitan cargas de archivos | Revisar tanto los requisitos reales del servicio como los límites previos a PHP
upload_max_filesize | Establecer un valor menor que post_max_size | Comprobar el efecto sobre la función de carga de archivos
fatal_error_backtraces | Establecer en 0 en PHP 8.5 | No aplicarlo de forma general a otras ramas
Los valores de la tabla se basan en los avisos oficiales de respuesta de octubre de 2026. 8M es un ejemplo propuesto para servicios que no necesitan cargas de archivos. No es un criterio para aplicar el mismo tamaño a todos los servicios.
· Limite el tamaño de las solicitudes en el cortafuegos de aplicaciones web, el servidor web y el proxy.
· Compruebe que los límites también se aplican a las solicitudes sin información de tamaño.
· Si no se necesitan cargas de archivos, bloquee las solicitudes multipart antes de que lleguen a PHP.
· Revise las reglas de bloqueo más recientes del cortafuegos de aplicaciones web.
· Aplique la configuración en php.ini, en el pool de PHP-FPM u otras ubicaciones.
· Compruebe si es necesario conservar pruebas y después reinicie los procesos PHP.
No aplique la configuración temporal solo con ini_set(). Las opciones necesarias antes de procesar las solicitudes podrían aplicarse demasiado tarde. Tampoco espere que .user.ini de PHP-FPM cumpla esa función. Medidas temporales oficiales de PHP
Qué comprobar en el aviso adicional del 23 de octubre
En el aviso adicional, PHP recomendó desactivar la función de progreso de carga. El aviso se refiere a otra vía de ejecución que persiste con algunas combinaciones de configuración. Si la función ya está desactivada, se indica que debe mantenerse así hasta la siguiente versión ordinaria de corrección de errores.
Entre las condiciones correspondientes está el cambio del método de serialización de sesiones durante la ejecución. Estas condiciones no se dan en todas las instalaciones de PHP. Consulte el aviso adicional para decidir si debe restaurar la configuración después de aplicar el parche. (Valor comprobado: se recomienda mantener session.upload_progress.enabled=0 hasta la siguiente versión ordinaria de corrección de errores · Fuente: php.net · Comprobado el 2026-10-23) Aviso adicional de PHP Session upload progress
Cómo revisar los registros y cambiar las credenciales
KISA recomienda revisar, como mínimo, los registros desde el 20 de octubre de 2026. Si es posible, revise también los registros anteriores. El parche no revierte las intrusiones ni las filtraciones de información que ya se hayan producido.
Elemento que revisar | Indicios que buscar
Registros del servidor web | Errores HTTP 500 repetidos
Registros de ejecución de PHP | Terminaciones anómalas y segfault
Carpetas web, de cargas y temporales | Archivos PHP nuevos o modificados
Registros de ejecución de procesos | Ejecución de sh, bash y herramientas de descarga por el servidor web
Conexiones de red | Indicios de nuevas conexiones a direcciones externas desconocidas
Sitio web y páginas de administración | Scripts externos añadidos sin autorización
La presencia de errores no basta para confirmar una intrusión. Del mismo modo, la ausencia de registros anómalos tampoco permite confirmar que el sistema sea seguro. KISA indica lo siguiente:
Aunque no haya anomalías en los registros, la seguridad no está garantizada, por lo que deben hacerse tanto la actualización como el cambio de credenciales. KISA, «Pautas de respuesta de seguridad para empresas ante las vulnerabilidades de PHP (PHP2Shell)»
Se recomienda cambiar las credenciales de los servidores que estaban expuestos a Internet antes de aplicar el parche. En los servidores donde se hayan encontrado indicios de intrusión, es imprescindible cambiarlas. Esto incluye las contraseñas de las bases de datos y de los administradores. Revise también la posible exposición de claves de API y tokens de acceso.
En los servicios conectados a bases de datos con información personal, revise también los registros de esas bases de datos. Es necesario buscar indicios de consultas masivas y extracción de datos. Limite también el acceso directo a phpMyAdmin desde Internet. Reduzca los permisos de base de datos de la cuenta del servicio web a lo estrictamente necesario. Aviso de medidas preventivas de 개인정보보호위원회
Orden de actuación ante una sospecha de intrusión
Si sospecha de una intrusión, no apague el servidor ni lo reinicie de inmediato. El reinicio puede borrar los rastros del ataque que quedan en memoria. Aísle el servidor de la red y después recopile las pruebas.
· Bloquee en la red el acceso externo al servidor.
· Las empresas en Corea deben notificar el incidente desde el menú de notificación de incidentes de seguridad de 보호나라.
· Conserve los registros y la lista de programas en ejecución.
· Conserve también la información de las conexiones de red actuales.
· Después de recopilar las pruebas, actualice y reinicie.
· Elimine las webshells y cambie las credenciales.
El canal de consulta en Corea es KISA 118. La ruta del menú es 보호나라 > Notificación de incidentes de seguridad > Enviar notificación. Si opera en el extranjero, consulte el canal de notificación de la región correspondiente.
Comparación de errores habituales
Para confirmar que se ha aplicado el parche, hay que comprobar también el estado de ejecución y el historial de cambios. El mensaje de instalación completada no basta. Incluya las siguientes comprobaciones en su lista.
Conclusión habitual | Qué debe comprobarse
Si cambia php -v, ya está todo hecho | Comprobar el PHP que usa realmente el servicio web
Basta con instalar el paquete | Confirmar el reinicio de los servicios que ejecutan PHP
Si el número de versión no cambia, no se han tomado medidas | Comprobar en el historial de cambios de la distribución si se han corregido los CVE
Si hay un cortafuegos de aplicaciones web, se puede omitir el parche | Revisar las reglas más recientes y actualizar PHP
Si los registros están limpios, no ha habido filtraciones | Revisar también la posible exposición de credenciales
En los sitios externalizados, el proveedor se encarga de todo | Pedir pruebas de la aplicación de las medidas para cada servicio
No ejecute en servidores de producción código de prueba encontrado en Internet. KISA advierte de PoC falsas que contienen código malicioso. Una PoC es un código de prueba que demuestra la posibilidad de explotar una vulnerabilidad. Para comprobar si un sistema es vulnerable, empiece por revisar la versión y el historial de parches.
Lista de comprobación del cierre de medidas en entornos externalizados o de alojamiento
Conviene que el informe de finalización de las medidas incluya pruebas de comprobación para cada servicio. La tabla siguiente agrupa las pautas de respuesta de KISA en puntos de comprobación operativa. No es un formulario oficial de presentación.
Punto de comprobación | Qué pedir al proveedor o a la persona responsable
Posibles elementos sin revisar | Lista de revisión de sitios web, páginas de administración y servidores de pruebas
Corrección de las vulnerabilidades | Versión aplicada o historial de cambios del paquete que mencione ambos CVE
Estado de ejecución | Registros del reinicio del servicio o del nuevo despliegue de contenedores
Aplicación efectiva | Entorno de ejecución de PHP comprobado en el servicio web
Revisión de intrusiones | Periodo de los registros revisados y hallazgos
Credenciales | Credenciales que deben cambiarse y estado del cambio
Tareas pendientes | Servidores que solo tienen medidas temporales y plan de aplicación posterior del parche
Por ejemplo, supongamos que el proveedor solo ha informado de que la instalación del paquete ha terminado. En ese caso, pida los resultados de la comprobación del reinicio y del entorno de ejecución web. La revisión de registros y el cambio de credenciales pueden comprobarse como puntos separados.
Injoys
