• /
  • EnglishEspañolFrançais日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

NR26-10: vulnerabilidades de tempo de execução do PHP (CVE-2026-109618, CVE-2026-109619)

|View as Markdown (English)

Vulnerability Identifier: NR26-10

Priority: Crítico

Sumário:

Duas vulnerabilidades críticas (CVSS 9,2) foram divulgadas no runtime do PHP. Elas afetam as versões 5.4.0 e posteriores do PHP que atendem a requests da web. O projeto PHP lançou correções em 21 de outubro de 2026.

Os serviços da New Relic não foram afetados, e a New Relic não identificou nenhuma evidência de exploração dessas vulnerabilidades em seu ambiente. O agente PHP da New Relic é executado dentro do próprio ambiente PHP dos clientes e não é, por si só, o componente vulnerável.

Clientes que executam aplicativos PHP, com ou sem a instrumentação da New Relic, ainda devem avaliar suas versões do PHP.

Ação recomendada:

Nenhuma ação é necessária em relação aos seus serviços da New Relic. No entanto, a New Relic recomenda fortemente que os clientes que executam PHP atualizem para uma versão corrigida do PHP (para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35). Se você não puder atualizar imediatamente, aplique um conjunto de regras WAF que cubra essas CVEs e limite a exposição à internet dos aplicativos afetados até que possa.

Recomendações:

  • Pacotes de distribuição:
    • As distribuições Linux e os fornecedores de LTS receberam os patches com antecedência. Verifique com seu fornecedor os pacotes atualizados.
  • Versões em fim de vida útil (PHP 8.1 e anteriores):
    • Algumas distribuições e fornecedores de LTS fornecem correções de backport, portanto, entre em contato com seu fornecedor ou atualize para uma versão compatível. Devido à gravidade, a equipe de segurança do PHP também publicou backports de código-fonte mínimos para PHP 7.4, 8.0 e 8.1 para organizações que compilam a partir do código-fonte ou não têm um fornecedor de LTS.
  • Usuários do rpms.remirepo.net:
    • Este repositório mantido por voluntários não terá atualizações no dia do lançamento. A equipe do PHP recomenda fortemente que os usuários mudem para pacotes de distribuição ou compilem a partir do código-fonte.

Onde a aplicação imediata de patches não for viável, as organizações devem considerar o isolamento de recursos voltados para a internet de redes públicas até que a correção seja aplicada e verificada.

Mitigação temporária:

Apenas uma atualização corrige totalmente essas vulnerabilidades. As medidas abaixo reduzem a exposição a caminhos de ataque específicos, mas não tornam uma instalação segura.

CVE-2026-109618 (corrupção de OOM):

  • Defina memory_limit=-1 de uma forma que os aplicativos não possam substituir, como php_admin_value no pool FPM ou na configuração do Apache. Verifique se nenhuma configuração de pool, diretório ou aplicativo impõe um limite finito novamente. Isso remove a falha de limite de memória controlável, mas uma falha de alocação subjacente ainda pode atingir o caminho de código vulnerável.

  • Defina um post_max_size baixo: 8M para aplicativos que não precisam de uploads de arquivos, 32M se os uploads forem necessários. Mantenha o upload_max_filesize abaixo do post_max_size.

  • Considere impor limites no nível do servidor web ou proxy para o tamanho decodificado de requests, contagem de campos de entrada, contagem de partes multipart, contagem de cabeçalhos e profundidade de aninhamento. Esses limites também devem abranger requests sem um Content-Length utilizável.

  • Use um limite de memória de contêiner ou cgroup como um limite de disponibilidade, preferencialmente com uma política que encerre apenas o worker afetado. Não use RLIMIT_AS ou RLIMIT_DATA em vez disso, pois eles podem acionar a falha de alocação vulnerável.

CVE-2026-109619 (estado global obsoleto):

  • Defina session.upload_progress.enabled=0 e reinicie cada worker. Aplique isso no php.ini, em um pool FPM ou em uma configuração de servidor que entre em vigor antes da análise de requests. Não dependa do ini_set() ou do .user.ini do FPM. Isso bloqueia os caminhos de sessão confirmados, mas não outras variantes.

  • No PHP 8.5, defina fatal_error_backtraces=0 e reinicie todos os workers. Isso bloqueia apenas o caminho de backtrace fatal confirmado.

  • Remova as configurações por solicitação inválidas ou obsoletas que emitem diagnósticos antes da inicialização. Ocultar diagnósticos com error_reporting, display_errors ou @ não ajuda.

  • Corrigir erros fatais e tempos limite de execução que podem ser alcançados por invasores, incluindo falhas em retornos de chamada, processamento de upload ou importação e limpeza.

Perguntas frequentes:

  1. Como posso descobrir qual versão do PHP estou usando?

    Execute php -v no host ou no contêiner. Para a versão do PHP que a New Relic vê, verifique os detalhes do host ou do aplicativo na interface da New Relic.

  2. O agente PHP da New Relic precisa ser atualizado?

    As vulnerabilidades estão no tempo de execução do PHP, não no agente. A atualização do PHP é a correção necessária.

  3. Estou executando uma versão do PHP em fim de vida útil. O que devo fazer?

    O PHP 8.1, 8.0 e todas as ramificações 7.x e 5.x não receberão correções oficiais. Verifique se a sua distribuição Linux (como Ubuntu ou AlmaLinux) lançou um patch de backport e planeje uma atualização para uma ramificação compatível.

  4. Como posso saber se meus sistemas foram o destino?

    Analise os logs da web e do WAF a partir de 21 de outubro de 2026. Os indicadores relatados publicamente incluem o agente de usuário php2shell-verify/1.0 e requests para /vuln.php. Procure também por processos de servidor web ou PHP gerando comandos de shell, e por arquivos PHP novos ou modificados em diretórios web.

  5. Um WAF pode me proteger até que eu aplique o patch?

    Um WAF pode reduzir o risco. A Cloudflare publicou regras de WAF de emergência para essas vulnerabilidades, e outros fornecedores podem oferecer proteção semelhante. Um WAF é uma mitigação temporária, não um substituto para a atualização do PHP.

  6. Tenho dúvidas ou preocupações sobre essas vulnerabilidades. Com quem devo entrar em contato?

    Se você tiver alguma dúvida sobre essas vulnerabilidades e como elas se relacionam aos seus serviços da New Relic, abra um caso de suporte por meio do suporte no aplicativo ou entre em contato com seu representante de conta da New Relic.

Documentos de suporte:

Informações técnicas de vulnerabilidades:

Para qualquer necessidade de suporte relacionada a este comunicado, por gentileza, abra um caso de suporte por meio do suporte no aplicativo.

Histórico de publicação: 23 de outubro de 2026 - NR26-10 publicado

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.