Quem aplica patch PHP hospedagem compartilhada, VPS ou gerenciada no PHP2Shell

Saber quem aplica patch PHP hospedagem por hospedagem deixou de ser curiosidade técnica na semana de 20 de outubro de 2026, quando o PHP2Shell expôs milhões de servidores a execução remota de código sem login. A correção existe, mas ela só protege o seu site quando alguém instala, reinicia e confere. Neste guia eu mostro quem faz isso em cada modelo, em quanto tempo, e o que cobrar do seu provedor.

TL;DR

• O PHP2Shell são duas falhas críticas (CVE-2026-109618 e CVE-2026-109619, CVSS 4.0 nota 9,2) que permitem executar código no servidor sem autenticação. Correção desde 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• Resumo de quem aplica patch PHP hospedagem a hospedagem: na compartilhada, o provedor aplica o patch e você não tem como acelerar. Na VPS sem gestão, você aplica. Na gerenciada, quem aplica é a equipe contratada, no prazo que estiver no contrato.
• Atualizar o pacote não basta: todos os workers do PHP precisam ser reiniciados. E php -v pode mentir, porque as distribuições corrigem sem trocar o número da versão.
• PHP 7.4 a 8.1 só recebeu backports mínimos de código-fonte. PHP 5.4 a 7.3 não tem correção nenhuma.
• Mitigações de configuração reduzem o risco, mas não resolvem. A única saída completa é atualizar.

O que é o PHP2Shell e por que saber quem aplica patch PHP hospedagem virou urgente

O PHP2Shell é o apelido de duas vulnerabilidades no próprio interpretador do PHP, não em um CMS ou plugin. A CVE-2026-109618 é uma execução remota de código provocada por corrupção de memória quando o PHP estoura o limite de memória (out-of-memory). A CVE-2026-109619 explora um estado global que sobra de uma requisição para a seguinte no mesmo processo, um use-after-free (uso de memória já liberada).

As duas receberam nota 9,2 no CVSS 4.0, a escala padrão de gravidade. O detalhe que mais pesa: segundo a análise da Datadog Security Labs, o ataque acontece antes de qualquer código da aplicação rodar. Senha forte, plugin de segurança e login com dois fatores no WordPress ou no Moodle não bloqueiam nada.

A linha do tempo que encurtou o prazo de todo mundo

• 17/10/2026: a Amazon Threat Intelligence registrou a primeira tentativa de exploração em seus honeypots, quatro dias antes da divulgação, conforme o FAQ da Tenable.
• 20/10: os identificadores das CVEs vazaram, e o PHP publicou um aviso antecipado da release.
• 21/10: saíram as correções e o boletim oficial, antecipados em um dia por causa do vazamento.
• 23/10: o PHP publicou um alerta informativo sobre uma terceira falha, a CVE-2026-115560, com vetor improvável e correção prevista só para a próxima release regular.

A escala também assusta. A Palo Alto Networks contou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis, segundo a TechTarget. Quando o exploit circula antes do patch, a pergunta deixa de ser "se" e vira "quem e quando".

Quais versões estão corrigidas e quais ficaram sem saída

Antes de discutir quem aplica patch PHP hospedagem por hospedagem, vale saber em que lado da linha o seu site está. O quadro abaixo resume o boletim do php.net.

Ramo do PHP	Situação após o PHP2Shell	O que fazer
8.5	Corrigido na 8.5.12	Atualizar e reiniciar workers
8.4	Corrigido na 8.4.27	Atualizar e reiniciar workers
8.3	Corrigido na 8.3.36	Atualizar e reiniciar workers
8.2	Corrigido na 8.2.35 (fim de vida em 31/12/2026)	Atualizar agora e planejar a migração
7.4 a 8.1	Só backports mínimos de código-fonte	Depende de quem empacota; migrar é a saída
5.4 a 7.3	Sem correção	Isolar ou tirar do ar até migrar

O ponto cego é a faixa 7.4 a 8.1. Um backport de código-fonte não é um pacote pronto: alguém precisa compilar, testar e distribuir. Em hospedagem compartilhada, isso depende do fornecedor do painel. Em VPS, depende do repositório que você usa. A CISA chegou a recomendar tirar do ar sistemas PHP que não possam ser corrigidos ou que rodem 8.1 ou anterior.

Quem aplica patch PHP hospedagem compartilhada: o provedor, no ritmo da cadeia dele

Na hospedagem compartilhada, você não tem acesso de root. Não instala pacote, não reinicia o PHP-FPM (o gerenciador de processos do PHP) e não escolhe a hora. A resposta para quem aplica patch PHP hospedagem compartilhada é simples: o provedor. O problema é que o provedor também espera alguém.

A maioria dos servidores compartilhados no Brasil roda cPanel, muitas vezes com CloudLinux. Os pacotes de PHP vêm do EasyApache 4 (as versões ea-php) ou do CloudLinux (as alt-php). O próprio cPanel documenta que o CloudLinux corrige inclusive versões ea-php já fora de suporte. No dia do lançamento, relatos de provedores indicavam builds do EasyApache saindo rápido, enquanto parte dos servidores com CloudLinux ainda aguardava os pacotes do fornecedor.

