PHP2Shell: medidas de seguridad en servidores empresariales

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.

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.

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.

1. Haga una lista de los sitios web y sistemas expuestos a Internet.
2. Revise los sitios desarrollados por terceros y los sitios antiguos.
3. Revise los servidores de eventos y de pruebas, y las páginas de administración.
4. Compruebe si las interfaces de administración de los equipos y las soluciones incluyen PHP.
5. Revise las imágenes de contenedores y los contenedores en ejecución.
6. 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.

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.

1. Revise el efecto del parche sobre las funciones existentes.
2. Compruebe la compatibilidad del servicio en un entorno de pruebas.
3. Aplique los paquetes corregidos, empezando por los servidores expuestos a Internet.
4. Reinicie todos los servicios que ejecutan PHP.
5. En entornos de contenedores, vuelva a desplegarlos con la imagen corregida.
6. 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

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.

1. Limite el tamaño de las solicitudes en el cortafuegos de aplicaciones web, el servidor web y el proxy.
2. Compruebe que los límites también se aplican a las solicitudes sin información de tamaño.
3. Si no se necesitan cargas de archivos, bloquee las solicitudes multipart antes de que lleguen a PHP.
4. Revise las reglas de bloqueo más recientes del cortafuegos de aplicaciones web.
5. Aplique la configuración en php.ini, en el pool de PHP-FPM u otras ubicaciones.
6. 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.

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.

1. Bloquee en la red el acceso externo al servidor.
2. Las empresas en Corea deben notificar el incidente desde el menú de notificación de incidentes de seguridad de 보호나라.
3. Conserve los registros y la lista de programas en ejecución.
4. Conserve también la información de las conexiones de red actuales.
5. Después de recopilar las pruebas, actualice y reinicie.
6. 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.

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.

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.