Fontes verificadas em 22 de outubro de 2026. Apúblico: operadores de aplicativos PHP, equipes de segurança e engenheiros que mantêm compilações PHP personalizadas.

Este artigo resume a causa, o escopo do impacto, o processo formal de reparo, as medidas de mitigação temporárias e a implementação do patch oficial da vulnerabilidade PHP2Shell. O texto principal é citado usando números como S1; todos os links de fontes estão listados no apêndice no final do texto. O fragmento de configuração é um modelo de implantação que precisa ser ajustado com base na versão real, na capacidade de negócios e no relacionamento de herança de configuração.

TL;DR: Etapas e sugestões de reparo

  1. Atualize o tempo de execução PHP: atualize a ramificação relevante para pelo menos 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Para pacotes de distribuição, use a versão completa do pacote que o fornecedor confirma que corrige ambos os CVEs. S1S10
  2. Substitua todos os processos antigos: reinicie ou substitua cada PHP worker, serviço de hospedagem e contêiner após a atualização e confirme se as instâncias antigas foram encerradas.
  3. Verifique por meio do caminho de solicitação Web real: verifique o Web SAPI, a versão completa do pacote e a instância em execução. A verificação de php -v por si só não estabelece que o serviço ativo está corrigido.
  4. Execute verificações de regressão de negócios e restaure orçamentos normais de recursos: teste de login, tratamento de sessão, uploads, importações e tratamento de erros. Se o limite de memória PHP foi removido temporariamente, restaure um orçamento finito apropriado após a aplicação do patch.
  5. Se uma atualização imediata for impossível: restrinja o tráfego não confiável antes que ele atinja PHP. Avalie a desativação do progresso do upload e os backtraces fatais PHP 8.5 conforme descrito na Seção 5. As mitigações de configuração e as regras WAF têm cobertura limitada e não podem substituir uma atualização. S1S2S3

1. Visão geral da vulnerabilidade e julgamento de risco

PHP2Shell neste artigo refere-se a duas vulnerabilidades de nível Critical divulgadas oficialmente por PHP em 21 de outubro de 2026. Ambas estão relacionadas à memória e solicitam gerenciamento do ciclo de vida do mecanismo PHP, representando o risco de execução remota de código não autenticado. S1S2S3

ProjetoCVE-2026-109618CVE-2026-109619
nome oficialRCE via OOM corruptionRCE via stale global state
questões centraisMemória insuficiente causa um salto anormal, deixando um estado que ainda não concluiu a inicialização.O estado global restante no trabalhador aponta para a memória de solicitação liberada.
Tempo típico de ocorrênciaO processo de inicialização, execução ou limpeza da solicitação atualA solicitação anterior sai do status e as solicitações subsequentes o consomem antecipadamente.
OOM é uma condição necessária?Pertence ao principal mecanismo de desencadeamento da vulnerabilidadeNão; outros erros fatais e limpeza pós-diagnóstico também podem estar envolvidos
Direção fundamental de reparoLidar com segurança com falhas de alocação e rescisões de solicitaçõesCorrija a propriedade do estado, o tempo de limpeza e a inicialização antecipada
Requisitos de descartedeve ser reparadodeve ser reparado ao mesmo tempo

Base: Dois boletins de segurança oficiais e envios de correções. S2S3S4

1.1 Noções básicas sobre implantações afetadas

PHP considera oficialmente todas as implantações PHP que lidam com solicitações Web em risco, incluindo PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O ataque mod_php demonstrado pode ocorrer antes da execução do código do aplicativo, portanto, as verificações de login, o middleware da estrutura e a validação de upload do aplicativo não podem cobrir esse caminho. S1

É necessário distinguir entre “a implantação precisa ser corrigida” e “uma certa cadeia de ataque foi completamente comprovada”. Anúncio de CVE-2026-109618: FPM sairá do processo filho após a falha na inicialização da solicitação, bloqueando o caminho de limpeza correspondente de mod_php após a falha na inicialização; entretanto, o caminho OOM após a inicialização bem-sucedida ainda está em risco. O anúncio também observa que a exploração completa do FPM para este CVE ainda não foi demonstrada. Esta restrição não pode ser usada para deduzir que FPM é seguro, especialmente CVE-2026-109619 não pode ser ignorado. S2S3

Os limites imediatos de permissão para uma exploração bem-sucedida dependem da identidade do processo que hospeda PHP e dos recursos aos quais ele tem acesso. Geralmente, deve-se prestar atenção ao código do site, ao diretório de upload, às credenciais do banco de dados, aos tokens de serviço e aos recursos de acesso à rede interna; “execução remota de código” não significa obter permissões de root naturalmente. O julgamento das consequências aqui é baseado no modelo de permissão do processo, e o impacto real precisa ser avaliado em conjunto com as permissões de implantação.

Os scripts CLI comuns e únicos não possuem a mesma entrada HTTP; mas os processos que lidam com tarefas externas por um longo período em CLI ou no modo incorporado ainda devem ser incluídos no inventário de tempo de execução e de ciclo de vida. Somente as dependências CMS, de estrutura ou Composer são atualizadas e o mecanismo PHP subjacente não é substituído automaticamente.

2. Análise de causa

2.1 Primeiro entenda os dois ciclos de vida

PHP worker geralmente lida com várias solicitações em sucessão. A memória alocada durante a solicitação pode ser liberada uniformemente no final da solicitação, enquanto o próprio trabalhador e alguns de seus campos globais continuam a existir.

