Como atualizar o PHP do Sury contra as falhas CVE-2026-109618 e CVE-2026-109619

Resumo: Os CVE-2026-109618 e CVE-2026-109619 são falhas críticas no runtime do PHP. Em servidores Debian e Ubuntu que usam pacotes do Sury, é necessário atualizar os pacotes PHP a partir do repositório configurado, reiniciar o serviço que atende os sites e confirmar que a versão instalada contém a correção. A versão do comando php -v, sozinha, não confirma a correção de todas as versões e serviços PHP do servidor.

Os CVE-2026-109618 e CVE-2026-109619 afetam o próprio PHP, não apenas um CMS ou aplicação. Por isso, atualizar WordPress, Joomla, Magento ou outro sistema sem atualizar o runtime PHP não corrige essas falhas. O PHP publicou versões corrigidas para os ramos 8.2, 8.3, 8.4 e 8.5; para outras versões, é preciso verificar se o fornecedor do pacote publicou uma correção retroportada. O anúncio oficial do PHP 8.2.35 classifica essa versão como uma atualização de segurança.

Este guia é para servidores Debian ou Ubuntu que instalam PHP pelos repositórios de Ondřej Surý — incluindo packages.sury.org/php e instalações Ubuntu que ainda usam o PPA ondrej/php. Confira primeiro qual repositório e quais versões estão ativos no servidor. Não adicione um segundo repositório nem migre a origem dos pacotes sem entender como isso afetará as versões e extensões instaladas.

O que são os CVE-2026-109618 e CVE-2026-109619?

Os dois CVEs, também chamados em algumas publicações de PHP2Shell, descrevem falhas críticas no mecanismo interno do PHP. Sob condições específicas, uma requisição HTTP manipulada pode levar à exposição de dados, interrupção do serviço ou execução remota de código. A Cloudflare relata que observou tráfego de ataque e publicou regras de WAF; a Sansec ressalta que a exploração depende de condições específicas no servidor e que as provas de conceito públicas não funcionam em uma instalação PHP padrão. Mesmo assim, a correção recomendada é atualizar o runtime PHP.

Um WAF, como o da Cloudflare, pode acrescentar uma camada de proteção. Ele não substitui a atualização dos pacotes no servidor de origem. A própria Cloudflare recomenda corrigir o PHP mesmo quando as regras de WAF estão ativas.

Antes de atualizar: identifique a origem e as versões do PHP

Faça a atualização em uma janela adequada, especialmente em servidores de produção. Tenha um backup recente das configurações e dos dados importantes e, se possível, aplique primeiro a mudança em homologação. A atualização de pacotes pode exigir reinício do PHP-FPM ou do Apache, o que pode causar uma interrupção breve nos sites.

Confirme a versão do sistema e os pacotes PHP instalados:

cat /etc/os-release
apt-cache policy php8.2-cli php8.2-fpm php8.2-common
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*-cli' 'php*-fpm' 'php*-common' 2>/dev/null

Troque 8.2 pela versão que você usa — por exemplo, 8.1, 8.3 ou 8.4. O comando apt-cache policy mostra a versão instalada e as versões oferecidas pelas fontes configuradas. Confirme que a versão candidata vem do repositório esperado.

Para verificar os arquivos de repositório configurados:

grep -RniE 'sury|ondrej/php|packages.sury.org' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

O repositório atual do Sury usa um chaveiro dedicado e uma entrada APT associada à distribuição. Consulte as instruções mantidas pelo próprio repositório antes de adicionar ou alterar fontes. Evite copiar uma linha de repositório de outro servidor: o nome da distribuição, a arquitetura e o tipo de sistema precisam corresponder ao seu ambiente.

Como atualizar os pacotes PHP do Sury

Atualize os índices do APT e confira o que está pendente:

sudo apt update
apt list --upgradable 2>/dev/null | grep -E 'php[0-9.-]'

Se a versão corrigida aparecer e a origem estiver correta, atualize os pacotes. O comando abaixo pode atualizar outros pacotes do sistema além do PHP; revise a lista que o APT apresentar antes de confirmar:

sudo apt upgrade

Se o APT não oferecer uma atualização de PHP, não conclua que o servidor está corrigido. Confira a origem do pacote, o ramo PHP instalado, a arquitetura e a versão candidata:

apt-cache policy php8.2-cli php8.2-fpm php8.2-common
apt list --upgradable 2>/dev/null | grep -E 'php[0-9.-]'

Para os ramos mantidos pelo projeto PHP, os lançamentos de correção são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. O fornecedor pode usar numeração própria ou retroportar o patch sem mudar o número upstream da versão. Para PHP 8.1 ou anterior, não use esses números como único critério: confirme a correção no changelog do pacote ou no aviso do fornecedor responsável pela versão instalada.

