cPanel, Plesk e Servidores Linux: Mitigar o PHP2Shell e Blindar Portas

O setor global de alojamento web enfrenta um estado de emergência sem precedentes após a divulgação pública do PHP2Shell (CVE-2026-109618 e CVE-2026-109619), um par de falhas críticas de execução remota de código (RCE) sem autenticação e com gravidade CVSS 9.2 no núcleo do PHP. Para blindares o teu servidor hoje, tens de forçar atualizações por linha de comandos no teu painel de gestão (cPanel, Plesk, CyberPanel, DirectAdmin ou HestiaCP), purgar os processos antigos da memória RAM e trancar as portas de administração (2083, 8443, 8090, 2222, 8083) atrás de regras estritas em nftables ou de uma VPN WireGuard.

(Atualização Recente, 23 de Outubro de 2026: A equipa do PHP identificou o vetor CVE-2026-115560 em session.upload_progress; se geres servidores de alojamento partilhado ou painéis de controlo, desativa esta diretiva imediatamente conforme documentado no nosso guia dedicado).

Nos painéis de controlo de alojamento web (cPanel, Plesk, CyberPanel, DirectAdmin ou HestiaCP), dezenas de sites e aplicações partilham frequentemente o mesmo servidor físico. Quando surge uma vulnerabilidade crítica no núcleo do PHP como o PHP2Shell, o risco multiplica-se em duas frentes:

1. Movimentação Lateral Entre Sites: Se um único site no servidor for invadido através do PHP2Shell, o invasor ganha execução de comandos no sistema operativo e pode aceder aos ficheiros, bases de dados e credenciais de todos os outros sites alojados na mesma máquina.
2. Exposição de Portas Administrativas: Manter as consolas de gestão (2083, 8443, 8090, 8083) acessíveis à internet pública atrai botnets automatizadas e agentes de IA que tentam explorar credenciais roubadas ou falhas de software 24 horas por dia.

Se acompanhaste as últimas 24 horas nos canais técnicos da indústria, desde os Fóruns Oficiais do cPanel e o Plesk Talk até à Comunidade CyberPanel, ao Fórum DirectAdmin e ao Fórum Comunitário do HestiaCP, viste o alarme generalizado instalado após o alerta conjunto internacional e o comunicado oficial da Hetzner.

Este manual complementa diretamente a política de isolamento perimetral do nosso Alerta CISA, NSA e FBI: Blindagem PHP, Node e Portas Expostas.

No Webxtek Studio, onde operamos infraestruturas críticas para empresas de cibersegurança e pen-test e plataformas de SaaS empresarial B2B, não dependemos de interfaces gráficas em situações de emergência. Abaixo tens os comandos de terminal exatos para isolares e atualizares o teu painel.

1. Da Sala de Máquinas ao Kernel: Anatomia do PHP2Shell e a Cegueira das WAFs

Para mitigar a vulnerabilidade crítica PHP2Shell (CVE-2026-109618 e CVE-2026-109619) em servidores cPanel, Plesk, CyberPanel, DirectAdmin ou HestiaCP, tens de atualizar imediatamente os pacotes do PHP via terminal para as versões 8.2.35+, 8.3.36+ ou 8.4.27+, reiniciar os processos PHP-FPM em memória RAM e bloquear as portas administrativas públicas (2083, 8443, 8090, 2222 e 8083) com regras estritas de nftables.

Para perceberes porque é que este ataque contorna todas as defesas tradicionais do teu site, tens de observar o caminho que um pedido percorre desde o cabo de rede até ao motor do PHP. Quando um utilizador submete um formulário ou um ficheiro para o teu servidor, o servidor web frontal (Apache, Nginx ou OpenLiteSpeed) recebe o fluxo HTTP e entrega-o ao processo trabalhador do PHP através da camada de abstração SAPI (Server Application Programming Interface), geralmente recorrendo ao protocolo binário FastCGI (php-fpm) ou LSAPI (lsphp).

Antes de o teu WordPress, Laravel ou Magento executar a primeira linha de código PHP, o motor interno escrito em linguagem C (o Zend Engine) tem de desmontar o pacote multipart/form-data para separar os campos de texto e os ficheiros enviados, guardando-os em tabelas de dispersão (hash tables) na memória RAM. É precisamente neste estágio embrionário que o PHP2Shell (CVE-2026-109618 e CVE-2026-109619) ataca:

Fluxo de Corrupcao de Memoria no PHP2Shell (FastCGI / SAPI):
1. O atacante envia um POST multipart/form-data com fronteiras (boundaries) profundamente aninhadas.
2. O parser nativo em C (rfc1867.c) aloca blocos sucessivos no gestor de memoria do motor Zend (ZendMM).
3. O payload e calibrado ao byte para esgotar o limite memory_limit exatamente a meio da reatribuicao de um ponteiro.
4. O motor Zend dispara uma condicao critica de falta de memoria (OOM) e invoca a funcao C longjmp() via zend_bailout().
5. O salto abrupto do longjmp() ignora a rotina de limpeza da estrutura global SG(rfc1867_uploaded_files).
6. O processo trabalhador do PHP-FPM nao morre: volta ao ciclo FCGI_Accept() com ponteiros pendentes (Dangling Pointers).
7. No pedido HTTP imediatamente seguinte, o atacante reutiliza a memoria libertada (Use-After-Free) e ganha execucao de shell.

No meu dia a dia em produção, esta mecânica explica dois fenómenos que estão a apanhar milhares de administradores desprevenidos:

1. A Persistência do Processo Trabalhador em RAM: Num ambiente PHP-FPM ou LiteSpeed LSAPI, cada processo filho (worker) atende centenas ou milhares de pedidos consecutivos (pm.max_requests) antes de ser reciclado para poupar CPU. Como a função longjmp() em C interrompe apenas o pedido atual sem destruir o processo Linux subjacente, a memória corrompida permanece ativa na RAM à espera do segundo pacote do atacante para abrir uma consola remota como o utilizador do pool web.
2. A Falácia da Proteção por WAF (Cloudflare ou ModSecurity): Muitos clientes perguntam-me porque é que uma firewall aplicacional na borda ou o conjunto de regras OWASP CRS v4 no ModSecurity não bloqueiam o PHP2Shell. A razão é simples: uma WAF procura assinaturas de código malicioso (como SQL Injection ou XSS), mas o pacote inicial que dispara o longjmp() no PHP2Shell não precisa de conter código executável evidente. Os atacantes utilizam três técnicas de evasão ao nível do protocolo HTTP:
   • Fragmentação via Transfer-Encoding: chunked: Dividem o corpo da requisição em milhares de fragmentos minúsculos que esgotam o buffer de inspeção da WAF (que por performance apenas analisa os primeiros megabytes), mas que o Nginx ou Apache reconstrói integralmente antes de entregar ao socket do PHP-FPM.
   • Ofuscação de Cabeçalhos MIME: Inserem quebras de linha anómalas e parâmetros duplicados nos cabeçalhos Content-Disposition que as expressões regulares da WAF ignoram, mas que o parser em C do PHP processa até atingir o esgotamento de memória.
   • Compressão Assíncrona (Content-Encoding: gzip/deflate): Enviam payloads altamente comprimidos que aparentam ser inofensivos no trânsito perimetral e só se expandem dentro da memória do servidor de destino.

A conclusão arquitetural é inegociável: regras de WAF servem para filtrar ruído oportunista, mas a única defesa real contra corrupção de memória em C é atualizar o binário compilado no disco e matar todos os processos antigos que continuam a correr em memória RAM.

2. Relatório das Trincheiras: O Que Está a Falhar em Cada Painel de Gestão

Durante as últimas 24 horas, acompanhei ao minuto os relatórios de engenharia nos canais oficiais de cada plataforma. O maior erro que podes cometer hoje é confiar cegamente no botão de “Atualizar” da interface web do teu painel. Eis a realidade operacional em cada ecossistema:

A. cPanel & WHM (EasyApache 4)

Operado pelo grupo WebPros, o cPanel & WHM sustenta a esmagadora maioria do alojamento empresarial e partilhado. Nos Fóruns Oficiais do cPanel, os engenheiros de infraestrutura reportaram dois gargalos graves em servidores com elevada densidade de contas:

[!WARNING] Relato de Operações nos Fóruns do cPanel:
“As filas de atualização do EasyApache 4 através da interface gráfica do WHM estão a sofrer timeouts em servidores sob carga. Embora os pacotes ea-php82 e ea-php83 já tenham correções disponíveis nos espelhos oficiais, milhares de contas de clientes continuam amarradas a perfis antigos (ea-php74 e ea-php80). Além disso, deixar as portas 2082/2083 e 2086/2087 abertas a toda a internet está a atrair varreduras massivas de botnets que combinam ataques aos serviços cpsrvd com payloads PHP2Shell.”

No terreno, a minha regra para cPanel é clara: ignora o browser quando o sistema está sob pressão. Entra por SSH como root, limpa a cache do gestor de pacotes (dnf ou yum), força a atualização dos pacotes ea-php* e obriga o supervisor do cPanel a reiniciar todos os daemons FPM e o Apache.

B. Plesk Obsidian

Igualmente pertencente à WebPros, o Plesk é muito utilizado por agências digitais e equipas corporativas na Europa. No fórum oficial Plesk Talk, a discussão técnica expôs uma armadilha silenciosa no sistema de micro-atualizações:

[!WARNING] Alerta Técnico da Comunidade Plesk Talk:
“A atualização automática do Plesk substitui os ficheiros binários /opt/plesk/php/*/sbin/php-fpm no disco rígido, mas em múltiplos cenários não força o reinício imediato dos processos trabalhadores que já estão instanciados para cada domínio individual. Se não releres os handlers e não reiniciares explicitamente os serviços plesk-php*-fpm, o teu servidor mostra a versão nova na consola mas continua a servir pedidos HTTP através do binário antigo e vulnerável que permanece carregado na memória RAM.”

Além dos pools dos clientes, lembra-te de que o próprio painel do Plesk corre sobre um motor interno chamado sw-engine (na porta 8443), que também precisa de ser reiniciado após a aplicação dos patches.

C. CyberPanel e OpenLiteSpeed (lsphp)

O CyberPanel ganhou tração em ambientes WordPress pela velocidade do servidor web OpenLiteSpeed. Na Comunidade CyberPanel, o foco de alerta recai sobre o comportamento dos processos destacados (Detached PHP Processes):

[!WARNING] Aviso de Segurança na Comunidade CyberPanel:
“O OpenLiteSpeed utiliza o binário lsphp através do protocolo LSAPI em modo destacado. Mesmo quando atualizas os pacotes lsphp82 ou lsphp83 via apt ou dnf, e mesmo que reinicies o serviço lsws, os processos lsphp antigos continuam vivos em background para não interromper ligações ativas. Tens obrigatoriamente de executar killall -9 lsphp ou criar o ficheiro .lsphp_restart.txt para forçar a limpeza da memória, além de bloqueares imediatamente o acesso público à porta administrativa 8090.”

D. DirectAdmin e CloudPanel

Para as equipas que administram servidores em DirectAdmin ou CloudPanel:

• DirectAdmin: No Fórum DirectAdmin, a arquitetura de compilação via CustomBuild 2.0 provou ser rápida, mas exige intervenção direta para recompilar os binários e reescrever os ficheiros de configuração dos sockets FPM, mantendo a porta 2222 fechada ao exterior.
• CloudPanel: Por assentar numa base Debian/Ubuntu com Nginx e pacotes nativos PHP-FPM, a atualização via apt é direta, mas exige que feches de imediato a porta 8443 da consola de gestão, que nunca deve ficar exposta fora de uma rede privada.

E. HestiaCP e Repositórios Sury (Debian/Ubuntu)

No Fórum Comunitário do HestiaCP, muitos sysadmins em Debian 12 e Ubuntu 24.04 depararam-se com atrasos na sincronização dos espelhos CDN do repositório packages.sury.org (mantido por Ondřej Surý):

[!WARNING] Nota Operacional no Fórum HestiaCP:
“Vários administradores correram apt update && apt upgrade horas após o anúncio do CVE, mas os espelhos locais ainda entregavam a versão 8.3.35 em cache. Nunca confies que o comando apt upgrade terminou sem verificares o output exato de php -v e sem confirmares que o serviço hestia-php e a porta 8083 estão isolados da internet aberta.”

3. Runbook de Produção: Comandos Exatos de Atualização e Purga de RAM

Abre o teu terminal SSH com privilégios de root e executa o bloco correspondente à tua infraestrutura. Incluí no final um comando de auditoria forense ao /proc do Linux para garantires que nenhum binário antigo ficou esquecido em memória.

1. Servidores cPanel & WHM (RHEL / AlmaLinux / CloudLinux)

# 1. Limpar caches de metadados do DNF/YUM para garantir que puxas os pacotes mais recentes
dnf clean all

# 2. Atualizar todos os pacotes PHP do EasyApache 4 (incluindo ramos 8.2, 8.3, 8.4 e 8.5)
dnf update 'ea-php*' -y

# 3. Se utilizas CloudLinux com Alt-PHP (CageFS), atualizar também os binários alt-php
dnf update 'alt-php*' -y 2>/dev/null || true
cagefsctl --force-update 2>/dev/null || true

# 4. Reiniciar obrigatoriamente o daemon mestre do PHP-FPM do Apache e o motor interno do cPanel
/scripts/restartsrv_apache_php_fpm --hard
/scripts/restartsrv_httpd
/scripts/restartsrv_cpsrvd

# 5. Confirmar a versão compilada em cada binário instalado
for bin in /opt/cpanel/ea-php*/root/usr/bin/php; do
    echo "=== $bin ==="
    $bin -v | head -n 1