Portanto, o motor deve manter duas restrições:

  • Restrição de inicialização: Os dados visíveis para outros códigos devem estar em um estado que possa ser lido, percorrido e destruído com segurança.
  • Restrição do ciclo de vida: depois que a memória da solicitação for liberada, os campos de vida mais longa não deverão continuar tratando os endereços nessa memória como estado válido.

Estas duas restrições correspondem aos principais modos de falha dos dois grupos de vulnerabilidades. O processo a seguir é uma descrição do mecanismo que combina anúncios e compilação de patches. Isso não significa que toda implantação tenha exatamente o mesmo caminho acessível. S2S3S5

2.2 CVE-2026-109618: OOM interrompeu uma atualização de status inacabada

A implementação antiga usa um salto não local do tipo longjmp() para manipular OOM, e o caminho associado sai do contexto de execução atual por meio de zend_bailout(). O perigo é que uma parte do código C possa ter publicado um novo objeto, matriz ou status de solicitação para outro código, mas ainda não tenha concluído toda a inicialização do campo; neste momento, qualquer falha de alocação no momento relevante poderá fazer com que as etapas normais de fechamento sejam ignoradas. S2

O processo de falha pode ser dividido em quatro etapas:

  1. Crie ou atualize a estrutura interna da solicitação e torne-a acessível.
  2. A alocação de memória subsequente falha e OOM é acionado.
  3. O fluxo de execução se afasta da função atual e o código originalmente usado para concluir a inicialização ou restaurar o estado não é executado.
  4. A limpeza de solicitação continua processando essas estruturas e trata conteúdos inválidos como campos ou endereços válidos.

O problema não é que a falta de memória sempre cause RCE. Em vez disso, o esgotamento da memória altera o fluxo de controle e viola as suposições do mecanismo sobre estruturas válidas. A alocação falhada não precisa envolver diretamente a estrutura que eventualmente será lida incorretamente. S2

Por que solicitações menores também podem ficar sem memória

O número de bytes no corpo da solicitação e o uso do heap após a análise não são a mesma coisa. O campo A pode corresponder a múltiplas strings, elementos de array e objetos de metadados dentro de PHP; a complexidade estrutural de entrada afetará o grau de amplificação da memória.

Os problemas com multipart listados no anúncio oficial incluem: lacuna na verificação do tamanho inicial quando falta o comprimento da declaração disponível, o número de cabeçalhos para uma única parte não é suficientemente limitado e controles de arquivo vazios ainda produzem metadados, com nomes aninhados aumentando ainda mais a carga de trabalho do array. O desenrolamento, decodificação ou reatribuição de entrada do próprio aplicativo também pode ser uma fonte de OOM. S2

Duas conclusões protetoras podem ser tiradas disso:

  • As restrições do corpo da solicitação devem ser implementadas tanto quanto possível antes de inserir PHP, e o comprimento real da leitura e a complexidade estrutural devem ser considerados.
  • Limitar individualmente o tamanho do arquivo, o número de arquivos ou fechar apenas um portal de upload não pode abranger todas as fontes OOM.

Por que a autenticação de aplicativos pode ser tarde demais

Em mod_php, o corpo da solicitação pode ser analisado automaticamente durante a fase de inicialização da solicitação; mesmo que a inicialização falhe, a limpeza da solicitação relacionada ainda será executada. Os caminhos de ataque confirmados podem, portanto, ocorrer antes do código do aplicativo. Para reduzir a exposição neste estágio, as restrições precisam ser colocadas no proxy reverso, no servidor Web ou em outro limite que precede o processamento da solicitação PHP. S1S2

2.3 CVE-2026-109619: A memória da solicitação foi liberada, a referência global ainda está ativa

Esse problema envolve status de erro, sessão, objeto ou extensão: o campo é armazenado em um local de acesso de longo prazo do trabalhador, mas os dados referenciados pelo campo pertencem a uma única solicitação. Contanto que a referência não seja devidamente limpa antes que o heap de solicitação seja liberado, as solicitações subsequentes poderão encontrar um estado pendente, formando uso após liberação. S3

A análise oficial divide as condições de exploração em “produtores” e “consumidores”:

função ou condiçãosignificadoImplicações para proteção
produtor estadualColoque o estado pertencente a esta solicitação em um local que ainda possa ser acessado posteriormentePara verificar se a limpeza correspondente foi concluída após uma saída anormal
O status permaneceNão foi liberado ou foi liberado e reabastecido em uma operação tardia.Apenas limpar uma vez no estágio anterior de desligamento pode não ser suficiente
reutilização do trabalhadorO mesmo trabalhador continua a processar solicitações subsequentesVários trabalhadores são apenas uma diferença de agendamento, não uma garantia de segurança de memória
consumidor avançadoLeia, libere ou determine o valor residual antes que o estado correspondente seja inicializado normalmente.Deve verificar INI, sessão e outros caminhos antes da inicialização

Estas condições devem ser satisfeitas em combinação; qualquer log de erros por si só não prova que a vulnerabilidade foi explorada com êxito. S3

Não requer OOM como pré-requisito necessário

Erros fatais podem interromper a publicação e a restauração do estado emparelhado. Falhas de compilação ou análise, erros não detectados, falhas de require e tempos limite de execução podem deixar estados específicos para trás. Os diagnósticos não fatais no final da limpeza também podem preencher novamente as informações de erro que já foram apagadas. S3

