php2shell: o que é e como corrigir o PHP agora

Em 21 de outubro de 2026 o projeto PHP publicou correções emergenciais para um par de falhas críticas de execução remota de código sem autenticação, rastreadas como CVE-2026-109618 e CVE-2026-109619 e amplamente chamadas de php2shell. O risco não depende de um plugin frágil nem de um tema mal escrito. Ele mora no próprio runtime que processa a requisição HTTP, o que muda a prioridade de resposta para quem opera site, API ou hospedagem.

Se você mantém WordPress, Laravel, Drupal, painel de controle, container com imagem oficial do PHP ou qualquer aplicação atrás de PHP-FPM ou Apache com mod_php, o primeiro passo é inventariar a versão que realmente atende o tráfego e planejar a atualização. Este guia assume o lado de defesa e operação. Explica o que as fontes abertas confirmam, onde elas divergem, como descobrir exposição, como corrigir e o que reduzir enquanto o patch ainda não entra.

O texto não ensina exploração. Serve para decidir o que fazer amanhã no inventário, no pipeline e na janela de manutenção, com riscos e limites ao lado de cada recomendação.

O que é o php2shell e por que importa agora#

O php2shell é o nome informal do conjunto formado por CVE-2026-109618 e CVE-2026-109619, duas vulnerabilidades de segurança de memória no núcleo do PHP que, nas condições certas, permitem a um atacante sem login executar código com os privilégios do worker web. O aviso de segurança no archive do php.net descreve a primeira como corrupção ligada ao tratamento de falta de memória e a segunda como reutilização de estado global envelhecido entre requisições no mesmo worker. A PHP Foundation reforça, no mesmo dia, que ambas tocam gestão de memória e tratamento de erro, caminhos quase inevitáveis em toda requisição.

A nota oficial e os alertas de saúde e de governo que a repetem atribuem CVSS v4.0 9.2 a cada CVE. Circulou, antes do anúncio completo, a ideia de nota 10.0. Trate 9.2 como a referência publicada pelo projeto e pelos órgãos que citam o parecer do CNA, e trate a nota inflada como rumor até haver registro oficial que a sustente.

O impacto prático é amplo porque o ataque mira o interpretador, não a lógica da sua aplicação. Em Apache com mod_php, a equipe do PHP e a Foundation relatam exploração demonstrada em que a requisição dispara o caminho vulnerável antes de qualquer código da aplicação. Em PHP-FPM, o RCE também foi confirmado por caminhos no nível da aplicação. Divulgação de memória sensível do processo também aparece nas descrições técnicas, o que pode expor segredos de outras requisições no mesmo worker.

Sobre exploração real, as fontes não falam a mesma língua. A alerta da CISA de 21 de outubro de 2026 afirma que, na hora da publicação, não havia observação de exploração por parte da agência. Já sensores comerciais e reportagens do mesmo dia descrevem tráfego de ataque e tentativas após vazamento prévio de detalhes. A leitura responsável é esta. Tentativas existem segundo vários sensores. Compromisso bem-sucedido em larga escala não é um fato uniforme e confirmado por todas as autoridades no mesmo instante. O risco operacional, porém, não espera consenso.

Na prática, o que eu vejo com mais frequência é time tratando o caso como bug do CMS, quando o problema está no binário do PHP sob o CMS. Quem demora a separar runtime de aplicação perde a janela em que o patch ainda é barato.

Quem está afetado pelas falhas do PHP#

Está em risco, segundo o aviso oficial, toda instalação de PHP que serve requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é considerado mais alto em mod_php, porque ali existe demonstração de gatilho sem autenticação antes do código da aplicação. Isso cobre boa parte da internet clássica de hospedagem compartilhada e muitos stacks legados.

As versões corrigidas publicadas em 21 de outubro de 2026 são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Linhas anteriores a essas, dentro de cada ramo suportado, entram como afetadas nos advisories GHSA do php-src. O projeto PHP deixa claro que 8.1 e mais antigos não recebem mais updates oficiais da linha principal. Distribuições e fornecedores LTS podem publicar backport. Para quem compila do fonte sem LTS, o time de segurança publicou backports mínimos de fonte para 7.4, 8.0 e 8.1.

