{"content_id":"vufynon7qa","slug":"php2shell-enterprise-security-patch-response-guide","locale":"es","schema_type":"HowTo","category":"how_to","category_name":"Cómo hacer","title":"PHP2Shell: medidas de seguridad en servidores empresariales","summary":"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.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"Equipo editorial de Injoys","url":"https://injoys.com/ko/about"},"key_points":["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."],"content_markdown":"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.\n\nLas 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.\n\n## ¿Qué tipo de vulnerabilidad es PHP2Shell?\n\nPHP2Shell 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.\n\n| Categoría | Identificador | Naturaleza del problema |\n| --- | --- | --- |\n| Problema en el tratamiento de la falta de memoria | CVE-2026-109618 | Procesamiento de datos internos incompletos en situaciones de falta de memoria |\n| Problema de estado residual entre solicitudes | CVE-2026-109619 | Uso, en solicitudes posteriores, de un estado que apunta a memoria liberada |\n\nKISA 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.\n\nKISA 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](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230), [Explicación de PHP2Shell de los investigadores](https://www.php2shell.com/)\n\n## Orden de actuación según la situación\n\nEl 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.\n\n| Estado actual | Primera medida | Medida posterior |\n| --- | --- | --- |\n| 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 |\n| 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 |\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 |\n| 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 |\n| 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 |\n\nEl 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.\n\n## Cómo comprobar dónde se usa PHP\n\nRevise 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.\n\n1. Haga una lista de los sitios web y sistemas expuestos a Internet.\n2. Revise los sitios desarrollados por terceros y los sitios antiguos.\n3. Revise los servidores de eventos y de pruebas, y las páginas de administración.\n4. Compruebe si las interfaces de administración de los equipos y las soluciones incluyen PHP.\n5. Revise las imágenes de contenedores y los contenedores en ejecución.\n6. Anote la versión de PHP y la persona responsable de la gestión de cada entorno.\n\nSi 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.\n\n## Versiones corregidas de PHP y criterios de fin de soporte\n\nLa 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.\n\n| Rama utilizada | Versión que corrige ambas vulnerabilidades | Criterio de actuación |\n| --- | --- | --- |\n| PHP 8.5 | 8.5.13 o posterior | Comprobar la última versión de seguridad de esta rama |\n| PHP 8.4 | 8.4.27 o posterior | Comprobar la última versión de seguridad de esta rama |\n| PHP 8.3 | 8.3.36 o posterior | Comprobar la última versión de seguridad de esta rama |\n| PHP 8.2 | 8.2.35 o posterior | Preparar la migración a una rama superior junto con la aplicación del parche |\n| PHP 8.1 o anterior | Soporte de seguridad ordinario finalizado | Migrar a una rama con soporte o comprobar los parches del proveedor |\n\nLa 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](https://www.php.net/archive/2026.php)\n\nEl 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](https://www.php.net/supported-versions.php)\n\nEl 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.\n\n## Cómo actualizar y reiniciar\n\nDespué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.\n\n1. Revise el efecto del parche sobre las funciones existentes.\n2. Compruebe la compatibilidad del servicio en un entorno de pruebas.\n3. Aplique los paquetes corregidos, empezando por los servidores expuestos a Internet.\n4. Reinicie todos los servicios que ejecutan PHP.\n5. En entornos de contenedores, vuelva a desplegarlos con la imagen corregida.\n6. Compruebe que los cambios están activos en el PHP que procesa las solicitudes web reales.\n\nEntre 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.\n\n`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.\n\n## Criterios de configuración temporal antes de actualizar\n\nLas 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.\n\n### ¿Cómo se aplica la configuración de memory_limit?\n\nLa 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.\n\nEliminar 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](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)\n\n| Parámetro | Medida temporal oficial | Qué comprobar al aplicarla |\n| --- | --- | --- |\n| `memory_limit` | Establecer en `-1` | Aplicar la configuración de administrador para impedir que la aplicación la cambie |\n| `session.upload_progress.enabled` | Establecer en `0` | Usar una ubicación de configuración que se aplique antes del procesamiento de las solicitudes |\n| `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 |\n| `upload_max_filesize` | Establecer un valor menor que `post_max_size` | Comprobar el efecto sobre la función de carga de archivos |\n| `fatal_error_backtraces` | Establecer en `0` en PHP 8.5 | No aplicarlo de forma general a otras ramas |\n\nLos 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.\n\n1. Limite el tamaño de las solicitudes en el cortafuegos de aplicaciones web, el servidor web y el proxy.\n2. Compruebe que los límites también se aplican a las solicitudes sin información de tamaño.\n3. Si no se necesitan cargas de archivos, bloquee las solicitudes multipart antes de que lleguen a PHP.\n4. Revise las reglas de bloqueo más recientes del cortafuegos de aplicaciones web.\n5. Aplique la configuración en `php.ini`, en el pool de PHP-FPM u otras ubicaciones.\n6. Compruebe si es necesario conservar pruebas y después reinicie los procesos PHP.\n\nNo 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](https://www.php.net/archive/2026.php)\n\n### Qué comprobar en el aviso adicional del 23 de octubre\n\nEn 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.\n\nEntre 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](https://www.php.net/archive/2026.php)\n\n## Cómo revisar los registros y cambiar las credenciales\n\nKISA 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.\n\n| Elemento que revisar | Indicios que buscar |\n| --- | --- |\n| Registros del servidor web | Errores HTTP 500 repetidos |\n| Registros de ejecución de PHP | Terminaciones anómalas y segfault |\n| Carpetas web, de cargas y temporales | Archivos PHP nuevos o modificados |\n| Registros de ejecución de procesos | Ejecución de sh, bash y herramientas de descarga por el servidor web |\n| Conexiones de red | Indicios de nuevas conexiones a direcciones externas desconocidas |\n| Sitio web y páginas de administración | Scripts externos añadidos sin autorización |\n\nLa 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:\n\n\u003e 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.\n\u003e\n\u003e KISA, «Pautas de respuesta de seguridad para empresas ante las vulnerabilidades de PHP (PHP2Shell)»\n\nSe 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.\n\nEn 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 개인정보보호위원회](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588)\n\n## Orden de actuación ante una sospecha de intrusión\n\nSi 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.\n\n1. Bloquee en la red el acceso externo al servidor.\n2. Las empresas en Corea deben notificar el incidente desde el menú de notificación de incidentes de seguridad de 보호나라.\n3. Conserve los registros y la lista de programas en ejecución.\n4. Conserve también la información de las conexiones de red actuales.\n5. Después de recopilar las pruebas, actualice y reinicie.\n6. Elimine las webshells y cambie las credenciales.\n\nEl canal de consulta en Corea es KISA 118. La ruta del menú es 보호나라 \u003e Notificación de incidentes de seguridad \u003e Enviar notificación. Si opera en el extranjero, consulte el canal de notificación de la región correspondiente.\n\n## Comparación de errores habituales\n\nPara 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.\n\n| Conclusión habitual | Qué debe comprobarse |\n| --- | --- |\n| Si cambia `php -v`, ya está todo hecho | Comprobar el PHP que usa realmente el servicio web |\n| Basta con instalar el paquete | Confirmar el reinicio de los servicios que ejecutan PHP |\n| 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 |\n| Si hay un cortafuegos de aplicaciones web, se puede omitir el parche | Revisar las reglas más recientes y actualizar PHP |\n| Si los registros están limpios, no ha habido filtraciones | Revisar también la posible exposición de credenciales |\n| En los sitios externalizados, el proveedor se encarga de todo | Pedir pruebas de la aplicación de las medidas para cada servicio |\n\nNo 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.\n\n## Lista de comprobación del cierre de medidas en entornos externalizados o de alojamiento\n\nConviene 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.\n\n| Punto de comprobación | Qué pedir al proveedor o a la persona responsable |\n| --- | --- |\n| Posibles elementos sin revisar | Lista de revisión de sitios web, páginas de administración y servidores de pruebas |\n| Corrección de las vulnerabilidades | Versión aplicada o historial de cambios del paquete que mencione ambos CVE |\n| Estado de ejecución | Registros del reinicio del servicio o del nuevo despliegue de contenedores |\n| Aplicación efectiva | Entorno de ejecución de PHP comprobado en el servicio web |\n| Revisión de intrusiones | Periodo de los registros revisados y hallazgos |\n| Credenciales | Credenciales que deben cambiarse y estado del cambio |\n| Tareas pendientes | Servidores que solo tienen medidas temporales y plan de aplicación posterior del parche |\n\nPor 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.","content_html":"\u003cp\u003eLa 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.\u003c/p\u003e\n\u003cp\u003eLas 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#qu%C3%A9-tipo-de-vulnerabilidad-es-php2shell\" class=\"anchor\" id=\"qué-tipo-de-vulnerabilidad-es-php2shell\"\u003e\u003c/a\u003e¿Qué tipo de vulnerabilidad es PHP2Shell?\u003c/h2\u003e\n\u003cp\u003ePHP2Shell 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoría\u003c/th\u003e\n\u003cth\u003eIdentificador\u003c/th\u003e\n\u003cth\u003eNaturaleza del problema\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eProblema en el tratamiento de la falta de memoria\u003c/td\u003e\n\u003ctd data-label=\"Identificador\"\u003eCVE-2026-109618\u003c/td\u003e\n\u003ctd data-label=\"Naturaleza del problema\"\u003eProcesamiento de datos internos incompletos en situaciones de falta de memoria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eProblema de estado residual entre solicitudes\u003c/td\u003e\n\u003ctd data-label=\"Identificador\"\u003eCVE-2026-109619\u003c/td\u003e\n\u003ctd data-label=\"Naturaleza del problema\"\u003eUso, en solicitudes posteriores, de un estado que apunta a memoria liberada\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eKISA 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.\u003c/p\u003e\n\u003cp\u003eKISA 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. \u003ca href=\"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026amp;menuNo=205020\u0026amp;nttId=72230\"\u003ePautas de respuesta de KISA para empresas\u003c/a\u003e, \u003ca href=\"https://www.php2shell.com/\"\u003eExplicación de PHP2Shell de los investigadores\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#orden-de-actuaci%C3%B3n-seg%C3%BAn-la-situaci%C3%B3n\" class=\"anchor\" id=\"orden-de-actuación-según-la-situación\"\u003e\u003c/a\u003eOrden de actuación según la situación\u003c/h2\u003e\n\u003cp\u003eEl 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEstado actual\u003c/th\u003e\n\u003cth\u003ePrimera medida\u003c/th\u003e\n\u003cth\u003eMedida posterior\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Estado actual\"\u003eServidor expuesto a Internet sin indicios de intrusión\u003c/td\u003e\n\u003ctd data-label=\"Primera medida\"\u003eRevisar la compatibilidad y aplicar la versión corregida\u003c/td\u003e\n\u003ctd data-label=\"Medida posterior\"\u003eReiniciar, comprobar la versión que se ejecuta y revisar los registros\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Estado actual\"\u003eDetección de una webshell o de conexiones sospechosas\u003c/td\u003e\n\u003ctd data-label=\"Primera medida\"\u003eAislar de la red y notificar el incidente\u003c/td\u003e\n\u003ctd data-label=\"Medida posterior\"\u003eConservar las pruebas y después tomar medidas de recuperación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Estado actual\"\u003eServidor que no se puede actualizar de inmediato\u003c/td\u003e\n\u003ctd data-label=\"Primera medida\"\u003eAplicar la configuración temporal oficial y limitar las solicitudes antes de que lleguen a PHP\u003c/td\u003e\n\u003ctd data-label=\"Medida posterior\"\u003eEstablecer un calendario de aplicación del parche y aplicarlo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Estado actual\"\u003eServidor en el que tampoco se pueden aplicar medidas temporales\u003c/td\u003e\n\u003ctd data-label=\"Primera medida\"\u003eValorar el bloqueo del acceso externo o la suspensión temporal\u003c/td\u003e\n\u003ctd data-label=\"Medida posterior\"\u003eDecidir si se reanuda el servicio después de aplicar el parche\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Estado actual\"\u003eEntorno gestionado por un proveedor de alojamiento o un fabricante\u003c/td\u003e\n\u003ctd data-label=\"Primera medida\"\u003eConfirmar con la empresa responsable si se han aplicado las medidas\u003c/td\u003e\n\u003ctd data-label=\"Medida posterior\"\u003eObtener pruebas de que los cambios están activos en el entorno de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEl 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#c%C3%B3mo-comprobar-d%C3%B3nde-se-usa-php\" class=\"anchor\" id=\"cómo-comprobar-dónde-se-usa-php\"\u003e\u003c/a\u003eCómo comprobar dónde se usa PHP\u003c/h2\u003e\n\u003cp\u003eRevise 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eHaga una lista de los sitios web y sistemas expuestos a Internet.\u003c/li\u003e\n\u003cli\u003eRevise los sitios desarrollados por terceros y los sitios antiguos.\u003c/li\u003e\n\u003cli\u003eRevise los servidores de eventos y de pruebas, y las páginas de administración.\u003c/li\u003e\n\u003cli\u003eCompruebe si las interfaces de administración de los equipos y las soluciones incluyen PHP.\u003c/li\u003e\n\u003cli\u003eRevise las imágenes de contenedores y los contenedores en ejecución.\u003c/li\u003e\n\u003cli\u003eAnote la versión de PHP y la persona responsable de la gestión de cada entorno.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSi 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#versiones-corregidas-de-php-y-criterios-de-fin-de-soporte\" class=\"anchor\" id=\"versiones-corregidas-de-php-y-criterios-de-fin-de-soporte\"\u003e\u003c/a\u003eVersiones corregidas de PHP y criterios de fin de soporte\u003c/h2\u003e\n\u003cp\u003eLa versión corregida de la rama 8.5 indicada en el aviso oficial de PHP es \u003cstrong\u003e8.5.12\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eRama utilizada\u003c/th\u003e\n\u003cth\u003eVersión que corrige ambas vulnerabilidades\u003c/th\u003e\n\u003cth\u003eCriterio de actuación\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rama utilizada\"\u003ePHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"Versión que corrige ambas vulnerabilidades\"\u003e8.5.13 o posterior\u003c/td\u003e\n\u003ctd data-label=\"Criterio de actuación\"\u003eComprobar la última versión de seguridad de esta rama\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rama utilizada\"\u003ePHP 8.4\u003c/td\u003e\n\u003ctd data-label=\"Versión que corrige ambas vulnerabilidades\"\u003e8.4.27 o posterior\u003c/td\u003e\n\u003ctd data-label=\"Criterio de actuación\"\u003eComprobar la última versión de seguridad de esta rama\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rama utilizada\"\u003ePHP 8.3\u003c/td\u003e\n\u003ctd data-label=\"Versión que corrige ambas vulnerabilidades\"\u003e8.3.36 o posterior\u003c/td\u003e\n\u003ctd data-label=\"Criterio de actuación\"\u003eComprobar la última versión de seguridad de esta rama\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rama utilizada\"\u003ePHP 8.2\u003c/td\u003e\n\u003ctd data-label=\"Versión que corrige ambas vulnerabilidades\"\u003e8.2.35 o posterior\u003c/td\u003e\n\u003ctd data-label=\"Criterio de actuación\"\u003ePreparar la migración a una rama superior junto con la aplicación del parche\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rama utilizada\"\u003ePHP 8.1 o anterior\u003c/td\u003e\n\u003ctd data-label=\"Versión que corrige ambas vulnerabilidades\"\u003eSoporte de seguridad ordinario finalizado\u003c/td\u003e\n\u003ctd data-label=\"Criterio de actuación\"\u003eMigrar a una rama con soporte o comprobar los parches del proveedor\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLa 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. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eAviso de versiones de seguridad de PHP\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eEl 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. \u003ca href=\"https://www.php.net/supported-versions.php\"\u003eCalendario de soporte de PHP\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eEl 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#c%C3%B3mo-actualizar-y-reiniciar\" class=\"anchor\" id=\"cómo-actualizar-y-reiniciar\"\u003e\u003c/a\u003eCómo actualizar y reiniciar\u003c/h2\u003e\n\u003cp\u003eDespué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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eRevise el efecto del parche sobre las funciones existentes.\u003c/li\u003e\n\u003cli\u003eCompruebe la compatibilidad del servicio en un entorno de pruebas.\u003c/li\u003e\n\u003cli\u003eAplique los paquetes corregidos, empezando por los servidores expuestos a Internet.\u003c/li\u003e\n\u003cli\u003eReinicie todos los servicios que ejecutan PHP.\u003c/li\u003e\n\u003cli\u003eEn entornos de contenedores, vuelva a desplegarlos con la imagen corregida.\u003c/li\u003e\n\u003cli\u003eCompruebe que los cambios están activos en el PHP que procesa las solicitudes web reales.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eEntre 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ephp -v\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#criterios-de-configuraci%C3%B3n-temporal-antes-de-actualizar\" class=\"anchor\" id=\"criterios-de-configuración-temporal-antes-de-actualizar\"\u003e\u003c/a\u003eCriterios de configuración temporal antes de actualizar\u003c/h2\u003e\n\u003cp\u003eLas 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#c%C3%B3mo-se-aplica-la-configuraci%C3%B3n-de-memory_limit\" class=\"anchor\" id=\"cómo-se-aplica-la-configuración-de-memory_limit\"\u003e\u003c/a\u003e¿Cómo se aplica la configuración de memory_limit?\u003c/h3\u003e\n\u003cp\u003eLa recomendación temporal oficial para esta vulnerabilidad es \u003ccode\u003ememory_limit=-1\u003c/code\u003e. Este valor elimina el límite de uso de memoria del propio PHP. No lo considere una configuración de funcionamiento habitual.\u003c/p\u003e\n\u003cp\u003eEliminar 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. \u003ca href=\"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w\"\u003eAviso sobre la vulnerabilidad de falta de memoria de PHP\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eParámetro\u003c/th\u003e\n\u003cth\u003eMedida temporal oficial\u003c/th\u003e\n\u003cth\u003eQué comprobar al aplicarla\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parámetro\"\u003e\u003ccode\u003ememory_limit\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporal oficial\"\u003eEstablecer en \u003ccode\u003e-1\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"Qué comprobar al aplicarla\"\u003eAplicar la configuración de administrador para impedir que la aplicación la cambie\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parámetro\"\u003e\u003ccode\u003esession.upload_progress.enabled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporal oficial\"\u003eEstablecer en \u003ccode\u003e0\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"Qué comprobar al aplicarla\"\u003eUsar una ubicación de configuración que se aplique antes del procesamiento de las solicitudes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parámetro\"\u003e\u003ccode\u003epost_max_size\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporal oficial\"\u003eEjemplo de \u003ccode\u003e8M\u003c/code\u003e si no se necesitan cargas de archivos\u003c/td\u003e\n\u003ctd data-label=\"Qué comprobar al aplicarla\"\u003eRevisar tanto los requisitos reales del servicio como los límites previos a PHP\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parámetro\"\u003e\u003ccode\u003eupload_max_filesize\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporal oficial\"\u003eEstablecer un valor menor que \u003ccode\u003epost_max_size\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"Qué comprobar al aplicarla\"\u003eComprobar el efecto sobre la función de carga de archivos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parámetro\"\u003e\u003ccode\u003efatal_error_backtraces\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporal oficial\"\u003eEstablecer en \u003ccode\u003e0\u003c/code\u003e en PHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"Qué comprobar al aplicarla\"\u003eNo aplicarlo de forma general a otras ramas\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLos valores de la tabla se basan en los avisos oficiales de respuesta de octubre de 2026. \u003ccode\u003e8M\u003c/code\u003e 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eLimite el tamaño de las solicitudes en el cortafuegos de aplicaciones web, el servidor web y el proxy.\u003c/li\u003e\n\u003cli\u003eCompruebe que los límites también se aplican a las solicitudes sin información de tamaño.\u003c/li\u003e\n\u003cli\u003eSi no se necesitan cargas de archivos, bloquee las solicitudes multipart antes de que lleguen a PHP.\u003c/li\u003e\n\u003cli\u003eRevise las reglas de bloqueo más recientes del cortafuegos de aplicaciones web.\u003c/li\u003e\n\u003cli\u003eAplique la configuración en \u003ccode\u003ephp.ini\u003c/code\u003e, en el pool de PHP-FPM u otras ubicaciones.\u003c/li\u003e\n\u003cli\u003eCompruebe si es necesario conservar pruebas y después reinicie los procesos PHP.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNo aplique la configuración temporal solo con \u003ccode\u003eini_set()\u003c/code\u003e. Las opciones necesarias antes de procesar las solicitudes podrían aplicarse demasiado tarde. Tampoco espere que \u003ccode\u003e.user.ini\u003c/code\u003e de PHP-FPM cumpla esa función. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eMedidas temporales oficiales de PHP\u003c/a\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#qu%C3%A9-comprobar-en-el-aviso-adicional-del-23-de-octubre\" class=\"anchor\" id=\"qué-comprobar-en-el-aviso-adicional-del-23-de-octubre\"\u003e\u003c/a\u003eQué comprobar en el aviso adicional del 23 de octubre\u003c/h3\u003e\n\u003cp\u003eEn 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.\u003c/p\u003e\n\u003cp\u003eEntre 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) \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eAviso adicional de PHP Session upload progress\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#c%C3%B3mo-revisar-los-registros-y-cambiar-las-credenciales\" class=\"anchor\" id=\"cómo-revisar-los-registros-y-cambiar-las-credenciales\"\u003e\u003c/a\u003eCómo revisar los registros y cambiar las credenciales\u003c/h2\u003e\n\u003cp\u003eKISA recomienda revisar, como mínimo, los registros \u003cstrong\u003edesde el 20 de octubre de 2026\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eElemento que revisar\u003c/th\u003e\n\u003cth\u003eIndicios que buscar\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eRegistros del servidor web\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eErrores HTTP 500 repetidos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eRegistros de ejecución de PHP\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eTerminaciones anómalas y segfault\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eCarpetas web, de cargas y temporales\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eArchivos PHP nuevos o modificados\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eRegistros de ejecución de procesos\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eEjecución de sh, bash y herramientas de descarga por el servidor web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eConexiones de red\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eIndicios de nuevas conexiones a direcciones externas desconocidas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Elemento que revisar\"\u003eSitio web y páginas de administración\u003c/td\u003e\n\u003ctd data-label=\"Indicios que buscar\"\u003eScripts externos añadidos sin autorización\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLa 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:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAunque 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.\u003c/p\u003e\n\u003cp\u003eKISA, «Pautas de respuesta de seguridad para empresas ante las vulnerabilidades de PHP (PHP2Shell)»\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003cp\u003eEn 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. \u003ca href=\"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026amp;mCode=C010010000\u0026amp;nttId=12588\"\u003eAviso de medidas preventivas de 개인정보보호위원회\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#orden-de-actuaci%C3%B3n-ante-una-sospecha-de-intrusi%C3%B3n\" class=\"anchor\" id=\"orden-de-actuación-ante-una-sospecha-de-intrusión\"\u003e\u003c/a\u003eOrden de actuación ante una sospecha de intrusión\u003c/h2\u003e\n\u003cp\u003eSi 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eBloquee en la red el acceso externo al servidor.\u003c/li\u003e\n\u003cli\u003eLas empresas en Corea deben notificar el incidente desde el menú de notificación de incidentes de seguridad de 보호나라.\u003c/li\u003e\n\u003cli\u003eConserve los registros y la lista de programas en ejecución.\u003c/li\u003e\n\u003cli\u003eConserve también la información de las conexiones de red actuales.\u003c/li\u003e\n\u003cli\u003eDespués de recopilar las pruebas, actualice y reinicie.\u003c/li\u003e\n\u003cli\u003eElimine las webshells y cambie las credenciales.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eEl canal de consulta en Corea es KISA 118. La ruta del menú es 보호나라 \u0026gt; Notificación de incidentes de seguridad \u0026gt; Enviar notificación. Si opera en el extranjero, consulte el canal de notificación de la región correspondiente.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#comparaci%C3%B3n-de-errores-habituales\" class=\"anchor\" id=\"comparación-de-errores-habituales\"\u003e\u003c/a\u003eComparación de errores habituales\u003c/h2\u003e\n\u003cp\u003ePara 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eConclusión habitual\u003c/th\u003e\n\u003cth\u003eQué debe comprobarse\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eSi cambia \u003ccode\u003ephp -v\u003c/code\u003e, ya está todo hecho\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003eComprobar el PHP que usa realmente el servicio web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eBasta con instalar el paquete\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003eConfirmar el reinicio de los servicios que ejecutan PHP\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eSi el número de versión no cambia, no se han tomado medidas\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003eComprobar en el historial de cambios de la distribución si se han corregido los CVE\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eSi hay un cortafuegos de aplicaciones web, se puede omitir el parche\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003eRevisar las reglas más recientes y actualizar PHP\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eSi los registros están limpios, no ha habido filtraciones\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003eRevisar también la posible exposición de credenciales\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusión habitual\"\u003eEn los sitios externalizados, el proveedor se encarga de todo\u003c/td\u003e\n\u003ctd data-label=\"Qué debe comprobarse\"\u003ePedir pruebas de la aplicación de las medidas para cada servicio\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eNo 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-comprobaci%C3%B3n-del-cierre-de-medidas-en-entornos-externalizados-o-de-alojamiento\" class=\"anchor\" id=\"lista-de-comprobación-del-cierre-de-medidas-en-entornos-externalizados-o-de-alojamiento\"\u003e\u003c/a\u003eLista de comprobación del cierre de medidas en entornos externalizados o de alojamiento\u003c/h2\u003e\n\u003cp\u003eConviene 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePunto de comprobación\u003c/th\u003e\n\u003cth\u003eQué pedir al proveedor o a la persona responsable\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003ePosibles elementos sin revisar\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eLista de revisión de sitios web, páginas de administración y servidores de pruebas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eCorrección de las vulnerabilidades\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eVersión aplicada o historial de cambios del paquete que mencione ambos CVE\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eEstado de ejecución\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eRegistros del reinicio del servicio o del nuevo despliegue de contenedores\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eAplicación efectiva\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eEntorno de ejecución de PHP comprobado en el servicio web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eRevisión de intrusiones\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003ePeriodo de los registros revisados y hallazgos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eCredenciales\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eCredenciales que deben cambiarse y estado del cambio\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Punto de comprobación\"\u003eTareas pendientes\u003c/td\u003e\n\u003ctd data-label=\"Qué pedir al proveedor o a la persona responsable\"\u003eServidores que solo tienen medidas temporales y plan de aplicación posterior del parche\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003ePor 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.\u003c/p\u003e\n","tags":["Protección de datos","PHP","Actualizaciones de seguridad"],"faqs":[{"question":"¿Se puede bloquear PHP2Shell cambiando la contraseña de inicio de sesión?","answer":"Puede explotarse sin iniciar sesión, por lo que cambiar la contraseña no basta para resolverlo. Es necesario aplicar una actualización de seguridad de PHP. Cambiar las credenciales es una medida aparte para responder a una posible filtración."},{"question":"En PHP 8.5, ¿hay que esperar a la versión 8.5.13?","answer":"Los avisos originales de PHP y KISA indican que la versión que corrige ambas vulnerabilidades es la 8.5.13. Esto no significa que haya que esperar a la 8.5.13. Al aplicar la actualización, compruebe también cuál es la última versión oficial de esa rama."},{"question":"¿No hace falta hacer comprobaciones si se usa PHP-FPM?","answer":"PHP-FPM también debe revisarse. Las condiciones del ataque pueden variar según el modo de ejecución. No determine si un entorno es seguro solo por su nombre."},{"question":"¿Las medidas están completas si el resultado de php -v muestra una versión corregida?","answer":"El PHP de la línea de comandos puede ser distinto del PHP del servicio web. Compruebe el entorno que procesa las solicitudes web reales. También debe comprobar si se ha reiniciado el servicio en ejecución."},{"question":"¿Ha fallado el parche si el número de versión no cambia después de aplicarlo?","answer":"Los paquetes de la distribución o del fabricante pueden incorporar las correcciones a la versión existente. Compruebe en el historial de cambios del paquete si se han incluido las correcciones de ambos CVE."},{"question":"¿Está prohibida la configuración memory_limit=-1 en la respuesta a estas vulnerabilidades?","answer":"La recomendación provisional oficial para estas vulnerabilidades incluye esa configuración. Debe distinguirse de las recomendaciones generales de funcionamiento. Revise también los límites de solicitudes y las medidas de gestión de recursos."},{"question":"¿También están afectados los sitios que no permiten subir archivos?","answer":"No se puede descartar que un sitio esté afectado solo porque no tenga una función de subida de archivos. Como se trata de vulnerabilidades del propio PHP, compruebe la versión utilizada y el estado de los parches. Bloquear las solicitudes multipart innecesarias es una medida provisional."},{"question":"¿Se puede seguir usando PHP 8.1 o una versión anterior si hay un parche del proveedor?","answer":"Hay que comprobar los parches del proveedor al margen del fin del soporte ordinario. Aunque aplique ese parche de forma provisional, prepare un plan para migrar a una versión con soporte."},{"question":"¿Se pueden mantener las credenciales si no hay anomalías en los registros?","answer":"Los registros por sí solos no permiten determinar que no haya habido una filtración de información. KISA recomienda cambiar las credenciales de los servidores que estuvieron expuestos a Internet antes de aplicar el parche. Si hay indicios de intrusión, debe cambiarlas sin falta."},{"question":"Si se sospecha una intrusión, ¿hay que actualizar primero?","answer":"Primero, aísle el sistema de la red. Notifique el incidente y recopile las pruebas antes de actualizar. Un reinicio puede borrar los rastros del ataque que queden en la memoria."},{"question":"¿Qué deben comprobar los usuarios de servicios de alojamiento?","answer":"Solicite al proveedor pruebas de la aplicación de los parches en cada servicio. Pida también los resultados de la comprobación del reinicio y del entorno real de ejecución web. Compruebe por separado si se han revisado los registros y cambiado las credenciales."},{"question":"¿Se puede volver a activar la configuración del progreso de subida después de aplicar el parche?","answer":"Consulte el aviso adicional de PHP del 23 de octubre de 2026. Se recomienda mantener la función desactivada debido a problemas adicionales en algunas combinaciones de configuración. Decida si restablecer la configuración después de comprobar las correcciones posteriores."}],"sources":[{"url":"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230","title":"KISA 보호나라: pautas de respuesta de seguridad para empresas ante la vulnerabilidad de seguridad de PHP (PHP2Shell), 22 de octubre de 2026","type":"source"},{"url":"https://www.php.net/archive/2026.php","title":"Aviso de PHP de 2026: actualización de seguridad del 21 de octubre e información adicional sobre Session upload progress del 23 de octubre","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w","title":"Aviso de seguridad de PHP: RCE por corrupción debida a OOM","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp","title":"Aviso de seguridad de PHP: RCE por un estado global obsoleto","type":"source"},{"url":"https://www.php.net/supported-versions.php","title":"PHP Supported Versions: período de soporte oficial","type":"data_point"},{"url":"https://www.php2shell.com/","title":"PHP2Shell: explicación de los investigadores sobre la vulnerabilidad y el alcance de su impacto","type":"source"},{"url":"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588","title":"개인정보보호위원회: llamamiento a tomar medidas para prevenir la filtración de datos personales ante la vulnerabilidad de seguridad de PHP, 22 de octubre de 2026","type":"source"}],"images":[{"id":2106,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.","caption":"침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존해야 합니다.","description":null},"en":{"alt":"A woman holds a blue Ethernet cable connector near a rack server’s network port in a server room.","caption":"If a compromise is suspected, isolate the server and preserve evidence before restarting.","description":null},"ja":{"alt":"サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。","caption":"侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全する必要があります。","description":null},"es":{"alt":"Una mujer sostiene el conector de un cable Ethernet azul junto al puerto de un servidor en una sala de servidores.","caption":"Si se sospecha una intrusión, hay que aislar el servidor y preservar las pruebas antes de reiniciarlo.","description":null},"id":{"alt":"Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.","caption":"Jika dicurigai terjadi penyusupan, isolasi server dan amankan bukti sebelum memulai ulang.","description":null},"pt":{"alt":"Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.","caption":"Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.","description":null},"zh-hant":{"alt":"一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。","caption":"若懷疑遭到入侵，應先隔離伺服器，並在重新啟動前保全證據。","description":null},"de":{"alt":"Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.","caption":"Bei Verdacht auf einen Angriff muss der Server isoliert und müssen vor dem Neustart Beweise gesichert werden.","description":null}}},{"id":2107,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습","caption":"PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스에 패치가 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"An older technician checks a tablet status screen beside an open network equipment cabinet in a factory.","caption":"After restarting PHP services, verify that the patch has taken effect on the live web service.","description":null},"ja":{"alt":"工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者","caption":"PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。","description":null},"es":{"alt":"Un técnico mayor revisa una tableta junto a un armario abierto con equipos de red en una fábrica.","caption":"Tras reiniciar los servicios de PHP, compruebe que el parche se haya aplicado al servicio web en producción.","description":null},"id":{"alt":"Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.","caption":"Setelah memulai ulang layanan PHP, pastikan patch telah diterapkan pada layanan web yang beroperasi.","description":null},"pt":{"alt":"Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.","caption":"Após reiniciar os serviços PHP, confirme que a correção foi aplicada ao serviço web em produção.","description":null},"zh-hant":{"alt":"一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面","caption":"重新啟動 PHP 執行服務後，應確認實際運作的網頁服務已套用修補程式。","description":null},"de":{"alt":"Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.","caption":"Prüfen Sie nach dem Neustart der PHP-Dienste, ob der Patch im laufenden Webdienst wirksam ist.","description":null}}}],"published_at":"2026-10-24T16:09:48+09:00","updated_at":"2026-10-24T16:09:48+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/es/articles/php2shell-enterprise-security-patch-response-guide"}