Portanto, alterar memory_limit para ilimitado não cobre esse conjunto de vulnerabilidades.

”Antes da inicialização” precisa ser tratado separadamente

O momento dos dois tipos de consumidores confirmados é diferente:

  • EDiagnóstico inicial do INI: Algumas configurações aplicadas na solicitação emitem aviso, aviso ou descontinuação antes da inicialização normal do executor e o processamento de diagnóstico pode acessar o estado de erro antigo.
  • progresso de upload da sessão: a sessão pode ser processada antecipadamente durante o processo de análise do corpo da solicitação, mas o módulo regular RINIT ainda não foi concluído; não se pode inferir que o caminho não existe porque o aplicativo não chama session_start() explicitamente. S3

Nem todas as configurações INI têm o mesmo tempo de risco. A configuração em nível de diretório de mod_php e PHP_VALUE / PHP_ADMIN_VALUE transmitida pelo front-end FPM precisa ser diferenciada da configuração de inicialização comum php.ini, FPM pool e FPM .user.ini. Os últimos têm tempos de configuração diferentes e não podem ser chamados coletivamente de mesmos consumidores iniciais. S3

Desligar display_errors, log_errors, reduzir error_reporting ou usar @ afeta apenas a visibilidade do diagnóstico; o estado interno relevante pode ter sido acessado antes de decidir se o log será gerado. S3

3. Versão de reparo e seleção de patch

3.1 Linha de base oficial da correção upstream

Filial PHP atualA primeira versão a incluir esta correção oficialSugestões
8.28.2.35Atualize para esta versão ou uma versão subsequente contendo as mesmas correções
8.38.3.36Igual ao acima
8.48.4.27Igual ao acima
8.58.5.12Igual ao acima
8.1 e versões anterioresO suporte geral upstream terminouPriorizar a migração para filiais apoiadas; liberação de verificação de curto prazo ou backport do fabricante LTS

A versão e o status de suporte são baseados no anúncio oficial de PHP, e a linha de base é 22 de outubro de 2026. S1

Estes são limites de correção específicos da filial. Elas não podem ser substituídas por uma declaração de que todas as versões abaixo de 8.5.12 são vulneráveis: versões como 8.2.35 e 8.4.27 em outras filiais já contêm as correções.

3.2 Verifique a versão completa do pacote de distribuição

As distros geralmente adicionam correções de segurança com base em versões upstream mais antigas. A aceitação também deve verificar a versão de lançamento, fonte do repositório, versão completa do pacote e boletim de segurança.

Por exemplo, a versão do pacote de correção Ubuntu 24.04 LTS listada para Ubuntu USN-8948-1 é:

8.3.6-0ubuntu0.24.04.13

Sua parte upstream ainda é 8.3.6, mas a versão completa do pacote dessa distribuição está incluída neste anúncio de correção. Esta conclusão se aplica apenas à distribuição e fonte do pacote correspondente e não pode ser generalizada para qualquer compilação que também exiba 8.3.6. S10

3.3 Escolhendo o patch certo

cenaPlano prioritárioPontos-chave para aceitação
Usando o pacote de distribuição PHPInstale atualizações de segurança lançadas pelo fabricanteO anúncio abrange CVE; a versão completa do pacote está correta
Use o contêiner PHP oficial ou a imagem autoconstruídaAtualizar o tempo de execução base, reconstruir e implantarA instância em execução usa a nova imagem; todas as cópias antigas foram encerradas
Ramos suportados autocompiladosUse a versão de segurança oficial deste branch ou o conjunto completo de patches oficiaisCorrespondência de ramificações, conclusão de dependências, compatibilidade de extensões e passagem de regressão
Sujeito a 7.4, 8.0, 8.1Priorize o backport do fornecedor; avalie a ramificação oficial do código-fonte de emergência, se necessárioIdentifique mudanças comportamentais e agende a migração para versões suportadas

Patches oficiais foram lançados e as correções reais devem começar a partir desses patches. Os trechos de código na Seção 6 destinam-se a ilustrar os destaques do design e da revisão e não constituem um patch completo que possa ser aplicado de forma independente. S1S4S6

4. Processo formal de reparo

4.1 Inventário do tempo de execução que realmente trata as solicitações

Recomenda-se formar um breve livro razão para registrar pelo menos:

  • Nome de domínio ou serviço de entrada, back-end de proxy reverso, PHP SAPI.
  • Ramificação PHP, versão completa do pacote ou resumo da imagem, fonte de compilação.
  • FPM pool, unidade de serviço real, contêiner ou Pod, número de réplicas.
  • Extensões, configuração principal e arquivos de configuração adicionais foram carregados.
  • Existem outras versões do PHP, cópias de implantação antigas ou portais de origem que podem ser acessados diretamente?

Estas são sugestões de implementação para que “atualizado” possa corresponder a cada entrada de tráfego real. Verifique especialmente se as linhas de comando PHP e Web PHP usam versões diferentes, se a imagem foi construída, mas o contêiner antigo ainda está em execução, parte do pool ou a cópia não foi substituída, etc.

4.2 Selecione e implante a atualização correta

Confirme a versão da correção conforme a Seção 3, de preferência usando uma fonte de pacote confiável existente ou uma cadeia de construção controlada. O escopo da atualização deve incluir o componente que realmente hospeda a solicitação, como o pacote FPM, o módulo Apache PHP, o binário CGI ou a construção de serviço na qual PHP está integrado.

