Em resumo: uma atualização PHP no cPanel após o PHP2Shell abrange três passos: levar todos os pacotes ea-php e, se for o caso, alt-php para um nível corrigido, reiniciar por completo o PHP-FPM e o Apache e documentar o nível dos pacotes. Os clientes do servidor não podem definir sozinhos os principais valores provisórios; tem de ser o administrador do WHM a fazê-lo.
Ponto de partida nos servidores cPanel
O PHP2Shell engloba as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 no próprio PHP. Ambas permitem a execução de código malicioso sem autenticação e têm a pontuação CVSS v4.0 9.2. Estão afetados o PHP-FPM, o Apache com mod_php, o php-cgi, o FrankenPHP e o LiteSpeed. O projeto PHP publicou a 21/10/2026 as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
O cPanel não traz o PHP como um único pacote, mas através do EasyApache 4, com um conjunto de pacotes por versão, por exemplo ea-php83 ou ea-php84. A isto juntam-se, em alguns servidores, os pacotes do sistema operativo e, no CloudLinux, as versões alt-php. Cada origem tem o seu próprio nível. Só obtém um quadro completo quando verifica as três.
Atualização PHP no cPanel: verificar inventário e atribuição
Comece por um levantamento do que existe. Os comandos seguintes só leem e não alteram nada. Caminhos e nomes de pacotes são exemplos e podem variar consoante a instalação.
# Versões PHP instaladas segundo a API do WHM
whmapi1 php_get_installed_versions
# Versão de cada instalação ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Nível dos pacotes (sistemas baseados em RPM, exemplo)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
No MultiPHP Manager vê que domínio usa que versão e se o PHP-FPM está ativado. Registe as versões que estão instaladas mas não atribuídas a nenhum domínio. Também essas têm de ser atualizadas ou removidas.
Interpretar corretamente os backports
Tal como com outros fornecedores, o número de versão mostrado não é o único critério. Se uma correção for entregue como backport, o número pode permanecer igual. Verifique por isso também o registo de alterações do pacote e as indicações do fornecedor.
# Pesquisar números CVE no registo de alterações de um pacote (exemplo)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Se não aparecer nenhuma entrada, isso não significa automaticamente que a correção falta. Significa, porém, que precisa de uma confirmação escrita antes de classificar o servidor como com patch. Como ler corretamente as versões está descrito em Verificar a versão PHP e o nível de patch.
Atualização, reinício e controlo
A atualização instala-a no WHM através da atualização do sistema ou pela gestão de pacotes. Depois, reinicie todos os processos PHP. Ficheiros novos, por si só, não bastam enquanto houver processos antigos a correr em memória.
# Reiniciar os serviços PHP-FPM de todas as versões (script do cPanel)
/scripts/restartsrv_apache_php_fpm
# Reiniciar o Apache por completo
/scripts/restartsrv_httpd
# Verificar a hora de arranque dos processos PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Cada processo PHP deve ter uma hora de arranque posterior à atualização. Se não for assim, termine-o de forma dirigida através do serviço correspondente. Com vários servidores, compensa um pequeno registo por máquina, que poderá usar mais tarde como comprovativo.
Uma atualização do CMS através de ferramentas do cPanel como o WP Toolkit não fecha a vulnerabilidade do PHP. Faz sentido, mas não substitui nem a atualização do PHP nem o reinício.
Definir valores provisórios de forma centralizada
Se uma versão ainda não estiver corrigida, o php.net recomenda medidas provisórias, que não oferecem proteção completa. No cPanel, defina-as no MultiPHP INI Editor, no modo de administrador, ou diretamente no php.ini da respetiva versão ea-php. Valores no .user.ini das contas de clientes não bastam para session.upload_progress.enabled.
; php.ini de todo o servidor para a versão afetada (exemplo)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Sem função de upload, o php.net indica post_max_size = 8M. No PHP 8.5 acresce fatal_error_backtraces=0. Depois, reinicie de novo todos os workers. Defina um limite de memória através de cgroups, por exemplo com os limites do CloudLinux, e não através de RLIMIT_AS ou RLIMIT_DATA. Mais pormenores em Medidas imediatas sem patch.
Responsabilidade entre o operador do servidor e os titulares das contas
Num servidor cPanel com muitas contas, o administrador do WHM é responsável pelo PHP, pelos serviços e pela configuração de todo o servidor. Os titulares de cada conta são responsáveis pelas suas aplicações, plugins e credenciais de acesso. Informe os titulares das contas sobre quando e como foi aplicado o patch e recomende-lhes que verifiquem as suas aplicações quanto a anomalias. Como a situação se apresenta do ponto de vista do cliente descreve-o Alojamento partilhado.
Guarde os registos a partir de 20/10/2026. Um patch não remove software malicioso introduzido antes.
Para o comprovativo basta um registo simples por servidor: data e hora da atualização, lista dos pacotes ea-php e alt-php com a versão antes e depois, a lista de processos com as horas de arranque após o reinício e, se for o caso, a confirmação do fornecedor dos pacotes sobre backports. Guarde o registo fora do servidor. Mais tarde serve de prova perante clientes, seguradoras ou auditores e facilita a próxima atualização de emergência, porque os passos já estão descritos. Se operar vários servidores cPanel, compensa reunir os comandos de leitura desta página num pequeno script que corra da mesma forma em todas as máquinas e recolha os resultados. Assim reconhece de relance diferenças entre servidores, por exemplo uma versão PHP esquecida.
Como ajuda concretamente a PHP SOS?
- Inventariamos pacotes ea-php, alt-php e do sistema e associamos todas as contas à sua versão PHP.
- Através do nosso serviço de patches PHP, atualizamos, reiniciamos todos os serviços e comprovamos o nível com listas de pacotes e horas de processos.
- Quando necessário, definimos valores provisórios em todo o servidor e de forma a não poderem ser sobrescritos.
- Verificamos as contas quanto a vestígios típicos de comprometimento e, em caso de achado, iniciamos a remoção de malware.
- Em seguida, reduzimos o número de versões PHP e reforçamos a configuração.
Perguntas frequentes
Onde vejo no WHM que domínio usa que versão PHP?
No MultiPHP Manager do WHM vê, para cada domínio, a versão atribuída e se o PHP-FPM está ativo. Para uma lista completa convém consultar também pela linha de comandos. Anote igualmente as versões que não estão atribuídas a nenhum domínio.
Um cliente do cPanel pode definir ele próprio os valores provisórios em .user.ini?
Para session.upload_progress.enabled, o php.net afirma expressamente que .user.ini e ini_set() não bastam. O valor tem de ficar no php.ini, no pool FPM ou na configuração do servidor. Isso só o administrador do servidor pode fazer.
Basta um reinício graceful do Apache?
No caso do PHP-FPM, são os próprios serviços FPM que têm de reiniciar; um reload do Apache não os renova. Com handlers PHP baseados no Apache, um reinício completo é o caminho seguro. Verifique depois a hora de arranque de todos os processos PHP.
E o CloudLinux e o alt-php?
Em servidores CloudLinux, os sites correm por vezes com pacotes alt-php próprios em vez de ea-php. Estes têm o seu próprio nível de pacotes e têm de ser verificados e atualizados em separado.