O que você controla na compartilhada

• A versão selecionada no painel. Se o seu site ainda roda PHP 7.4 por preguiça de testar, você está na faixa mais frágil.
• A pergunta certa ao suporte (lista mais abaixo).
• A decisão de sair. Se o provedor não informa prazo nem versão do pacote, isso já é a resposta.

Quando a compartilhada ainda faz sentido

Site institucional pequeno, sem dado sensível, com provedor que publica status de segurança. Quando o site guarda cadastro de cliente, notas de aluno ou integra pagamento, o fato de você não conseguir verificar nada é o risco. Escrevi sobre esse limite em 5 sinais de que é hora de sair da hospedagem compartilhada.

Quem aplica patch PHP hospedagem VPS: você, e o relógio corre contra

Na VPS sem gestão, o provedor entrega a máquina ligada e a rede funcionando. Do sistema operacional para cima, é com você. Então quem aplica patch PHP hospedagem VPS é quem tem a senha de root, mesmo que essa pessoa seja o estagiário que configurou o servidor em 2022 e saiu da empresa.

Aqui o tempo depende de três coisas: de onde vem o seu PHP, se alguém está olhando e se alguém sabe reiniciar o que precisa.

De onde vem o pacote muda tudo

• Repositório da distribuição (Ubuntu, Debian, RHEL). As distros receberam o patch com antecedência, mas costumam corrigir sem mudar o número da versão. O php -v continua mostrando 8.3.6 no Ubuntu 24.04, por exemplo, e o que muda é a revisão do pacote.
• Repositórios de terceiros (PPA do Ondřej Surý, Remi). Muito usados para ter PHP mais novo, mas o pacote corrigido sai quando o mantenedor publica. O unattended-upgrades do Ubuntu, por padrão, não cobre esses repositórios.
• Imagem Docker ou PHP compilado à mão. Não há atualização automática. É rebuild da imagem e novo deploy.

Um caso que ilustra bem: a Laravel Forge, plataforma popular para provisionar VPS, avisou clientes que as atualizações automáticas de segurança dela não aplicam PHP. Painel de provisionamento não é gestão.

A armadilha do reinício

O código antigo continua na memória até o processo morrer. A Datadog é explícita: depois de atualizar, reinicie ou substitua todos os workers que ainda rodam o runtime antigo. Isso vale para PHP-FPM, Apache com mod_php, LiteSpeed e FrankenPHP. Segundo o PHP, mod_php é o cenário de maior risco, porque o exploit demonstrado roda antes de qualquer código da aplicação.

Quem aplica patch PHP hospedagem gerenciada: a equipe contratada, no prazo do contrato

Na gerenciada, alguém foi pago para cuidar do sistema operacional, do runtime e da resposta a incidentes. Então quem aplica patch PHP hospedagem gerenciada é a equipe do provedor. A diferença real para a compartilhada é que você pode perguntar, receber evidência e cobrar prazo.

Mas "gerenciada" é uma palavra elástica. Há provedores que chamam de gerenciada uma VPS com painel e backup. Comparei as duas coisas em detalhe em hospedagem gerenciada vs VPS: quem cuida do quê. Na prática, o que separa uma da outra é o contrato dizer, por escrito, quem atualiza runtime e em quanto tempo.

O que uma gerenciada séria entrega numa semana como a do PHP2Shell

1. Inventário em horas: quais servidores, quais versões, qual SAPI (FPM, mod_php), qual origem do pacote.
2. Mitigação imediata onde o pacote ainda não saiu, avisando que é paliativo.
3. Patch em staging e produção, com reinício de todos os workers.
4. Verificação pela versão do pacote, não pelo php -v.
5. Caça a sinais de invasão nos dias anteriores ao patch, já que houve tentativa desde 17/10.
6. Relatório ao cliente com o que foi feito, quando, e o que ficou pendente.

O prazo de resposta deve estar amarrado ao SLA. Se o contrato só fala de uptime, ele não cobre segurança. Explico como ler essa cláusula em SLA de hospedagem: uptime e janela de manutenção.

Comparativo: quem aplica patch PHP hospedagem em cada modelo

O quadro abaixo junta tudo. A coluna de tempo não traz número fixo porque nenhum provedor sério promete horas sem conhecer o seu ambiente. O que muda é de quem depende o relógio.

Critério	Compartilhada	VPS sem gestão	Gerenciada
Quem instala o patch	Provedor	Você	Equipe contratada
De quem depende o prazo	Provedor + fornecedor do painel (cPanel, CloudLinux)	Você + repositório (distro, PPA, Remi)	Contrato e SLA
Reinício dos workers	Provedor	Você	Equipe contratada
Você consegue verificar?	Quase nunca	Sim, se souber onde olhar	Sim, com relatório
PHP 7.4–8.1	Depende de pacote do fornecedor	Você compila ou migra	Plano de migração conduzido
Caça a sinais de invasão	Raramente informada	Por sua conta	Incluída, se o contrato prevê
Custo escondido	Ficar sem informação	Hora técnica de madrugada	Mensalidade maior

