Em resumo: no Windows com IIS, o PHP corre normalmente como php-cgi.exe através de FastCGI, um modo de operação expressamente afetado pelo PHP2Shell. Uma atualização PHP no IIS consiste em três passos: encontrar todas as instalações PHP, substituí-las por uma versão corrigida e reciclar os pools de aplicações. Gestão de pacotes e backports como no Linux não existem aqui, em regra.
Como o PHP corre no IIS
Nos servidores Windows, o IIS liga o PHP através do módulo FastCGI. Para cada versão PHP existe uma entrada FastCGI que aponta para um php-cgi.exe e uma atribuição de handler que encaminha para aí os ficheiros com a extensão .php. O IIS inicia vários processos php-cgi conforme necessário e mantém-nos ativos para novos pedidos.
Ao contrário do Linux, o PHP aqui geralmente não vem de uma gestão de pacotes, mas de um arquivo ZIP das compilações Windows do projeto PHP, como parte de uma aplicação especializada ou de instaladores mais antigos. Isso significa: as atualizações não acontecem automaticamente e não há backports de um distribuidor. Conta o número de versão dos ficheiros instalados.
O que o PHP2Shell significa para os servidores Windows
O PHP2Shell engloba a CVE-2026-109618 e a CVE-2026-109619 no próprio PHP, cada uma com CVSS v4.0 9.2. Ambas permitem a execução de código sem autenticação. O projeto PHP indica expressamente o php-cgi entre os modos de operação afetados. Estão corrigidos o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Para o PHP 8.1 e anteriores já não existem atualizações oficiais. Os servidores Windows com aplicações especializadas correm, por experiência, muitas vezes nesses níveis, porque a aplicação exige uma determinada versão. Aqui, além das medidas provisórias, é necessário um esclarecimento com o fabricante da aplicação. O contexto deste modo de operação está em php-cgi: um legado com risco.
Atualização PHP no IIS: encontrar as instalações
Os comandos PowerShell seguintes apenas leem. Mostram que instalações PHP o IIS usa e que versão têm. Os caminhos são exemplos.
# Entradas FastCGI no IIS: que php-cgi.exe é utilizado?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi
# Versão de cada instalação encontrada (caminho como exemplo)
& "C:\PHP\8.3\php.exe" -v
# Processos php-cgi em execução com hora de arranque
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Procure além disso em todas as unidades outros php-cgi.exe, porque as aplicações especializadas trazem por vezes cópias próprias. Anote, por instalação, a versão, a variante (Thread Safe ou Non Thread Safe) e a arquitetura.
Instalar a atualização e reciclar os pools de aplicações
Descarregue a versão corrigida das compilações oficiais para Windows do projeto PHP, ligadas a partir do php.net, na mesma variante e arquitetura. Tem-se revelado eficaz descompactar a nova versão para uma pasta nova, aproveitar o php.ini existente e as extensões necessárias e só depois mudar a entrada FastCGI para o novo caminho. Assim, o nível antigo fica preservado para um eventual regresso.
# Reciclar o pool de aplicações (nome como exemplo)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"
# Em alternativa, reiniciar todos os serviços do IIS
iisreset
# Verificação: todos os processos php-cgi foram iniciados depois da atualização?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Cada processo php-cgi tem de ter uma hora de arranque posterior à atualização e apontar para o novo caminho. Teste depois os sites. Remova a pasta antiga do PHP assim que o novo nível funcionar de forma estável, para que não seja ligada de novo por engano.
Ficheiros novos na pasta do PHP não bastam enquanto houver processos php-cgi antigos a correr. Só depois de reciclar os pools ou de reiniciar o IIS é que o patch é eficaz.
Medidas provisórias no php.ini
Se uma instalação não puder ser atualizada de imediato, o php.net recomenda medidas provisórias sem proteção completa. No IIS, defina os valores no php.ini central da respetiva instalação. Ficheiros .user.ini e ini_set() não bastam, segundo o php.net.
; php.ini da instalação afetada
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Com função de upload, o php.net indica post_max_size = 32M. No PHP 8.5 acresce fatal_error_backtraces=0. Para que os sites não alterem os valores através de ficheiros .user.ini próprios, pode deixar-se user_ini.filename vazio no php.ini central; verifique antes se há aplicações que dependam disso. Depois, recicle os pools. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda retirar temporariamente os servidores web da rede quando a atualização não for possível de imediato. Outras definições são explicadas em Configurar o php.ini em segurança.
Depois da atualização
Um patch não remove software malicioso introduzido antes. Guarde os registos do IIS a partir de 20/10/2026, verifique nos diretórios web a presença de novos ficheiros de script e controle as tarefas agendadas e as contas de utilizador locais à procura de algo desconhecido. Se o servidor estiver num domínio, convém também olhar para os inícios de sessão.
Preste atenção, além disso, às permissões das identidades dos pools de aplicações. Se um pool correr com uma conta que tenha permissões de escrita em todo o diretório web ou até direitos administrativos, um atacante pode causar bastante mais danos depois de uma intrusão bem-sucedida. Faz sentido ter uma identidade própria e restrita por pool, com permissões de escrita apenas onde a aplicação realmente as precisa, por exemplo na pasta de uploads ou de cache. Nessas pastas, o IIS não deve executar ficheiros PHP; isso pode regular-se através das atribuições de handlers da respetiva pasta. Verifique também se há ficheiros antigos de teste e de instalação, como saídas de phpinfo, no diretório web, e remova-os.
Como ajuda concretamente a PHP SOS?
- Encontramos todas as instalações PHP nos seus servidores Windows, incluindo cópias dentro de aplicações especializadas.
- Através do serviço de patches PHP, trocamos o PHP, reciclamos os pools e documentamos a versão e as horas dos processos.
- Em versões antigas, esclarecemos consigo e com o fabricante da aplicação o caminho para a migração para uma versão PHP suportada.
- Verificamos os servidores quanto a vestígios de um ataque e preservamos os registos.
Perguntas frequentes
Que variante de PHP preciso para o IIS?
Para o IIS com FastCGI usa-se normalmente a variante Non-Thread-Safe (NTS). Na atualização, tenha o cuidado de escolher de novo a mesma variante e arquitetura, para que as extensões continuem a servir.
Basta descompactar a nova pasta do PHP?
Não. O IIS mantém os processos php-cgi.exe ativos durante algum tempo. Recicle os pools de aplicações ou reinicie o IIS e verifique que já não correm processos antigos.
Posso operar várias versões PHP no mesmo IIS?
Sim, através de várias entradas FastCGI e atribuições de handlers por site. Isso aumenta, porém, o esforço de manutenção. Cada instalação precisa da sua própria atualização e da sua própria verificação.
O PHP no Windows está afetado pelo PHP2Shell?
As vulnerabilidades estão no próprio PHP. No IIS, o PHP corre normalmente como php-cgi, que o projeto PHP inclui expressamente entre os modos de operação afetados. Trate por isso os servidores Windows com a mesma urgência que os servidores Linux.