Segurança PHP: como proteger meus servidores contra vulnerabilidades?

Este tópico foi traduzido automaticamente do espanhol. Ver original
R

robo

Épsilon
Usuário com poucas negociações! Use sempre o saldo do ForoBeta!
O NCSC insta as organizações do Reino Unido a tomar medidas imediatas para mitigar um problema de segurança que afeta o PHP (CVE-2026-109618 e CVE-2026-109619).

1792593220187.webp

O que aconteceu?​

O PHP publicou uma atualização de segurança para solucionar um problema crítico que poderia permitir que atacantes executassem comandos em qualquer servidor web que execute PHP.

PHP (PHP Hypertext Preprocessor) é uma linguagem de programação do lado do servidor amplamente utilizada, projetada para o desenvolvimento web. Ela é executada em um servidor web para gerar conteúdo dinâmico para as páginas, interagir com bancos de dados e gerenciar a lógica da aplicação no servidor antes de entregar o HTML final ao navegador do usuário. O PHP também é utilizado em uma variedade de outros produtos.

O problema de segurança poderia permitir que um atacante provocasse um erro de memória insuficiente (OOM) no PHP, o que resultava em uma corrupção de memória. Em determinadas circunstâncias, essa corrupção poderia ser explorada para obter a execução remota de código sem autenticação. Este problema de segurança já foi solucionado.

  • CVE-2026-109618 : O tratamento de erros de memória pode interromper o PHP enquanto os dados internos da solicitação foram apenas parcialmente inicializados. A limpeza da solicitação pode, então, tratar os dados inválidos como válidos.
  • CVE-2026-109619 : O estado interno de propriedade de uma solicitação pode persistir mesmo depois que sua memória de suporte tenha sido liberada. Uma solicitação posterior processada pelo mesmo trabalhador pode utilizar esse estado obsoleto antes que a inicialização normal o restabeleça.
O aviso de segurança completo do PHP fornece mais detalhes sobre o problema de segurança solucionado.

O NCSC continuará monitorando qualquer impacto nas organizações do Reino Unido.

Quem são os afetados?​

As organizações que utilizam qualquer versão do PHP são afetadas e recomenda-se fortemente que atualizem para a última versão corrigida. As organizações que utilizam versões anteriores do PHP também devem atualizar para uma versão com suporte completo.

O que devo fazer?​

O NCSC recomenda seguir as melhores práticas dos fornecedores para a mitigação de vulnerabilidades. O NCSC insta fortemente as organizações a seguirem estas ações prioritárias:

  1. Identifique os sistemas que executam PHP em sua infraestrutura, dando prioridade aos sistemas com acesso à internet. Como todas as versões podem ser afetadas, não limite a detecção a versões obsoletas do PHP; identifique as instalações de PHP em geral e avalie sua exposição às vulnerabilidades CVE-2026-109618 e CVE-2026-109619.
  2. Monitore continuamente as atualizações de segurança de fornecedores de software externos, incluindo dispositivos e serviços que possam incluir PHP como componente. Aplique as atualizações pertinentes assim que estiverem disponíveis.
  3. Atualize para a última versão do PHP e continue atento a futuras atualizações.
  4. Aplique os passos de reforço adicionais fornecidos pela equipe do PHP .
  5. Se não puder atualizar para uma versão com a atualização de segurança aplicada, a equipe do PHP forneceu soluções temporárias .
  6. Se não puder aplicar as medidas de mitigação temporárias, ou se sua aplicação levaria tempo demais, você deve considerar a possibilidade de desconectar o sistema até que as deficiências possam ser totalmente solucionadas.
  7. Se não puder atualizar ou desabilitar o sistema imediatamente, você deve avaliá-lo em busca de indícios de violação antes da atualização ou da mitigação, e procurar por backdoors instaladas por um atacante. Se não se sentir seguro em fazer isso sozinho, você pode obter ajuda de um fornecedor de resposta a incidentes cibernéticos certificado pelo NCSC .
  8. Monitore continuamente as atualizações de segurança de fornecedores de software externos, incluindo dispositivos e serviços que possam incluir PHP. O NCSC-NL publicou um inventário de produtos de software com dependência de PHP que poderiam ser afetados pelas vulnerabilidades.

Recursos adicionais do NCSC​

 
Foi útil? Participe da conversa

Com sua conta grátis você pode responder, mandar mensagem privada ao autor e comprar com Saldo retido: o pagamento é liberado quando você recebe o combinado.

Leva 30 segundos · você volta a este tópico ao terminar
Obrigado pela informação. Efetivamente, o cPanel já publicou as correções, inclusive para versões antigas do PHP.

No changelog oficial do EasyApache 4, versão 25.91 (21/10/2026), confirma-se:

  • PHP 7.4: EA-13613 — Backport do patch para CVE-2026-109618 e CVE-2026-109619 para ea-php74.
  • PHP 8.0 e 8.1: Também receberam patches retroportados.
  • PHP 8.3: Atualização de 8.3.35 para 8.3.36.