done

2. Servidores Plesk Obsidian (Ubuntu / Debian / AlmaLinux)

# 1. Executar o instalador do Plesk para aplicar todos os micro-updates de segurança
plesk installer update

# 2. Atualizar os pacotes do sistema operativo onde residem os handlers PHP do Plesk
apt-get update && apt-get install --only-upgrade 'plesk-php*' -y 2>/dev/null || dnf update 'plesk-php*' -y

# 3. Forçar o Plesk a reler as versões dos binários registados
plesk bin php_handler --reread

# 4. Reiniciar todas as instâncias PHP-FPM de clientes e o motor interno do painel (sw-engine)
systemctl restart 'plesk-php*-fpm'
plesk bin service --restart sw-engine
plesk bin service --restart sw-cp-server

# 5. Auditar as versões registadas no painel
plesk bin php_handler --list | awk '{print $1, $2, $4}'

3. Servidores CyberPanel e OpenLiteSpeed (lsphp)

# 1. Atualizar os pacotes LiteSpeed PHP nos repositórios oficiais LiteSpeed
apt-get update && apt-get install --only-upgrade 'lsphp82*' 'lsphp83*' 'lsphp84*' -y 2>/dev/null || \
dnf upgrade 'lsphp82*' 'lsphp83*' 'lsphp84*' -y

# 2. Sinalizar ao OpenLiteSpeed para reciclar todos os processos PHP destacados
touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt

# 3. Matar imediatamente todos os processos trabalhadores lsphp antigos em memória RAM
killall -9 lsphp 2>/dev/null || true

# 4. Reiniciar o servidor web OpenLiteSpeed e o serviço do CyberPanel (lscpd)
systemctl restart lsws
systemctl restart lscpd

# 5. Validar a versão do binário lsphp em execução
/usr/local/lsws/lsphp83/bin/php -v | head -n 1

4. Servidores DirectAdmin (CustomBuild 2.0)

# 1. Entrar no diretório do CustomBuild e sincronizar espelhos de código-fonte
cd /usr/local/directadmin/custombuild
./build update

# 2. Recompilar todas as versões configuradas de PHP e reiniciar pools PHP-FPM
./build php n
./build rewrite_confs

# 3. Reiniciar o serviço central do DirectAdmin
systemctl restart directadmin

5. Servidores HestiaCP, CloudPanel ou Debian/Ubuntu Bare-Metal (Repositório Sury)

# 1. Forçar atualização das listas ignorando caches de proxy locais
apt-get -o Acquire::http::No-Cache=True -o Acquire::https::No-Cache=True update

# 2. Atualizar todos os pacotes PHP-FPM, CLI e módulos comuns
apt-get install --only-upgrade 'php8.2*' 'php8.3*' 'php8.4*' 'php8.5*' -y