Reinicie o PHP-FPM ou o Apache

Depois da atualização, reinicie cada serviço PHP-FPM que atende sites. Liste os serviços disponíveis:

systemctl list-units --type=service --all 'php*-fpm.service'

Reinicie o serviço correspondente à versão atualizada. Por exemplo:

sudo systemctl restart php8.2-fpm
sudo systemctl status php8.2-fpm --no-pager

Se o site usa Apache com mod_php, reinicie o Apache em vez de presumir que um serviço PHP-FPM está em uso:

sudo apache2ctl -M | grep -i php
sudo systemctl restart apache2
sudo systemctl status apache2 --no-pager

Em uma configuração com Nginx e PHP-FPM, normalmente é o serviço PHP-FPM que precisa ser reiniciado para carregar os novos binários. Confirme a configuração real do servidor antes de reiniciar serviços; não pare todas as versões de PHP sem verificar quais sites dependem delas.

Como confirmar que o servidor recebeu a correção

Confira a versão instalada nos pacotes CLI, FPM e comuns. Exemplo para PHP 8.2:

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
  php8.2-cli php8.2-fpm php8.2-common

Compare o resultado com a versão corrigida ou com a versão retroportada publicada pelo fornecedor do pacote. Também verifique o changelog disponível localmente:

zgrep -E 'CVE-2026-(109618|109619)' \
  /usr/share/doc/php8.2-common/changelog.Debian.gz

O caminho e o nome do pacote podem variar conforme o ramo PHP e a distribuição. Se o arquivo não existir, localize o changelog do pacote instalado com dpkg-query -L php8.2-common. Ausência de uma linha no changelog não é prova automática de que o pacote esteja vulnerável: valide a versão e a publicação do repositório correspondente.

Por fim, teste o site e confira se o serviço está ativo. Lembre-se de que php -v verifica o PHP CLI padrão. Um servidor pode ter várias versões instaladas e um site pode usar PHP-FPM ou Apache com outra versão. Confirme o runtime efetivamente associado ao domínio.

Erros comuns ao corrigir o PHP

• Atualizar o CMS e esquecer o runtime: a atualização do WordPress ou de um plugin não corrige o PHP instalado no servidor.
• Conferir somente php -v: o CLI pode apontar para uma versão diferente daquela usada pelo site.
• Misturar repositórios sem planejamento: combinar pacotes da distribuição, do PPA e de packages.sury.org pode alterar dependências e versões candidatas.
• Assumir que todo pacote está corrigido porque o APT terminou sem erro: verifique a versão instalada e a origem do pacote.
• Tratar uma regra de WAF como correção definitiva: ela reduz exposição, mas o runtime do servidor ainda deve ser atualizado.
• Desativar apenas session.upload_progress e encerrar a investigação: essa configuração foi discutida na issue do CloudPanel como mitigação temporária, mas não deve ser apresentada como substituta do patch. As falhas têm mais de um caminho de exploração.

Perguntas frequentes

Atualizar o WordPress corrige esses CVEs?

Não. Os CVEs estão no runtime PHP. Atualize os pacotes PHP usados pelo site e reinicie o serviço correspondente.

O comando php -v confirma que o PHP-FPM foi corrigido?

Não necessariamente. Ele mostra a versão do PHP CLI padrão. Confira também os pacotes FPM e confirme qual versão o domínio utiliza.

PHP 8.1 ou anterior está corrigido?

O projeto PHP publicou correções upstream para os ramos 8.2 a 8.5. Para versões anteriores, verifique se o fornecedor do pacote publicou um backport e confirme essa informação no changelog ou no aviso oficial.

Tenho Cloudflare. Ainda preciso atualizar?

Sim. O WAF acrescenta uma camada de defesa, mas não substitui a atualização do PHP no servidor de origem.

Posso simplesmente desativar o upload progress do PHP?

Trate isso apenas como uma possível mitigação temporária e específica. Não a considere correção completa; atualize o pacote PHP e reinicie o serviço que atende o site.

Conclusão

Para corrigir os CVE-2026-109618 e CVE-2026-109619 em um servidor Debian ou Ubuntu com pacotes Sury, identifique a origem e todos os runtimes instalados, aplique a atualização oferecida pelo repositório correto, reinicie PHP-FPM ou Apache e valide os pacotes efetivamente usados pelos sites. Se a versão estiver fora dos ramos 8.2 a 8.5, confirme o backport com o fornecedor antes de declarar o servidor corrigido.

Fontes: PHP 8.2.35 — anúncio oficial de segurança; instruções do repositório Sury; Cloudflare — proteção WAF para PHP2Shell; Sansec — análise técnica PHP2Shell; issue comunitária do CloudPanel #823.