Antes de atualizar, mantenha a configuração e a lista de pacotes e verifique a inicialização e os principais serviços em um ambiente semelhante ao de produção. Para extensões automantidas, verifique a compatibilidade de construção e execução correspondente à versão PHP. Apenas escolher um commit aparentemente relevante de outro branch não garante que todo o conjunto de correções foi implementado.

4.3 Reiniciar ou substituir instâncias em execução

Instalar um arquivo e carregar um novo código em um processo são duas coisas diferentes. O serviço correspondente deve ser reiniciado ou a substituição contínua deve ser concluída e o trabalhador antigo e o contêiner antigo devem ser confirmados como tendo saído.

Para mod_php, reinicie o processo Apache que hospeda o módulo. Os serviços que incorporam PHP precisam ter seu processo de hospedagem substituído. Para FPM, limpar OPcache não substitui a atualização do tempo de execução e a desativação de trabalhadores antigos.

Ao usar a comutação graciosa, você precisa verificar se o processo da geração antiga ainda está lidando com conexões longas ou solicitações pendentes. O registro de aceitação deve incluir o serviço real, a versão de implantação, o tempo de conclusão da alteração e os resultados de saída da instância antiga.

4.4 Verifique por meio de solicitações Web reais

Recomenda-se combinar as seguintes evidências em vez de depender apenas de um único comando de versão:

evidênciaO que pode ser provadoNão posso provar nada sozinho
Gerenciador de pacotes ou metadados de imagemFontes de instalação e compilações completasO tráfego foi transferido para esta instância
Status do processo e implantaçãotrabalhador ou contêiner conclui a substituiçãoA entrada externa deve ser direcionada para ele
Resultados de diagnóstico restritos acessados via portal realWeb SAPI real e configuração em execuçãoSe o backport de lançamento cobre dois CVE
Anúncio do fornecedor ou registro completo do patchEsta correção de bug está incluída nesta compilaçãoTodas as réplicas são implantadas

PHP_VERSION, PHP_SAPI, arquivos de configuração carregados e configurações de emergência podem ser verificados por meio de recursos de diagnóstico internos existentes ou portais de diagnóstico temporários e com acesso controlado. Certifique-se de que a solicitação não seja retornada diretamente por CDN ou pelo cache de páginas; remova a entrada de diagnóstico temporária quando concluída.

php -v geralmente indica apenas o binário CLI atualmente selecionado pelo shell; comandos como php-fpm -i não são equivalentes à verificação do trabalhador existente que está recebendo tráfego. Não exponha a página phpinfo() completa à rede pública por muito tempo.

4.5 Verificações de regressão de negócios e remoção de configurações de emergência

Verifique o login normal, leitura e gravação de sessão, formulário e upload, importação, tratamento de erros e estabilidade do trabalhador em torno das funções afetadas por esta mudança. Verifique se a taxa de erro, o atraso de resposta, o pico de memória, a saída do processo e a frequência de reconstrução estão anormais.

Se memory_limit=-1 for definido temporariamente, o orçamento limitado correspondente à capacidade comercial será restaurado após a entrada em vigor do patch oficial; se pm.max_requests=1 estiver definido, a configuração do ciclo de vida avaliada pela capacidade será restaurada após a confirmação do reparo. Os limites de tamanho de entrada e os controles de acesso à fonte podem ser mantidos conforme as necessidades do negócio.

Se surgirem problemas de compatibilidade durante a atualização, deverá ser dada prioridade à suspensão do portal afetado, à restrição do seu acesso externo ou ao ajuste da aplicação antes da reversão. Permitir diretamente que o tempo de execução não reparado atenda novamente à rede pública reabrirá o risco original.

5. Medidas de mitigação quando a atualização imediata não for possível

Esta seção destina-se à redução da exposição a curto prazo ou à melhoria da disponibilidade. Cada medida cobre apenas um caminho específico e uma combinação de múltiplas medidas não equivale a uma reparação completa. S1S2S3

5.1 Priorizar controles de tráfego antes de PHP

Se o serviço permitir, restrinja temporariamente os terminais confidenciais a fontes confiáveis ou imponha o controle de acesso antes de PHP. Para cargas de trabalho de upload, limite o tamanho do corpo da solicitação, contagens de campos, contagens de peças, cabeçalhos por parte e profundidade de aninhamento. Os serviços que não precisam de multipartes podem rejeitá-lo no frontend. S2

Essas restrições devem cobrir todas as entradas em PHP. Somente interceptar o URL chamado “upload” irá perder outras entradas que ainda são analisadas automaticamente por PHP no corpo da solicitação. Para casos como transferências fragmentadas, falta de comprimento declarado disponível, etc., o limite deve ser baseado no tamanho real da leitura; o aplicativo também deve ter seu próprio orçamento de tamanho de saída ao descompactar ou expandir o conteúdo novamente.

Modelo de configuração 5.2 FPM pool

Coloque as seguintes configurações na seção de configuração FPM pool que realmente atende solicitações, não literalmente em php.ini. Os valores 8M e 4M são exemplos para ajustar a carga de trabalho. Deixe espaço para campos de formulário e limites multipartes ao limitar toda a solicitação POST. S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Somente PHP 8.5, mais:

