Atualizações de segurança PHP
PHP2Shell: verificar o runtime PHP em uso
A resposta a PHP2Shell exige inventário de runtimes, atualização controlada, reinício de workers e testes da aplicação, com registo separado das pendências.
A resposta a PHP2Shell exige mais do que confirmar um pacote instalado. É preciso identificar o PHP que serve os pedidos web e o runtime usado pelos processos agendados.
Inventariar os runtimes antes de alterar pacotes
Um servidor gerido pode ter várias instalações de PHP. Os sites podem usar pools FPM diferentes, enquanto os processos agendados usam o executável de linha de comandos do sistema. Atualizar uma instalação pode deixar outra carga de trabalho numa versão diferente.
O aviso de segurança do PHP identifica as CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell, e as versões de segurança publicadas. Inclui também orientações posteriores sobre o progresso de uploads de sessão. Estas atualizações devem ser lidas em conjunto com os avisos do fornecedor dos pacotes.
No trabalho anonimizado que serve de base a esta nota, foram mapeados os runtimes web e as dependências dos processos agendados antes da atualização. O inventário revelou uma versão antiga de linha de comandos ao lado de um runtime web mais recente. A intervenção incluiu, por isso, testes de compatibilidade.
É neste ponto que o suporte de servidores geridos se cruza com a manutenção da aplicação: o inventário precisa de explicar que operações dependem de cada runtime.
Verificar os processos depois da atualização
As intervenções documentadas incluíram cópias das configurações, atualização de pacotes PHP, validação de configuração e reinício dos serviços FPM afetados. Depois foram verificadas as versões dos processos em execução. O pacote instalado, por si só, não responderia a esta última questão.
Onde foi necessário migrar a versão antiga de linha de comandos, foram executados cenários de compatibilidade nos dois runtimes antes da mudança e repetidos depois. Foram observadas execuções agendadas, sem emitir documentos financeiros ou enviar mensagens operacionais apenas para demonstrar que um script executava.
É necessário manter um caminho de recuperação e uma lista dos serviços afetados. O plano de rollback deve explicar como repor o serviço e como gerir a exposição de segurança resultante. Regressar a um runtime vulnerável não constitui uma correção concluída.
Os controlos temporários de configuração também devem ser acompanhados pelo aviso que os justificou. A atualização de pacotes não deve remover silenciosamente um controlo que continua relevante para outra vulnerabilidade.
Comunicar os limites da validação
As verificações registadas abrangeram configuração de serviços, versões em execução, endpoints selecionados, respostas de saúde e observação de processos agendados. Não foram observadas regressões nesses testes. Esta conclusão tem um âmbito definido e não significa que todos os processos de negócio tenham sido percorridos.
Falhas anteriores de certificados, DNS e autenticação em serviços externos foram registadas separadamente. Não ficaram resolvidas por se atualizar o PHP, nem devem ser atribuídas à atualização sem evidência.
A passagem de trabalho deve distinguir pacotes atualizados, workers verificados, testes de compatibilidade realizados e pendências. Deve também separar correção de vulnerabilidades de investigação de intrusão. Uma atualização bem-sucedida não prova que nunca existiu um compromisso anterior.
Uma revisão de remediação e uma passagem de trabalho com contexto de incidente tornam estes limites claros sem publicar clientes, endereços de servidores ou evidência interna.
Conclusão prática
- Mapear separadamente PHP web, CLI e processos agendados.
- Verificar os workers em execução depois de atualizar os pacotes.
- Testar compatibilidade sem provocar operações financeiras ou comunicações reais.
- Manter falhas independentes e percursos não testados na passagem de trabalho.