# 3. Reiniciar todos os daemons PHP-FPM ativos e o motor interno do HestiaCP (se aplicável)
systemctl restart 'php*-fpm'
systemctl restart hestia 2>/dev/null || true

# 4. Verificar se ainda existem processos na RAM ligados a ficheiros binários apagados (antigos)
lsof -nP +L1 | grep -E 'php-fpm|lsphp' || echo "[OK] Zero processos PHP antigos retidos na memoria RAM."

Repara naquele último comando (lsof -nP +L1). No Linux, quando um ficheiro binário em disco é substituído durante um apt upgrade ou dnf update, os processos que já estavam em execução mantêm um descritor de ficheiro aberto para o inode antigo (que aparece marcado como deleted na tabela do kernel). Se aquele comando devolver alguma linha, significa que ainda tens trabalhadores vulneráveis ao PHP2Shell vivos na memória RAM: mata esses PIDs imediatamente com kill -9.

Se geres ambientes HestiaCP em produção e precisas de dar acesso a developers ou clientes sem risco de fuga de diretoria, aplica em paralelo as diretivas do nosso guia de HestiaCP: Isolamento SSH com Jailkit e SFTP Seguro. E se queres eliminar a sobrecarga de conexões TCP locais entre a tua stack web e a cache, consulta o playbook de Redis 8: Sockets Unix, ACLs e Tuning de Memória.

4. Isolamento Perimetral: Fechar Portas Administrativas e Socket 9000 com nftables

Há uma verdade dura que repito em todas as auditorias de segurança que conduzimos no Webxtek Studio: uma consola de administração de servidores nunca deve estar acessível ao público geral na internet.

Deixar a porta 2083 ou 2087 (cPanel/WHM), a porta 8443 (Plesk e CloudPanel), a porta 8090 (CyberPanel), a porta 2222 (DirectAdmin) ou a porta 8083 (HestiaCP) aberta a qualquer endereço IP do mundo multiplica o teu risco por dois motivos:

1. Os daemons que servem estes painéis correm com privilégios elevados ou interagem diretamente com wrappers suid de root; qualquer vulnerabilidade zero-day no próprio painel compromete o servidor inteiro.
2. Os scanners de botnets utilizam a impressão digital (fingerprinting) dos certificados TLS e cabeçalhos dessas portas para catalogar exatamente que versão do sistema operativo e do painel estás a usar em menos de meio segundo.

Aplica esta configuração de nftables para garantir que as portas de gestão do teu servidor respondem exclusivamente aos endereços IP fixos da tua equipa ou à sub-rede da tua VPN WireGuard, bloqueando também qualquer exposição acidental da porta 9000 do FastCGI:

#!/usr/sbin/nft -f
# Ficheiro: /etc/nftables.d/webxtek-panel-hardening.nft
# Blindagem de Portas de Gestão de Hosting e Isolamento FastCGI

table inet webxtek_perimeter {
    # Lista de IPs de administração autorizados (Escritório / VPN WireGuard)
    set admin_trusted_ips {
        type ipv4_addr
        flags interval
        elements = { 198.51.100.42/32, 203.0.113.0/24, 10.66.66.0/24 }
    }

    # Portas administrativas dos principais painéis (cPanel, Plesk, CyberPanel, DirectAdmin, HestiaCP)
    set hosting_panel_ports {
        type inet_service
        elements = { 2082, 2083, 2086, 2087, 2095, 2096, 8443, 8090, 2222, 8083 }
    }

    chain input_hardening {
        type filter hook input priority -10; policy accept;

        # 1. Permitir sempre tráfego interno na interface de loopback (127.0.0.1 / ::1)
        iifname "lo" accept

        # 2. Bloquear de imediato qualquer tentativa externa de falar com o PHP-FPM via TCP (Porta 9000-9099)
        tcp dport 9000-9099 log prefix "[NFT_FASTCGI_BLOCK]: " counter drop

        # 3. Autorizar acesso às portas dos painéis apenas para os nossos IPs de confiança
        tcp dport @hosting_panel_ports ip saddr @admin_trusted_ips ct state new,established accept

        # 4. Registar e descartar qualquer acesso público às portas dos painéis (IPv4 e IPv6)
        tcp dport @hosting_panel_ports log prefix "[NFT_PANEL_DROP]: " counter drop
    }
}