php_admin_flag[fatal_error_backtraces] = off

As funções e limites de cada um são os seguintes:

Configuraçãoefeito esperadoDescrição das restrições que devem ser mantidas
memory_limit=-1Remova a condição de acionamento do limite superior de memória de solicitação previsível PHPNão evita falhas de alocação subjacentes; cancelar o orçamento original pode aumentar o risco de esgotamento da memória e interrupção do serviço.
post_max_size menorReduza o tamanho dos dados que entram no processo de análiseO analisador não corrigido possui lacuna conhecida; a amplificação da memória não pode ser evitada de forma independente
upload_max_filesize < post_max_sizeLimite o tamanho de arquivo único e reserve espaço adicional para solicitaçãoNão restringe todos os campos, metadados ou alocações no aplicativo
Fechar progresso do uploadBloquear o caminho relacionado à sessão confirmadaNão cobre outras variantes de estado global
PHP 8.5 fechar backtrace fatalBloquear produtores de status relacionados confirmadosNão cobre outros caminhos, como sessão

Os limites da medida vêm do anúncio oficial; para sintaxe de pool e semântica de configuração em nível de gerenciamento, consulte o manual PHP. S1S2S3S11

As configurações de nível de gerenciamento php_admin_* não podem ser substituídas por aplicativos via ini_set(). Todas as configurações de entrada de pool, nível de diretório e front-end ainda devem ser revisadas para confirmar se os valores nas solicitações reais estão conforme o esperado. Após a modificação, reconstrua todos os trabalhadores para evitar que os processos existentes continuem mantendo o estado antigo.

Se você optar por modificar php.ini diretamente, a sintaxe deverá ser alterada para:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

Ao contrário de php_admin_value no pool, apenas definir memory_limit=-1 em php.ini não impede que o aplicativo o modifique novamente. A estrutura, o código do aplicativo e outras configurações devem ser verificados para ver se redefiniram o valor limitado; quando a aplicação for necessária, use as configurações de nível de gerenciamento apropriadas para o SAPI atual e verifique o valor efetivo real. S11S12

Adicione fatal_error_backtraces = Off apenas para PHP 8.5. Não use ini_set() em nível de aplicativo como solução alternativa para desabilitar o progresso de upload e não confie em FPM .user.ini para torná-lo efetivo antes da análise da solicitação. S1S3

5.3 Gerenciar o custo de remoção dos limites de memória PHP

memory_limit=-1 é uma mitigação de caminho temporária para ambientes não corrigidos e não deve ser copiada como configuração padrão de longo prazo. Quando um aplicativo ou solicitação fica fora de controle, ele pode usar mais memória do host. Portanto, antes de usar, você deve avaliar o número de simultaneidades, o pico de trabalho único e a capacidade total de serviço, e implantar limites de entrada de front-end. S2

Os limites de memória do contêiner ou do cgroup podem fornecer limites de disponibilidade, mas não garantem que as alocações nunca falharão; todo o contêiner, mestre e todos os trabalhadores também podem ser encerrados quando o limite é acionado. A granularidade do isolamento e as estratégias de encerramento precisam ser avaliadas em conjunto com a implantação e não podem ser chamadas de proteção completa para esses dois CVE. S2

Não substitua as estratégias acima por RLIMIT_AS, RLIMIT_DATA ou restrições de espaço de endereço de processo correspondentes; eles podem fazer com que a alocação subjacente falhe diretamente no caminho OOM ainda problemático. S2

Exemplo de configuração 5.4 Nginx

Aplicável à implantação onde Nginx encaminha solicitações para PHP-FPM. Pode ser definido no nível de configuração do serviço de hospedagem real:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size limita o tamanho do corpo da solicitação; fastcgi_request_buffering on permite que Nginx leia primeiro o corpo completo da solicitação e depois envie-o para o backend FastCGI. Se isso entra em vigor em um determinado server ou location precisa ser verificado em conjunto com os relacionamentos de herança e cobertura existentes. S13S14

Somente quando a empresa não precisa de multipart, você pode adicionar uma regra de rejeição à entrada de serviço correspondente:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Este é um modelo simples de restrição de entrada usando if e return, não uma regra geral de filtragem para vulnerabilidades do analisador. Verifique a sintaxe de configuração e as solicitações normais antes da implantação e verifique se o error_page personalizado redireciona solicitações 403 para PHP. A correspondência de strings não fornece garantias completas sobre todas as diferenças de análise. S15

Além disso, essas configurações não limitam automaticamente a quantidade de dados, o número de campos ou o número de objetos PHP que podem ser descompactados pelo aplicativo; as empresas que precisam fazer upload devem usar restrições adicionais que compreendam a estrutura de suas solicitações.

5.5 Mitigação opcional: uma solicitação por trabalhador FPM

Para implantações FPM que podem arcar com a sobrecarga, as configurações de curto prazo podem ser avaliadas:

pm.max_requests = 1

E reconstrua o trabalhador existente. Ele bloqueia a cadeia de solicitações cruzadas descrita no nível de reutilização do trabalhador, mas aumentará a sobrecarga de criação e inicialização do processo; ao mesmo tempo, ele não pode reparar a mesma solicitação OOM e problemas de limpeza de CVE-2026-109618. Quando o valor é menor, mas maior que 1, ainda há uma janela de reutilização da solicitação. S3S11

Limites de cobertura 5.6 WAF e Cloudflare

