En resumen: en Windows con IIS, PHP suele funcionar como php-cgi.exe mediante FastCGI, un modo de funcionamiento expresamente afectado por PHP2Shell. Una actualización de PHP en IIS consta de tres pasos: localizar todas las instalaciones de PHP, sustituirlas por una versión corregida y reciclar los grupos de aplicaciones. Aquí, por lo general, no existen la gestión de paquetes ni los backports como en Linux.
Cómo funciona PHP en IIS
En los servidores Windows, IIS conecta PHP mediante el módulo FastCGI. Para cada versión de PHP hay una entrada FastCGI que apunta a un php-cgi.exe y una asignación de manejador que dirige hacia allí los archivos con la extensión .php. IIS inicia varios procesos php-cgi cuando hace falta y los mantiene activos para más solicitudes.
A diferencia de Linux, PHP aquí no suele proceder de un gestor de paquetes, sino de un archivo ZIP de las compilaciones para Windows del proyecto PHP, de una aplicación especializada o de instaladores antiguos. Esto significa que las actualizaciones no se hacen automáticamente y que no hay backports de un distribuidor. Lo decisivo es el número de versión de los archivos instalados.
Qué significa PHP2Shell para los servidores Windows
PHP2Shell comprende CVE-2026-109618 y CVE-2026-109619 en el propio PHP, cada una con un CVSS v4.0 de 9,2. Ambas permiten ejecutar código sin autenticación. El proyecto PHP cita expresamente php-cgi entre los modos de funcionamiento afectados. Están corregidas PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales. Según la experiencia, los servidores Windows con aplicaciones especializadas suelen funcionar con estas versiones, porque la aplicación exige una versión determinada. Aquí, además de las medidas provisionales, hace falta aclararlo con el fabricante de la aplicación. El contexto de este modo de funcionamiento está en php-cgi: una herencia con riesgo.
Actualizar PHP en IIS: localizar las instalaciones
Los siguientes comandos de PowerShell solo leen. Muestran qué instalaciones de PHP usa IIS y qué versión tienen. Las rutas son ejemplos.
# Entradas FastCGI en IIS: ¿qué php-cgi.exe se usa?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi
# Versión de cada instalación encontrada (ruta a modo de ejemplo)
& "C:\PHP\8.3\php.exe" -v
# Procesos php-cgi en ejecución con hora de inicio
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Busque además en todas las unidades otros php-cgi.exe, porque las aplicaciones especializadas a veces traen copias propias. Anote para cada instalación la versión, la variante (Thread Safe o Non Thread Safe) y la arquitectura.
Instalar la actualización y reciclar los grupos de aplicaciones
Descargue la versión corregida de las compilaciones oficiales para Windows del proyecto PHP, enlazadas desde php.net, en la misma variante y arquitectura. Ha dado buen resultado descomprimir la versión nueva en una carpeta nueva, trasladar el php.ini existente y las extensiones necesarias y cambiar después la entrada FastCGI a la ruta nueva. Así se conserva la versión anterior por si hay que volver atrás.
# Reciclar un grupo de aplicaciones (nombre a modo de ejemplo)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"
# Alternativamente, reiniciar todos los servicios de IIS
iisreset
# Control: ¿se iniciaron todos los procesos php-cgi después de la actualización?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Todo proceso php-cgi debe tener una hora de inicio posterior a la actualización y apuntar a la ruta nueva. Pruebe después los sitios web. Elimine la carpeta antigua de PHP en cuanto la versión nueva funcione de forma estable, para que no se vuelva a integrar por error.
Los archivos nuevos en la carpeta de PHP no bastan mientras sigan funcionando procesos php-cgi antiguos. Solo tras reciclar los grupos o reiniciar IIS es efectivo el parche.
Medidas provisionales en el php.ini
Si una instalación no puede actualizarse de inmediato, php.net recomienda medidas provisionales sin protección completa. En IIS se fijan los valores en el php.ini central de cada instalación. Según php.net, los archivos .user.ini e ini_set() no bastan.
; php.ini de la instalación afectada
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con función de carga de archivos, php.net indica post_max_size = 32M. En PHP 8.5 se añade fatal_error_backtraces=0. Para que los sitios web no modifiquen los valores mediante archivos .user.ini propios, puede dejarse vacío user_ini.filename en el php.ini central; compruebe antes si hay aplicaciones que dependan de ello. Después, recicle los grupos. El BSI recomienda desconectar temporalmente de la red los servidores web si la actualización no es posible de inmediato. Otros ajustes se explican en Configurar php.ini de forma segura.
Después de la actualización
Un parche no elimina el software malicioso introducido antes. Conserve los registros de IIS desde el 20/10/2026, revise los directorios web en busca de archivos de script nuevos y compruebe las tareas programadas y las cuentas de usuario locales en busca de elementos desconocidos. Si el servidor funciona en un dominio, también hay que echar un vistazo a los inicios de sesión.
Preste atención además a los permisos de las identidades de los grupos de aplicaciones. Si un grupo funciona con una cuenta que tiene permisos de escritura sobre todo el directorio web o incluso permisos administrativos, un atacante puede causar mucho más daño tras una intrusión exitosa. Es recomendable una identidad propia y restringida por grupo, con permisos de escritura solo donde la aplicación realmente los necesite, por ejemplo en la carpeta de cargas o de caché. En esas carpetas, IIS no debería ejecutar archivos PHP; esto puede regularse mediante las asignaciones de manejadores de cada carpeta. Compruebe también si en el directorio web quedan archivos antiguos de prueba e instalación, como salidas de phpinfo, y elimínelos.
¿Cómo ayuda PHP SOS en concreto?
- Encontramos todas las instalaciones de PHP en sus servidores Windows, también las copias dentro de aplicaciones especializadas.
- Mediante el servicio de parcheo de PHP sustituimos PHP, reciclamos los grupos y documentamos la versión y las horas de los procesos.
- Con versiones antiguas aclaramos con usted y con el fabricante de la aplicación el camino hacia la migración a una versión de PHP compatible.
- Revisamos los servidores en busca de rastros de un ataque y conservamos los registros.
Preguntas frecuentes
¿Qué variante de PHP necesito para IIS?
Para IIS con FastCGI se suele usar la variante Non-Thread-Safe (NTS). Al actualizar, asegúrese de elegir de nuevo la misma variante y arquitectura, para que las extensiones sigan encajando.
¿Basta con descomprimir la carpeta nueva de PHP?
No. IIS mantiene activos los procesos php-cgi.exe durante un tiempo. Recicle los grupos de aplicaciones o reinicie IIS y compruebe que ya no quedan procesos antiguos en marcha.
¿Puedo ejecutar varias versiones de PHP en un IIS?
Sí, mediante varias entradas FastCGI y asignaciones de manejadores por sitio web. Pero eso aumenta el esfuerzo de mantenimiento. Cada instalación necesita su propia actualización y su propio control.
¿Afecta PHP2Shell a PHP en Windows?
Las vulnerabilidades están en el propio PHP. En IIS, PHP suele funcionar como php-cgi, que el proyecto PHP incluye expresamente entre los modos de funcionamiento afectados. Trate por eso los servidores Windows con la misma urgencia que los servidores Linux.