Quando uma sequência de vulnerabilidades em PHP entra no radar, a reação mais comum é sair atualizando tudo no escuro. Isso pode ser tão ruim quanto ignorar o alerta: você perde tempo, corre risco de quebrar uma aplicação e ainda não sabe o que estava exposto.
O caminho útil é transformar a notícia em inventário e decisão. O CTIR Gov recomendou conferir as atualizações de segurança de 21 de outubro para as CVEs 2026-109618 e 2026-109619. Também alertou para a CVE-2026-115560, cujo cenário de exploração depende de uma combinação específica envolvendo session.serialize_handler e session.upload_progress. Isso pede prioridade, mas não pânico.
Comece pelo que realmente roda PHP
Liste aplicações, versões de PHP, imagens de container, servidores, jobs e serviços de terceiros que você administra. Não confie só no repositório principal: CMS, painéis antigos, integrações e máquinas de homologação costumam ficar fora do inventário mental. Para cada item, registre ambiente, responsável, versão e janela segura para intervenção.
Confira versão e canal de atualização
Compare a versão instalada com os releases de segurança do projeto PHP. Em um servidor, php -v ajuda; em containers, confira a imagem efetivamente implantada, não apenas o Dockerfile. Se a distribuição empacota o PHP, valide também o boletim do fornecedor. Atualização aplicada no ambiente de build não resolve uma imagem antiga que continua em produção.
Veja se a condição específica existe antes de mexer em tudo
Para a CVE-2026-115560, o comunicado oficial aponta duas condições: alteração de session.serialize_handler durante a execução e uso de session.upload_progress. Aplicações que não mudam esse parâmetro em runtime não entram nesse cenário. Se a equipe não puder confirmar rapidamente, a mitigação temporária indicada é desabilitar o acompanhamento de upload com session.upload_progress.enabled=0, avaliando antes o efeito nas telas que mostram progresso.
Atualize com rollback, não com torcida
Faça backup verificável, defina a versão-alvo e rode um teste curto do fluxo crítico: login, upload, sessão, pagamento ou integração que sustenta a aplicação. Em ambiente com múltiplos nós, atualize de forma escalonada. O que interessa não é só a versão subir; é conseguir voltar se extensão, cache de opcode ou dependência legada reagir mal.
Procure sinais de abuso enquanto o patch avança
Revise picos de erro, arquivos inesperados, processos estranhos, alterações de configuração e requisições anômalas nos serviços expostos. Não transforme um alerta em afirmação de invasão; trate-o como motivo para aumentar a observação. Se houver indício de comprometimento, preserve evidências e siga o plano de resposta a incidentes da organização.
O item que evita repetir o susto
Feche a rodada atualizando o inventário: versão, data, responsável e pendência. A próxima falha crítica chega mais rápido do que a documentação interna. Quem consegue responder “onde usamos PHP e como atualizamos?” reduz horas de incerteza para uma sequência de tarefas verificáveis.