Cloudflare anunciou acordos de implantação para proteção contra PHP2Shell, incluindo o plano Free. Ao utilizar seus serviços, você deve verificar se o tráfego real passa pelo proxy, se as regras de proteção estão em vigor e se o site de origem pode ser contornado diretamente; para planos pagos, também é necessário verificar a configuração e as exceções das Regras Gerenciadas correspondentes. S16

Algumas das detecções descritas pelo fornecedor utilizam sinais de resposta, portanto todas as proteções não podem ser interpretadas como “todo ataque é bloqueado antes de atingir PHP”. WAF pode ajudar a reduzir a exposição e fornecer informações observacionais, mas atualizações contínuas para PHP ainda são necessárias. S16

5.7 Por que as medidas comuns são insuficientes

medidas ou julgamentosdeficiências
Fechar apenas file_uploadsNão é possível cobrir todo o processamento multipartes e aplicar seu próprio caminho OOM
Configurando enable_post_data_reading=OffAlterar o comportamento de preenchimento automático de POST/FILES; o corpo da solicitação ainda pode ser lido pelo aplicativo e pode interromper os negócios normais
Desative a exibição de erros, registre ou use @O processamento de diagnóstico interno ainda pode acessar o estado pendente
Aumentar a quantidade de trabalhadoresNão estabeleça um mecanismo seguro de limpeza de estado, nem elimine a reutilização de trabalhador único
Configure apenas disable_functions ou open_basedirEssas limitações não corrigem a corrupção da memória da camada do mecanismo C
Verifique uma versão ou uma única cópia apenas uma vezNão pode ser provado que todas as entradas e instâncias em execução foram substituídas
Nenhum log de exceção é vistoNão pode provar que a vulnerabilidade não existe ou que não foi explorada anteriormente.

Entre eles, a base do mecanismo de configuração e vulnerabilidade de PHP pode ser encontrada em S2S3S12; os julgamentos sobre cobertura, aceitação e limites de permissão baseiam-se nas sugestões de implementação apresentadas por esses mecanismos.

6. Ideias de implementação e pontos de revisão do patch oficial

6.1 Use correções completas para o branch correto

A submissão oficial representativa para PHP 8.5 é:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

O commit associa explicitamente dois CVEs, tanto para ajustar o mecanismo de saída OOM quanto para corrigir o estado global que pode ser acessado durante a fase de inicialização. Enviar página com comparação completa, consulte S4S5. Outras filiais devem usar seus próprios lançamentos de segurança oficiais ou patches correspondentes, e não se pode presumir que as alterações no 8.5 possam ser aplicadas diretamente a qualquer versão mais antiga.

6.2 OOM Reparo: primeiro restaure o estado processável e, em seguida, encerre a solicitação

A implementação formal introduz dois níveis de processamento OOM suave e difícil: quando o limite flexível é atingido, o status pendente é registrado e uma saída controlada é executada em um local seguro como VM; a interface de alocação com falha permite que o chamador lide explicitamente com a falha. Para alocações que não podem retornar falhas diretamente, se for esperado que um limite rígido mais alto seja excedido, o processo será encerrado diretamente para evitar continuar a processar solicitações em um estado intermediário inseguro. S2S5

A seguir está um trecho do código-chave no diferencial 8.5 usado para marcar OOM pendente:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

O tratamento de interrupções VM e outros locais seguros chamam posteriormente zend_handle_delayed_oom(). Seu contexto de execução de código do usuário usa um caminho de desenrolamento controlado; o caminho OOM difícil chama _exit(137). S5

Do ponto de vista do design, as mudanças importantes são: evita cruzar arbitrariamente a pilha de chamadas C quando a estrutura está em um estado intermediário e coloca a saída em um local que pode manter restrições de estado. Depois que o limite flexível é acionado, pode ser necessária memória adicional para concluir o processo, portanto, o novo limite flexível não pode ser entendido como um limite superior absoluto para a memória total do processo.

Nem pode ser resumido como “PHP excluiu todos os zend_bailout()”. O patch ainda utiliza mecanismos relevantes em contextos específicos; o que está resolvido é o perigoso momento de saída e a gestão estatal que o acompanha. S5

6.3 Atualizar chamadores de alocação e análise multiparte juntos

Se você alterar apenas uma função de alocação para “retornar NULL em caso de falha” e o chamador original ainda assumir que um ponteiro válido é sempre retornado, você introduzirá novos acessos de ponteiro nulo ou limpeza incompleta. A interface de alocação com falha no patch precisa ser revisada juntamente com a verificação do chamador e a propagação de exceções. S5

as correções relacionadas a várias partes também incluem a execução de verificações cumulativas com base no volume de leitura real, reduzindo o processamento de cabeçalhos inúteis ou duplicados e adotando uma lógica consistente de saída e limpeza quando OOM está pendente. Essas alterações reduzem a amplificação de recursos e fazem com que o analisador esteja em conformidade com o novo protocolo OOM. S5

Para equipes que mantêm suas próprias filiais, é recomendado que os seguintes problemas sejam o foco da revisão de código:

  • O estado é visível para o mundo exterior antes de ser totalmente inicializado?
  • Após falha na alocação ou exceção de retorno de chamada, a propriedade ainda é única e inequívoca?
  • Você consegue alcançar a saída de limpeza unificada se falhar no meio do caminho?
  • A função de limpeza pode reconhecer campos não inicializados ou liberados?
  • O orçamento de análise é baseado no volume real de processamento e não apenas nas declarações de solicitação de confiança?
  • O novo valor de retorno de falha foi tratado por todos os chamadores?