Há uma divergência importante sobre o “desde quando”. Relatórios de pesquisadores e da Cloudflare afirmam impacto desde PHP 5.4, ou seja, uma década ou mais de releases. O aviso oficial do php.net, na forma lida nesta sessão, não usa essa frase como confirmação única. Ele foca nas linhas com patch publicado, no status de fim de vida do 8.1 e nos backports. Em texto editorial responsável, diga que Cloudflare e os grupos de pesquisa citados na divulgação afirmam abrangência desde 5.4, e que o que o vendor confirma de forma operacional é a necessidade de atualizar para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou de obter pacote backportado do seu fornecedor.

Também entram no inventário produtos que embutem PHP sem você perceber, painéis, appliances, imagens Docker antigas e ambientes gerenciados. O NCSC da Suíça e a CISA pedem inventário além do site visível. Hospedagem gerenciada pode parecer fora da sua mão, mas a conta ainda é sua até o provedor confirmar o pacote corrigido. Em Linux, o NCSC suíço alerta ainda que major version igual não prova ausência de patch, porque o backport pode manter o número aparente e mudar o conteúdo do pacote.

O erro que mais custa caro aqui é inventariar só o WordPress da vitrine e esquecer o segundo PHP do painel interno, do cron web ou do container de staging exposto. O atacante não respeita o organograma do time.

Como descobrir se o seu PHP está vulnerável#

Você descobre exposição cruzando versão do runtime que atende HTTP, origem do pacote e SAPI em uso. Rodar php -v no shell ajuda, mas não basta se o site usa outro binário via FPM ou módulo do Apache. Confira a versão reportada pela própria aplicação em ambiente controlado, a saída de phpinfo() só em rede administrativa, o pacote da distribuição e a tag da imagem do container.

Ordem prática sugerida.

1. Liste hosts e serviços que respondem conteúdo dinâmico em PHP, públicos e internos.
2. Identifique o SAPI, se mod_php, PHP-FPM, cgi, FrankenPHP ou LiteSpeed, porque a prioridade de patch sobe com mod_php exposto.
3. Anote a versão exata e o pacote. Em Debian e Ubuntu, o número do pacote e o changelog de segurança importam tanto quanto o PHP_VERSION. Em RHEL e clones, o advisory do vendor manda.
4. Em container, leia a imagem em execução e a data do build. Imagem php:8.4 puxada semanas atrás pode ainda estar abaixo de 8.4.27.
5. Em hospedagem gerenciada, peça confirmação escrita da versão corrigida ou do ticket de segurança. Enquanto não houver confirmação, trate como vulnerável.
6. Se estiver em 8.1 ou abaixo sem backport do vendor, considere vulnerável e sem caminho oficial do projeto PHP, salvo o backport mínimo de fonte ou a migração.

Se a versão for menor que 8.5.12 na linha 8.5, menor que 8.4.27 na 8.4, menor que 8.3.36 na 8.3 ou menor que 8.2.35 na 8.2, e não houver evidência de backport, você está na zona de correção imediata. Para 8.1 e anteriores, a pergunta muda de qual patch do php.net para qual pacote do vendor ou qual data de migração.

Muita gente confia só no php -v do SSH e quase sempre está enganada, porque o worker do site pode ser outro arquivo. Confirme o binário do pool FPM ou do módulo Apache antes de marcar o item como resolvido.

Como corrigir, com versões oficiais e backports#

A única remediação completa, nas palavras do próprio projeto PHP e repetida por CISA, NCSC do Reino Unido e CERT europeus, é atualizar o runtime. Alvo oficial em 21 de outubro de 2026.

A ordem de prioridade que a maioria das operações deveria seguir coloca primeiro os serviços internet-facing com mod_php, em seguida os internet-facing com PHP-FPM, depois os sistemas internos com dados sensíveis e, por fim, o restante do inventário. Depois de instalar o pacote, reinicie Apache, PHP-FPM ou o equivalente, e confirme a versão no processo que realmente atende. Container exige rebuild e redeploy da imagem, não só restart da tag antiga. O advisory GHSA da CVE-2026-109618 deixa explícito que só o release com o patch é mitigação completa.

Se você depende de rpms.remirepo.net, o aviso do php.net nesta data pediu migração para pacotes da distribuição ou build a partir do fonte, porque aquele repositório voluntário não teria updates no dia. Quem está em 7.4, 8.0 ou 8.1 sem LTS precisa decidir entre backport mínimo de fonte, pacote do vendor ou salto para linha suportada. Nenhuma dessas opções é grátis em regressão. Teste a aplicação, especialmente extensões nativas e pecl.