Fonte oficial do cPanel:
https://docs.cpanel.net/changelogs/easyapache-4-change-log-25/

O CloudLinux também está distribuindo atualizações para alt-php, incluindo o PHP 7.4:

https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5

Importante: O PHP 7.4 pode continuar mostrando a versão 7.4.33 mesmo após receber as correções, já que são patches retroportados.

A dúvida é se estes pacotes já foram instalados nos servidores da BanaHosting, porque a atualização do próprio cPanel não garante que as versões do PHP utilizadas pelos sites estejam com os patches aplicados.

Poderiam confirmar se as correções de ambas as CVE já estão aplicadas em seus servidores de hospedagem compartilhada, tanto para ea-php quanto para alt-php (se aplicável)?

Obrigado!

- ChatGPT
Já foram instalados imediatamente após o anúncio do cPanel.
 
Por que me indica que a versão disponível no cPanel é a v8.2.34? O comunicado em https://www.php.net/index.php indica que a versão com o patch de segurança é a 8.2.35.?
Vemos que o cPanel indicou o patch para versões do PHP

2026-10-21​

  • Fixed CPANEL-57977: Update cpanel-php84 to 8.4.27. Fixes: CVE-2026-109618 and CVE-2026-109619.
Aguardando o lançamento dos demais. que precisam lançar EA e ALT.

Estamos no aguardo, por enquanto aplicamos a mitigação manual.
E também o Imunify360 lançou mitigação. e também o monarx. temos várias camadas de proteção.
 
Vemos que o cPanel indicou o patch para versões do PHP

2026-10-21​

  • Fixed CPANEL-57977: Update cpanel-php84 to 8.4.27. Fixes: CVE-2026-109618 and CVE-2026-109619.
Aguardando o lançamento dos demais. que precisam lançar EA e ALT.

Estamos no aguardo, por enquanto aplicamos a mitigação manual.
E também o Imunify360 lançou mitigação. e também o monarx. temos várias camadas de proteção.
@banahosting.com Acabei de verificar diretamente pelo PHP em um dos servidores da BanaHosting e o PHP_VERSION continua retornando 8.3.35, não 8.3.36.

Pode ser que a atualização ainda não tenha sido implantada em todos os servidores?
 
Por favor, leia minha resposta anterior. Já confirmado que está sendo protegido com o Imunify360, que sim, já lançou regras de proteção.
 
Por favor, leia minha resposta anterior. Já confirmado que está sendo protegido com o Imunify360, que sim, já lançou regras de proteção.
Sim, li a resposta e entendo que o Imunify360 já tem regras ativas para mitigar a exploração.

Mas eu me referia à atualização do PHP em si. O PHP recomenda atualizar para as versões corrigidas, já que as regras do Imunify360 são uma mitigação e não substituem o patch.

Acabei de verificar o PHP_VERSION diretamente de um de seus servidores e atualmente continua executando o PHP 8.3.35, quando a versão corrigida desse ramo é a 8.3.36.

Por isso perguntei se os pacotes corrigidos já foram instalados em todos os servidores ou se a implantação ainda está em processo.
 
Sim, li a resposta e entendo que o Imunify360 já tem regras ativas para mitigar a exploração.

Mas eu me referia à atualização do PHP em si. O PHP recomenda atualizar para as versões corrigidas, já que as regras do Imunify360 são uma mitigação e não substituem o patch.

Acabei de verificar o PHP_VERSION diretamente de um de seus servidores e atualmente continua executando o PHP 8.3.35, quando a versão corrigida desse ramo é a 8.3.36.

Por isso perguntei se os pacotes corrigidos já foram instalados em todos os servidores ou se a implantação ainda está em processo.
Para o PHP em si, deve-se esperar que o cPanel o faça. Não está em nosso poder. Cada painel deve lançar as atualizações.
 
Para o PHP em si, deve-se esperar que o cPanel o faça. Não está em nosso poder. Cada painel deve lançar as atualizações.
Então é exatamente o que não consigo entender.

Antes indicaram que o cPanel já tinha publicado a atualização e que vocês a tinham instalado imediatamente.
No entanto, acabei de verificar diretamente a versão que está executando um de seus servidores e continua sendo o PHP 8.3.35.

Se o cPanel já publicou o ea-php83 8.3.36, qual atualização do cPanel resta pendente para que o PHP 8.3.36 esteja disponível nesse servidor?
 
Então é exatamente o que não consigo entender.

Antes indicaram que o cPanel já tinha publicado a atualização e que vocês a tinham instalado imediatamente.
No entanto, acabei de verificar diretamente a versão que está executando um de seus servidores e continua sendo o PHP 8.3.35.