A leitura honesta: VPS é mais barata até a semana em que aparece um PHP2Shell. Aí o custo vira a hora de quem sabe fazer, no horário que o ataque escolheu.

Mitigações: o que fazer enquanto o patch não chega (e por que não bastam)

O próprio boletim do PHP lista medidas temporárias. Elas compram tempo, mas o PHP é claro: atualizar é a única correção completa.

• Contra a CVE-2026-109618: memory_limit=-1, definido de forma que a aplicação não consiga sobrescrever, junto com post_max_size baixo e limite de tamanho de requisição no proxy. Há um custo: sem limite de memória, um script mal escrito pode derrubar o servidor.
• Contra a CVE-2026-109619: session.upload_progress.enabled=0 no php.ini ou no pool do FPM. No PHP 8.5, também fatal_error_backtraces=0.
• Depois de qualquer mudança: reiniciar todos os workers. Sem isso, a configuração nova não vale.
• WAF: a Cloudflare publicou regras para vetores conhecidos, mas elas só protegem o tráfego que passa por ela.

Quando NÃO confiar na mitigação

Não trate mitigação como solução se o servidor roda PHP 7.3 ou anterior, se não há como impedir que a aplicação altere memory_limit, ou se ninguém consegue confirmar que os workers foram reiniciados. O limite de memória do container ajuda na disponibilidade, mas o PHP diz que não é mitigação completa. Nesses casos, a orientação da CERT-EU é isolar a aplicação até corrigir.

O que perguntar ao seu provedor hoje

Mande estas perguntas por escrito. Elas resolvem a dúvida de quem aplica patch PHP hospedagem por hospedagem em uma troca de e-mails. A qualidade da resposta diz mais sobre o seu provedor do que qualquer página de vendas.

1. Meu servidor já está com a versão corrigida? Peça a versão do pacote, não só o php -v.
2. Quando foi aplicado e quando os workers foram reiniciados?
3. Qual SAPI meu site usa? PHP-FPM, mod_php ou LiteSpeed. Se for mod_php, pergunte o plano de migração.
4. Para PHP 7.4 a 8.1, de onde vem o pacote corrigido? CloudLinux, EasyApache, compilação própria?
5. Vocês verificaram sinais de exploração entre 17/10 e a data do patch? Logs de erro de memória na inicialização da requisição, segfaults de workers, shell disparado pelo processo do PHP.
6. Como vão tratar a CVE-2026-115560? A resposta esperada: session.upload_progress.enabled=0 até a próxima release regular, salvo se a aplicação depender do recurso.
7. Qual o prazo contratual para patch crítico? Se não houver, essa é a resposta mais importante.

Como a Agathas Web resolve isso

A hospedagem gerenciada da Agathas Web foi desenhada para que a pergunta "quem aplica o patch" tenha nome, prazo e relatório. Trabalho com PHP há mais de 15 anos, em Moodle, WordPress e Laravel, e também com sistemas que recebem webhooks da API oficial do WhatsApp, onde servidor parado é atendimento parado. Esse histórico define o que entra no serviço.

O que está incluso

• Atualização de sistema operacional e runtime (PHP, Node, Python) e banco, em janela combinada e com staging antes da produção.
• Monitoramento 24/7 com alertas no WhatsApp da equipe técnica.
• WAF da Cloudflare, fail2ban e hardening do sistema operacional.
• Backup diário criptografado, com restauração testada mensalmente.
• Plano de resposta a incidentes documentado, com ações preventivas após o evento.
• WhatsApp dedicado, com resposta em até 15 minutos para incidentes críticos, e SLA contratual com multa.

Como funciona numa semana de vulnerabilidade crítica

Na nossa operação, quem aplica patch PHP hospedagem gerenciada é a mesma equipe sênior que monitora o ambiente e atende o WhatsApp, sem terceirização. Quando sai um boletim como o do PHP2Shell, o roteiro é o da seção anterior: inventário de versões e SAPI, mitigação onde o pacote ainda não saiu, patch validado em staging, reinício de todos os workers, verificação pela versão do pacote, análise de logs do período de exposição e relatório para você. Para quem ainda está em PHP 7.4 a 8.1, o plano de migração entra junto, porque backport mínimo não é lugar para morar.

Como contratar

Você solicita o orçamento na página da hospedagem gerenciada ou pelo WhatsApp. Fazemos um diagnóstico do ambiente atual (versão do PHP, SAPI, origem dos pacotes, plugins), propomos a configuração e migramos com staging, janela de baixo tráfego e o ambiente antigo preservado por 30 dias para rollback.

Conclusão: escolha o modelo pelo pior dia, não pelo preço do mês

A semana do PHP2Shell mostrou que a diferença entre os modelos não aparece no dia a dia. Ela aparece no dia em que um exploit circula antes do patch. Na compartilhada, você espera. Na VPS, você corre. Na gerenciada, você pergunta e recebe resposta com evidência.

Se hoje você não sabe dizer quem aplica patch PHP hospedagem onde o seu site roda, faça as sete perguntas acima ainda esta semana. E se a resposta for silêncio, conheça a hospedagem gerenciada da Agathas Web e peça um diagnóstico do seu ambiente.