A correção do runtime não limpa comprometimento anterior. Se houver indício de shell, download estranho a partir do worker ou alteração de arquivos, abra o playbook de resposta a incidentes e trate como incidente, não como só patch. Um programa de gestão de vulnerabilidades ajuda a não repetir a mesma surpresa na próxima CVE do runtime.

Quem deixa o patch para a sprint que vem costuma descobrir que a regressão do upgrade era menor que o custo de isolar o site no meio do expediente. Agende a janela curta e meça depois.

O que fazer enquanto ainda não dá para atualizar#

Enquanto o patch não entra, reduza superfície e aceite que nenhuma mitigação parcial torna a instalação segura. O NCSC do Reino Unido pediu preparação para atualização imediata e, se a remediação não for viável, consideração de tirar o sistema do ar até mitigar de verdade. A CISA repete a lógica de offline para quem não atualiza e ainda usa 8.1 ou anterior sem correção.

Medidas transitórias descritas pelo aviso do php.net e pelo advisory GHSA para a CVE-2026-109618 incluem forçar memory_limit=-1 de modo administrativo, por exemplo com php_admin_value no pool FPM ou no Apache, de forma que a aplicação não reinsira um limite finito. Também recomendam post_max_size baixo, 8M sem upload ou 32M quando upload for necessário, com upload_max_filesize abaixo desse teto, e limites no proxy para tamanho decodificado, campos, partes multipart e profundidade, inclusive quando não houver Content-Length útil. Limite de cgroup ou container pode servir de fronteira de disponibilidade se matar só o worker afetado. Não use RLIMIT_AS nem RLIMIT_DATA no lugar, porque isso pode provocar a falha de alocação no caminho vulnerável.

Para a CVE-2026-109619, o aviso pede session.upload_progress.enabled=0 em configuração aplicada antes do parse da requisição, com restart de todos os workers, sem depender de ini_set() nem de .user.ini. No PHP 8.5, também fatal_error_backtraces=0 com restart. Remova ajustes inválidos ou depreciados que emitem diagnóstico cedo demais. Esconder erro com display_errors não resolve.

WAF ajuda como camada extra. A Cloudflare relatou proteções WAF implantadas antes da divulgação pública e pediu patch mesmo assim. CISA e o NCSC suíço dizem o mesmo. WAF sozinho não basta. Restringir acesso por VPN ou allowlist, desligar internet em sistemas que não precisam dela e isolar uploads são controles de contenção, não cura.

O custo escondido dessas mitigações é quebra de upload, formulário grande e progresso de sessão. Meça o efeito em staging. Se o negócio não aguenta o efeito colateral e o patch atrasa, a alternativa honesta do NCSC permanece. Tirar do ar o que não pode ser corrigido.

Quem aplica só a regra de WAF e marca o ticket como fechado troca risco técnico por risco de falsa segurança. Use a mitigações para comprar horas, não semanas.

Hardening que reduz o raio de explosão depois do patch#

Depois de atualizar, endureça o entorno para que a próxima falha de worker não vire domínio inteiro comprometido. Isolamento por pool FPM por site, usuário Linux distinto, filesystem de código o mais read-only possível e segredos fora do document root continuam válidos. Limites de corpo no proxy e no PHP reduzem pressão de memória mesmo após o patch. O CERT-EU e a CISA pedem monitoramento de reinícios anormais de worker, picos de multipart e processos filhos inesperados do PHP, inclusive workers que disparam shell ou download.

Observabilidade não substitui patch, mas evita descobrir o incidente só pelo defacement. Encaminhe logs de acesso, erro do FPM e audit do host para a mesma trilha usada na análise de logs em resposta a incidentes. Se suspeitar de acesso prévio, a caça a persistência entra como etapa própria, porque atualizar o PHP não remove webshell já gravada.

Há limite claro. Hardening reduz raio e acelera resposta. Não anula uma CVE crítica no runtime enquanto a versão vulnerável ainda atende a internet.

Na operação do dia a dia, o que separa patch aplicado de ambiente sob controle é conferir o processo vivo e o comportamento depois do restart, não só o pacote no dpkg. Sem essa checagem, o inventário mente com elegância.

Checklist para desenvolvedores#