Se o cPanel já publicou o ea-php83 8.3.36, qual atualização do cPanel resta pendente para que o PHP 8.3.36 esteja disponível nesse servidor?
O cPanel indica a URL com o update do cPanel onde mostra qual versão está atualizada.

Sobre as demais, estão sendo protegidas com Imunify360 e monarx.

Para que estejam corrigidas diretamente no PHP, é preciso esperar o cPanel atualizar.

Pode acompanhar as notícias diretamente pelo cPanel:

Igualmente, estamos atentos aos updates como sempre e aplicando-os instantaneamente assim que disponíveis.

Abraços!
 
cPanel indique o URL com o update do cPanel onde indica qual versão está atualizada.

Sobre as demais, estão sendo protegidas com imunify360 e monarx.

Para que estejam corrigidas diretamente no PHP, é preciso esperar o cPanel atualizar.

Pode seguir as notícias diretamente pelo cPanel :

Igualmente, estamos atentos aos Updates como sempre e aplicando-os instantaneamente assim que disponíveis.

Abraços!
Obrigado pelo esclarecimento.
Então entendo que atualmente as versões de PHP desses servidores ainda não estão corrigidas diretamente e que, enquanto o cPanel publica os pacotes correspondentes, a proteção que têm aplicada é mediante Imunify360 e Monarx.

Era exatamente o que eu queria esclarecer, porque ao indicar anteriormente que as atualizações tinham sido instaladas imediatamente, entendi que se referiam também aos pacotes de PHP.

Na minha verificação, o PHP 8.3 continua retornando 8.3.35, então ficarei atento a quando a 8.3.36 estiver disponível. Obrigado.
 
Obrigado pelo esclarecimento.
Então entendo que atualmente as versões de PHP desses servidores ainda não estão corrigidas diretamente e que, enquanto o cPanel publica os pacotes correspondentes, a proteção que têm aplicada é mediante Imunify360 e Monarx.

Era exatamente o que eu queria esclarecer, porque ao indicar anteriormente que as atualizações tinham sido instaladas imediatamente, entendi que se referiam também aos pacotes de PHP.

Na minha verificação, o PHP 8.3 continua retornando 8.3.35, então ficarei atento a quando a 8.3.36 estiver disponível. Obrigado.
o cPanel já lançou as correções e todos os servidores de Hosting/Reseller estão atualizados.

rpm -q --changelog ea-php83-php-cli | grep -m1 CVE-2026-109618
url_scanner_ex.c and ext/json/json_scanner.c for the CVE-2026-109618/109619 patch: el7/el8 re2c 0.14.3
 
Vou contribuir com o procedimento, que é o que serve quando sai um aviso como este, mais do que discutir o CVE concreto.

Primeiro: saber qual versão você tem de verdade. Cuidado com isso, que é onde quase todo mundo se engana. php -v te diz a versão do binário por padrão, mas se você tem painel (HestiaCP, cPanel, Plesk) pode haver várias versões instaladas e cada site usando uma diferente. No cPanel, vê-se no "MultiPHP Manager"; no Hestia, nas opções de cada domínio. Atualizar a do sistema não resolve nada se o seu site roda com um 7.4 que continua lá.

Segundo: atualizar e verificar se atualizou. No Debian/Ubuntu:

Inserir CODE, HTML ou PHP:
apt update && apt -y upgrade
php -v

Se o pacote não sobe de versão porque a distro já não a suporta, isso não é um problema de correção: é uma versão fora de suporte e é preciso migrar. E antes de mexer na produção, cópia e janela de manutenção: um apt upgrade de PHP pode quebrar um site com extensões compiladas.

Terceiro: se não puder atualizar hoje, o que acontece muito por compatibilidade da aplicação, há três correções de emergência que funcionam:

1. Regra no WAF (Cloudflare, CrowdSec, ModSecurity): bloquear os padrões de requisição associados à falha. Não substitui a correção, mas ganha tempo.
2. Fechar o que não se usa: display_errors desligado, allow_url_include em Off, e revisar os disable_functions do pool (sobretudo no PHP-FPM, no php.ini do pool e não no global).
3. Vigiar os logs: requisições estranhas repetidas ao mesmo endpoint em pouco tempo costumam ser alguém testando. Com Fail2ban ou CrowdSec, cortar por IP.

E a parte que quase ninguém diz: 90% dos servidores que vejo comprometidos não caíram por um 0-day de PHP, caíram por uma versão antiga abandonada, um plugin sem atualizar ou um painel exposto. Os CVEs críticos ganham as manchetes; os descuidos de todos os dias levam os sites.

Uma observação sobre o aviso original: os dois CVEs citados são do UK (NCSC) e não conheço o detalhe técnico exato, então não vou opinar sobre sua gravidade. O procedimento acima aplica-se da mesma forma, e é o que deve ser feito com qualquer aviso de PHP: versão real por site, correção, verificação e cópia antes de mexer.
 
Voltar
Topo