Estas são questões de revisão resumidas com base no mecanismo de correção e não são a conclusão de uma auditoria que foi concluída para uma base de código não fornecida.

6.4 Correção de solicitação cruzada: inicialização mais cedo, limpeza final mais tarde

Correspondente a CVE-2026-109619, o patch ajusta vários limites do ciclo de vida ao mesmo tempo. Os arquivos e operações listados abaixo usam a comparação oficial PHP 8.5 como exemplo. S5

localizaçãomudar de direçãoProblema resolvido
Zend/zend_execute_API.c etc.Redefina o status do executor, como erros, exceções, manipuladores, objetos, etc.Após o término da solicitação, ainda existem referências antigas que podem ser acessadas na próxima solicitação.
Caminho de inicialização de main/main.cLigue para php_basic_early_rinit() antes que SAPI seja ativadoQuando ocorre um consumidor antecipado, o estado subjacente relevante ainda não foi inicializado.
Fechar caminho de main/main.cDestrua HTTP globals e marque-o como indefinidoO valor liberado ainda é considerado um objeto válido
antes que o heap de solicitação seja finalmente liberadoLimpe a última mensagem de erro novamenteO diagnóstico de limpeza tardia preenche novamente o status do erro
ext/session/session.cprogresso do upload O caminho inicial é inicializado na primeira sessão globalMódulo regular RINIT acessou anteriormente o estado antigo
Código relacionado à serializaçãoLimite a análise de classe e os retornos de chamada do usuário no processamento inicialExecute código de usuário adicional quando a inicialização não for concluída

Por exemplo, a sequência de inicialização inclui:

zend_activate();
php_basic_early_rinit();
sapi_activate();

Depois que HTTP globals for destruído, adicione a marca de falha de status:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Esses trechos ilustram dois princípios: inicializar antes do primeiro consumidor possível e executar a limpeza final após a última operação que pode recriar o estado. Redefinir um ponteiro apenas durante o RINIT normal ou um estágio de desligamento anterior pode perder acessos anteriores ou posteriores. S5

6.5 Por que não é recomendado fazer seu próprio “reparo em uma linha”?

Substituir todos os zend_bailout() por _exit() ou apenas adicionar uma verificação de ponteiro nulo em uma determinada entrada abrangeria um grande número de contextos de execução diferentes. Eles podem omitir outros campos de status ou podem alterar a destruição, retornos de chamada estendidos, hospedagem de processos e solicitação de semântica final.

Para versões suportadas, as correções completas que já foram lançadas têm precedência. A migração de filiais próprias deve registrar a origem dos patches, linhas de base aplicáveis, tratamento de conflitos e mudanças de comportamento, e usar casos de uso de regressão upstream correspondentes e verificação deste processo de negócios. As sugestões aqui vêm de uma análise do escopo do patch no alocador, VM, sessão e alterações no ciclo de vida da solicitação. S4S5

7. Backport de emergência de PHP 7.4, 8.0, 8.1

PHP fornece oficialmente o backport mínimo do código-fonte de três ramificações antigas com base na gravidade. Os nomes das filiais são:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Para links de ramificação, consulte S7S8S9. Estas são entregas de emergência para esta vulnerabilidade e não representam um retorno ao suporte upstream regular para a filial antiga, nem substituem outras atualizações de segurança. S1

7.1 Tome o backport PHP 8.1 como exemplo

Os envios relevantes para PHP 8.1 são:

1d7dec178a094e6e75b229ce22754045f8c6070a

Sua estratégia favorece a falha rápida: chamar _exit(1) após gerar diagnósticos no caminho OOM correspondente e incluir status global e outras correções relevantes; enquanto desativa internamente o processamento correspondente do progresso do upload da sessão. Para envio de código-fonte relevante, consulte S6.

Esta é uma diferença comportamental em relação ao design OOM atrasado mais completo na ramificação suportada. Só porque a configuração ainda mostra que o progresso do upload está ativado, isso não significa que o comportamento do processamento interno após esse backport permanecerá inalterado.

7.2 O preço que você precisa aceitar ao implantar

Sair diretamente do processo pode causar falha na solicitação atual, ignorando os retornos de chamada normais de desligamento PHP e parte do fechamento do aplicativo; se o host adotar um modelo de thread, também será necessário avaliar o impacto de toda a saída do processo host em outros trabalhos simultâneos. Se o gerente do processo pode iniciar o processo de substituição a tempo também deve ser incluído na verificação.

Portanto, os usuários de versões mais antigas devem considerar em ordem:

  1. Migre para a filial PHP suportada e sua versão fixa.
  2. Use uma versão que cubra explicitamente CVE ou a atualização do fabricante LTS.
  3. Se estiver realmente sujeito à versão antiga do código-fonte, use o backport de emergência oficial da versão correspondente para verificar as alterações completas e a compatibilidade e providenciar a migração subsequente.

O “backport mínimo” aqui descreve o escopo de compatibilidade e implementação selecionado pelo oficial e não deve ser interpretado automaticamente como “correções de vulnerabilidades incompletas conhecidas”. Você deve julgar com base no código-fonte da filial correspondente e no anúncio do fabricante e não excluir as alterações de suporte por conta própria. S1S6