Carrega a tabela no kernel e verifica os contadores de pacotes bloqueados em tempo real:

# Carregar as regras de blindagem sem interromper ligações ativas
sudo nft -f /etc/nftables.d/webxtek-panel-hardening.nft

# Inspecionar quantos pacotes maliciosos já foram intercetados pela regra
sudo nft list table inet webxtek_perimeter

5. Isolamento Multi-Tenant e Mitigação de Emergência no php.ini

Se geres um servidor onde coexistem vários projetos ou clientes (arquitetura multi-tenant), atualizar o PHP é apenas metade do trabalho. Tens de garantir que cada domínio corre num pool de PHP-FPM estritamente isolado com o seu próprio utilizador Linux de sistema, usando sockets UNIX com permissões 0660, para que um site comprometido nunca consiga ler o ficheiro wp-config.php ou .env do vizinho do lado.

Caso tenhas uma aplicação empresarial antiga que dependa de uma versão de PHP legada (como PHP 7.4 ou 8.0) enquanto a equipa prepara a atualização ou o patch do fornecedor, aplica de imediato estas restrições no ficheiro php.ini ou na configuração do pool FPM (php_admin_value) para reduzir a superfície de exploração do parser multipart e bloquear funções de execução de comandos no sistema operativo:

; Ficheiro: /etc/php/8.3/fpm/conf.d/99-webxtek-emergency-hardening.ini

; 1. Restringir limites do parser multipart (RFC 1867) para travar payloads profundos
max_input_vars = 1000
max_input_nesting_level = 32
max_file_uploads = 10
post_max_size = 16M
upload_max_filesize = 12M

; 2. Desativar exposição da versão do PHP nos cabeçalhos HTTP (X-Powered-By)
expose_php = Off

; 3. Bloquear funções nativas usadas pelo PHP2Shell para instanciar shells interativas
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,pcntl_exec,pcntl_fork

; 4. Confinar cada pool exclusivamente ao diretório da respetiva aplicação
; (Definir individualmente no ficheiro .conf de cada pool FPM)
; php_admin_value[open_basedir] = /var/www/cliente_x/htdocs:/var/www/cliente_x/tmp

6. Matriz Comparativa de Operação e Blindagem por Painel de Controlo

Usa esta tabela de referência rápida para orientares a tua equipa de operações durante a janela de manutenção de emergência:

7. Checklist Final de Validação em Memória e Perímetro

Não feches o terminal SSH sem confirmares estes cinco pontos críticos no teu servidor:

1. Zero Binários Antigos em Memória RAM: Corre lsof -nP +L1 | grep -E 'php|lsphp' e confirma que nenhum trabalhador web continua a executar o ficheiro antigo eliminado do disco.
2. Versão Exata Confirmada na Consola: Executa php -v em cada versão instalada no servidor e valida que o número de compilação é igual ou superior a 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.
3. Portas de Painel Invisíveis ao Público: Testa o IP do teu servidor a partir de uma rede externa (como o 5G do teu telemóvel, fora da VPN) e confirma que as portas 2083, 2087, 8443, 8090, 2222 e 8083 não respondem (timeout por drop no nftables).
4. Porta TCP 9000 Desativada: Verifica com ss -tulpn | grep :9000 que todos os pools PHP-FPM comunicam exclusivamente por sockets UNIX locais com permissões 0660.
5. Auditoria de Criação de Ficheiros Suspeitos: Executa find /var/www /home -type f -name "*.php" -mtime -2 para detetares qualquer web shell (.php) que possa ter sido gravada no disco nas últimas 48 horas antes da aplicação da correção.

Manter servidores rápidos, estáveis e imunes a vagas de exploração global exige engenharia disciplinada e monitorização contínua ao nível do sistema operativo. No Webxtek Studio, construímos e gerimos ambientes preparados para resistir aos cenários mais adversos. Através das nossas soluções de alojamento gerido de alta segurança, consultoria técnica de infraestrutura e engenharia de websites de alta performance, garantimos que a operação digital da tua empresa permanece rápida, blindada e sempre disponível.