Em resumo: Em servidores com CloudLinux, os sites correm frequentemente não com o PHP padrão, mas com o alt-php, pacotes próprios por versão do PHP que os clientes escolhem através do PHP Selector. Contra o PHP2Shell, o operador do servidor tem de atualizar individualmente cada versão alt-php instalada e reiniciar todos os processos PHP. Como cliente de alojamento, esclareça que versão a sua conta usa e peça confirmação escrita do estado do patch dessa versão.
Porque é que o CloudLinux é uma questão própria no PHP2Shell
Muitos fornecedores de alojamento partilhado usam o CloudLinux, um sistema operativo Linux que separa milhares de contas de clientes num servidor. Para os operadores de sites, isso é geralmente invisível. Só se torna visível quando surge uma vulnerabilidade no próprio interpretador PHP, como no PHP2Shell com CVE-2026-109618 e CVE-2026-109619.
A razão: nestes servidores há muitas vezes várias fontes de PHP lado a lado. Além do PHP do sistema operativo e, no cPanel, dos pacotes ea-php, existem os pacotes alt-php do CloudLinux. Cada fonte tem o seu próprio estado de pacote. O facto de uma estar com patch não diz nada sobre as outras.
Para agências e empresas com várias contas no mesmo fornecedor acresce um segundo ponto: cada site pode usar uma versão diferente, porque alguém a alterou há anos na área de cliente. Uma única pergunta sobre “o PHP” do fornecedor fica por isso curta. Faz sentido uma lista de todos os domínios com a respetiva versão escolhida.
O que são o alt-php e o PHP Selector
Segundo a documentação do CloudLinux, o PHP Selector disponibiliza versões alternativas do PHP, os pacotes alt-php. Estão em /opt/alt/phpXX/, por exemplo /opt/alt/php83/ para o PHP 8.3, cada um com o seu próprio php.ini. A documentação lista versões da 5.1 à 8.5, consoante a versão do CloudLinux do servidor.
Os clientes escolhem eles mesmos a versão, no cPanel geralmente através de “Select PHP Version”. Tecnicamente isto pressupõe o CageFS, uma espécie de sistema de ficheiros isolado por conta. Segundo a documentação, o Selector funciona com suPHP, mod_fcgid, CGI e LiteSpeed; o Apache com mod_php não é suportado pelo CageFS.
| Termo | Significado para si |
|---|---|
| CloudLinux | Sistema operativo do fornecedor de alojamento, separa as contas dos clientes |
| CageFS | sistema de ficheiros próprio e isolado por conta |
| alt-php | pacotes PHP do CloudLinux, um por versão |
| PHP Selector | escolha da versão alt-php e de opções individuais na área de cliente |
CloudLinux alt-php e PHP2Shell: o que está comprovado e o que fica em aberto
Está comprovado: as versões do PHP corrigidas são a 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 do projeto PHP, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4.
Nas fontes de que dispomos, fica em aberto para que versões alt-php o CloudLinux já entrega pacotes com patch. Justamente nos ramos antigos como o 5.6 ou o 7.4, que o Selector continua a oferecer, conta por isso apenas a declaração do fornecedor. Os backports podem estar aplicados sem que o número de versão apresentado mude.
Uma particularidade diz respeito aos servidores cPanel com suporte comercial de longo prazo: segundo a documentação do cPanel, a TuxCare, uma marca do CloudLinux, entrega pacotes com patch para versões do PHP já descontinuadas como alt-php. Quem aí foi passado de ea-php74 para alt-php74 depende deste caminho. Mais sobre isto no artigo Suporte de longo prazo para versões antigas do PHP.
Estas perguntas deve fazê-las agora ao seu fornecedor
Como cliente, não pode aplicar patches ao alt-php por si mesmo. Mas pode fazer as perguntas certas e documentar as respostas. Um modelo pronto para isso está no guia Perguntar ao fornecedor de alojamento pelo estado do patch.
- A minha conta corre com alt-php, ea-php ou com o PHP do sistema operativo, e com que versão exatamente?
- Este pacote concreto tem patch contra CVE-2026-109618 e CVE-2026-109619, e desde quando?
- Todos os processos PHP foram reiniciados depois, também os processos lsphp e php-cgi?
- Os valores provisórios do php.net estão definidos centralmente, em especial
session.upload_progress.enabled=0? - Que versões alt-php deixam de receber patches e até quando tenho de mudar?
Verifique em paralelo que versão a sua conta usa realmente. Se tiver acesso SSH, o php -v mostra a versão da linha de comandos, que pode divergir da do site. Mais fiável é a indicação no PHP Selector para o domínio em causa.
Se o fornecedor responder que a versão que escolheu já não recebe patches, a mudança para um ramo suportado é o caminho limpo. Verifique antes, nos requisitos de sistema do seu CMS ou loja, que versões do PHP o fabricante autoriza, e teste a mudança, se possível, numa cópia do site. Mudar no Selector é rápido, um erro na loja numa segunda-feira de manhã não é.
Opções do PHP no Selector: cuidado com os valores provisórios
O PHP Selector permite aos clientes alterar eles mesmos valores individuais do php.ini, entre eles frequentemente o memory_limit. Segundo a documentação, os valores libertados são definidos pelo operador, no ficheiro /etc/cl.selector/php.conf. Os valores globais para todas as versões alt-php estão em /etc/cl.selector/global_php.ini.
Isto é importante para o PHP2Shell. O php.net recomenda como medida provisória definir memory_limit=-1 de modo que as aplicações não possam ultrapassar o valor, e não definir session.upload_progress.enabled=0 através de ini_set() nem de .user.ini. Um valor que cada conta pode alterar livremente não cumpre esta condição. Os antecedentes estão em Medidas imediatas sem patch.
Para os operadores de servidores resulta daqui uma lista de verificação curta. Os comandos só leem:
# Que versões do PHP oferece o Selector, qual é a padrão?
selectorctl --summary
# Pacotes alt-php instalados e o seu estado
rpm -qa 'alt-php*' | sort
# Os números CVE constam do changelog de um pacote? (nome do pacote como exemplo)
rpm -q --changelog alt-php83 | grep -E "CVE-2026-10961[89]"
# Processos PHP em execução com hora de arranque, para comprovar o reinício
ps -eo pid,lstart,cmd | grep -E '[l]sphp|[p]hp-cgi|[p]hp-fpm'
Segundo a documentação do CloudLinux, atualiza-se com yum groupupdate alt-php. Depois todos os processos PHP têm de reiniciar, caso contrário o código antigo continua em execução na memória. Os valores provisórios que não podem ser ultrapassados pertencem à configuração global e não à lista das opções dos clientes. Como o ea-php e o alt-php se relacionam em servidores cPanel está descrito em cPanel e WHM: proteger o PHP.
Um patch não remove software malicioso que tenha sido introduzido antes. Se a sua conta correu entre 17 e 21 de outubro com uma versão vulnerável, vale a pena olhar para novos ficheiros PHP e para os registos de acesso a partir de 20 de outubro.
Como ajuda concretamente a PHP SOS?
- Esclarecer o estado: apuramos com que fonte de PHP e versão corre cada um dos seus sites e formulamos o pedido ao fornecedor de alojamento.
- Avaliar a resposta: verificamos na confirmação do fornecedor eventuais lacunas, como falta de indicações sobre o reinício ou sobre ramos alt-php antigos.
- Acompanhar a mudança: se um site corre numa versão sem patch, planeamos a migração e testamo-la antecipadamente.
- Para operadores: através do serviço de patch PHP, atualizamos pacotes alt-php, ea-php e do sistema, reiniciamos todos os processos e documentamos o estado.
Perguntas frequentes
Como reconheço que o meu fornecedor de alojamento usa CloudLinux e alt-php?
Um sinal típico é a função “Select PHP Version” na área de cliente do cPanel, através da qual você mesmo pode alternar entre muitas versões do PHP. Só tem certeza quando o fornecedor o confirmar.
Posso atualizar o alt-php na minha conta?
Não. Os pacotes alt-php estão centralmente no servidor e são mantidos pelo operador. Só pode escolher entre as versões instaladas e deve pedir confirmação do estado do patch da versão escolhida.
Uma versão alt-php antiga como a 7.4 está protegida contra o PHP2Shell?
Sem uma declaração do fornecedor, não é possível dizer. Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4, e o projeto PHP não fornece atualizações oficiais para a 8.1 e anteriores. Se há um backport aplicado, o fornecedor de alojamento tem de o confirmar por escrito para a sua versão exata.
Posso alterar o memory_limit no PHP Selector eu mesmo?
Tecnicamente muitas vezes sim, se o operador tiver libertado a definição. O php.net recomenda, porém, como medida provisória, definir o memory_limit de modo que as aplicações não possam ultrapassar o valor. Altere por isso esses valores apenas em articulação com o fornecedor de alojamento.