8. Critérios de aceitação e inspeções de acompanhamento

Recomenda-se que os seguintes resultados sejam usados como base para concluir este reparo:

Itens de aceitaçãoPadrões de conclusão
cobertura de vulnerabilidadeO anúncio da versão ou do fornecedor corrige explicitamente CVE-2026-109618 e CVE-2026-109619
Cobertura de implantaçãoTodos os portais, pools, serviços e réplicas usam o tempo de execução reparado
Processo entra em vigorO antigo trabalhador, o antigo processo de host e o antigo contêiner saem
Verificação de solicitação autênticaSAPI confirmado, construído e configurado com link Web real para eliminar o direcionamento incorreto do cache
disponibilidade comercialFunções importantes como sessão, upload, importação e tratamento de erros retornaram normalmente.
Fim das medidas temporáriasMemória ilimitada e configurações extremas de reciclagem de trabalhadores foram restauradas de acordo com o plano de capacidade ou têm um motivo claro para retenção
Evidência de mudançaRegistre a versão do pacote ou resumo da imagem, atualize o escopo, o tempo de conclusão e os resultados da verificação

O acima são sugestões para implementação. Se precisar verificar o comportamento de OOM, saída anormal ou patches personalizados, você deve usar testes de regressão upstream ou injeção controlada de falhas em um ambiente isolado para evitar a criação repetida de esgotamento de memória no ambiente de produção como um método de aceitação.

Verifique também o PHP fatal, falha do trabalhador, reinicialização anormal, taxa de erro de solicitação e eventos WAF antes e depois da atualização. Os logs só podem fornecer pistas de investigação: a ocorrência de OOM não significa que tenha sido explorado e a falta de alarmes não prova que não ocorreu exploração. A atualização corrige caminhos de vulnerabilidade que podem ser alcançados no futuro; se forem encontradas anomalias, como adulteração de arquivos ou vazamento de credenciais, investigações separadas do incidente deverão ser realizadas.

Todos os links de fontes são coletados abaixo. Os avisos, patches e orientações do fornecedor refletem as verificações de 22 de outubro de 2026; implantações subsequentes devem verificar atualizações do fornecedor. As citações numeradas no texto referem-se a essas entradas.

S1 — Boletim de segurança oficial PHP e versão de reparo

  • Fonte: Projeto PHP, 21 de outubro de 2026.
  • Objetivo: Escopo de risco, quatro versões oficiais de reparo, medidas temporárias oficiais e instruções de backport de emergência para filiais antigas.
  • Referência: PHP 2026 This security bulletin está no arquivo do boletim anual

S2 — Boletim Técnico Oficial CVE-2026-109618

  • Fonte: php/php-src GitHub Security Advisory, 21 de outubro de 2026.
  • Identificação: GHSA-w8hw-w9fx-j79w.
  • Objetivo: Limite de cobertura para OOM, amplificação multiparte, diferença e mitigação SAPI.
  • Referência: RCE via OOM corruption

S3 — Boletim Técnico Oficial CVE-2026-109619

  • Fonte: php/php-src GitHub Security Advisory, 21 de outubro de 2026.
  • Identificação: GHSA-6wmf-4rv5-p3rp.
  • Objetivo: Estado pendente de solicitação cruzada, produtores e consumidores, inicialização antecipada, mitigação de configuração.
  • Referência: RCE via stale global state

S4 — Envio de correção oficial PHP 8.5

  • Fonte: php/php-src.
  • Enviar: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • Objetivo: confirmar o envio formal para corrigir duas vulnerabilidades ao mesmo tempo e explicar a direção geral da mudança.
  • Referência: Avoid state corruption via bailout

S5 — PHP 8.5 Oficialmente restaurado e diferencial completo

  • Fonte: diff do mesmo envio oficial.
  • Objetivo: Verificar a implementação específica do alocador, VM, HTTP globals, sessão, serialização e ciclo de vida da solicitação.
  • Referência: oficial completo diff

S6 — PHP 8.1 envio oficial de backport de emergência

S7 — PHP 7.4 filial oficial de backport de emergência

S8 — PHP 8.0 filial oficial de backport de emergência

S9 — PHP 8.1 filial oficial de backport de emergência

S10 — Boletim de segurança Ubuntu USN-8948-1

  • Fonte: Canonical / Ubuntu, 21 de outubro de 2026.
  • Objetivo: Liberar backport e exemplos completos de versões de pacotes.
  • Referência: USN-8948-1: PHP vulnerabilities

Manual S11 — PHP-FPM Configuration

  • Fonte: documento oficial PHP.
  • Objetivo: Semântica de configuração como php_admin_value, php_admin_flag, pm.max_requests, etc.
  • Referência: PHP-FPM Configuration

S12 — Manual de configuração do núcleo PHP INI

  • Fonte: documento oficial PHP.
  • Finalidade: Definição e escopo do corpo da solicitação, upload, memória e configuração automática de leitura do POST.
  • Referência: Description of core php.ini directives

S13 — Nginx limite de tamanho do corpo da solicitação

S14 — Buffer de solicitação Nginx FastCGI

S15 — Nginx Condição e instruções de devolução

  • Fonte: documento oficial Nginx.
  • Objetivo: Sintaxe de configuração de if e return.
  • Referência: ngx_http_rewrite_module

S16 — Instruções de proteção Cloudflare PHP2Shell