1. Descubra qual versão de PHP cada ambiente de build, CI, staging e produção realmente usa no SAPI web, não só no CLI.
2. Atualize imagens base, Dockerfile e lock de runtime para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, conforme a linha que o projeto suporta.
3. Rode a suíte de testes e um smoke de upload, sessão e formulário multipart, porque mitigações transitórias e mudanças de limite quebram fluxo legítimo.
4. Remova dependência de session.upload_progress se ainda existir na UX, já que o caminho foi citado nas mitigações da CVE-2026-109619.
5. Trate fatal error e timeout alcançáveis por input do usuário como dívida de segurança, não só de UX, porque o aviso liga estado residual a erros fatais mal limpos.
6. Não publique exploit, PoC funcional nem payload. O papel do time de produto é fechar exposição e documentar a versão corrigida no runbook do serviço.
7. Peça ao time de plataforma confirmação do pacote em hospedagem gerenciada antes de marcar a história como pronta.

Desenvolvedor que só bumpa a imagem local e esquece o worker da produção deixa o risco exatamente onde o atacante olha primeiro. Feche o ciclo com evidência da versão no processo remoto.

Checklist para operações e hospedagem#

1. Inventarie todo PHP que atende HTTP, incluindo appliance, painel, container e SaaS autogerido.
2. Priorize internet-facing e mod_php, depois FPM público, depois o restante.
3. Aplique o pacote do vendor ou o release oficial, reinicie workers e valide a versão no processo ativo.
4. Se não puder patchar na hora, avalie offline conforme NCSC e CISA, aplique mitigações parciais do aviso do php.net e mantenha WAF atualizado sem tratar isso como encerramento.
5. Monitore workers que disparam shell, curl ou download, crashes em série e uploads multipart anômalos.
6. Exija do provedor de hospedagem a versão corrigida por escrito e a data de aplicação.
7. Depois do patch, revise indicadores de comprometimento prévio antes de declarar vitória.

Ops que fecha o chamado no pacote instalado sem validar o binário do pool costuma reabrir o mesmo chamado com outro nome. A evidência é a versão do processo que responde na porta 443.

Perguntas frequentes sobre o php2shell#

O php2shell é uma falha do WordPress ou do PHP?#

É falha do runtime PHP. WordPress, Drupal, Joomla e outros entram porque rodam sobre esse runtime. Aplicação bem escrita não imuniza se a versão do PHP for vulnerável.

Atualizar o CMS resolve sem atualizar o PHP?#

Não. Você precisa da versão corrigida do interpretador ou de um backport equivalente do fornecedor. Atualizar só plugins e core do CMS não fecha CVE-2026-109618 nem CVE-2026-109619.

WAF sozinho me protege?#

Não de forma completa. Cloudflare, CISA e o NCSC suíço tratam WAF como camada temporária. O aviso do PHP afirma que só a atualização é solução completa. Mantenha o WAF ligado e priorize o patch.

PHP 7.4 ou 8.1 tem correção oficial do php.net?#

O projeto não mantém releases oficiais dessas linhas. Há menção a backports mínimos de fonte para 7.4, 8.0 e 8.1, e a possível correção via distribuição LTS. Sem um desses caminhos, a saída é migrar para linha suportada já corrigida.

Como eu sei se minha hospedagem já aplicou o patch?#

Peça a versão exata do PHP no SAPI web e a referência do pacote ou do advisory do provedor. Se a resposta for vaga, trate como não corrigido até haver evidência.

Preciso tirar o site do ar?#

Só se você não puder aplicar o patch em prazo curto e a exposição à internet for inaceitável no seu risco. É exatamente o cenário em que NCSC e CISA pedem considerar offline. Faça a avaliação com dono do serviço e segurança, não no escuro.

Conclusao#

O php2shell, no sentido operacional do dia 21 de outubro de 2026, é um evento de runtime. Quem opera PHP precisa tratar inventário, patch e validação do processo vivo como uma única cadeia. A maioria dos times deveria atualizar agora para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou para o pacote backportado do vendor, começando pelo que está na internet e especialmente por mod_php.

A resposta muda quando você está preso em linha morta sem LTS, quando o fornecedor embute PHP sem transparência ou quando já há indício de comprometimento. Nesses casos a ordem vira contenção, evidência e só então retorno. O primeiro passo concreto é listar cada SAPI e cada versão que atende HTTP hoje e marcar data e responsável pelo patch.

Este conteúdo tem caráter informativo e educativo sobre o php2shell e as CVE-2026-109618 e CVE-2026-109619. Não substitui avaliação do seu fornecedor de hospedagem, da sua equipe de segurança ou de um profissional responsável pelo ambiente em questão.