Vulnerabilidade crítica - Se você usa PHP, seu negócio está em perigo

Patches implantados a tempo! é hora de fazer testes para ver como afeta um ambiente vulnerável

Agora sim todo mundo está blindado!!!!!!!! :v Yijaaaaaaaaaaaaaaaaaaaaaa. Por sinal, o comentário dos 70% a mais a meu favor, você sabe quantas vendas na internet de themes? Por exemplo, eu sou o vivo exemplo: parei de comprar themes originais de WP, bonitos e tudo isso, já que indexavam bem no Google, full SEO e tudo eu configurava bem legal e :v o que eles vivem fazendo é pisar na bola. Parei de investir em themes.

Até o FBI emitiu um comunicado, deve ser algo grave então

perez2005 disse:

Até o FBI emitiu um comunicado, deve ser algo grave então

Clique para expandir...

Sim, também vi e é verdade.
A divisão de cibersegurança do FBI alertou sobre as duas vulnerabilidades do PHP (CVE-2026-109618 e CVE-2026-109619) e recomendou atualizar o quanto antes.
Inclusive indicaram que, se não fosse possível aplicar a atualização imediatamente, que se avaliasse deixar temporariamente offline os sistemas vulneráveis.

Então sim, parece que desta vez a coisa era bastante séria 😅

Fonte: Associated Press, que repercute o alerta do FBI:
https://apnews.com/article/php-websites-fbi-europe-vulnerability-a0af9576808a0963efca8df14d4b5183

Acredito que estamos entrando em uma etapa bastante interessante, mas também complicada para quem trabalha com desenvolvimento e infraestrutura.

Com ferramentas como REA (Reverse Engineer Anything) e os avanços da inteligência artificial, a engenharia reversa e a análise de código estão alcançando níveis de automação que antes exigiam muito mais tempo e conhecimento especializado.

Minha impressão é que nos próximos meses e anos veremos aparecer uma quantidade importante de vulnerabilidades que provavelmente levam muito tempo ocultas.

Nos espera um processo longo de descobertas, patches, atualizações e certamente as eternas discussões sobre qual linguagem ou tecnologia é mais segura. 😅

Mas também vejo algo positivo: essa pressão pode obrigar a melhorar as práticas de desenvolvimento, auditoria e manutenção de software.

A IA está mudando as regras do jogo, tanto para quem busca vulnerabilidades quanto para quem tem que defender a infraestrutura.

E acredito que apenas estamos começando.😅

soyjuli_us disse:

Acho que estamos entrando em uma etapa bastante interessante, mas também complicada para quem trabalha com desenvolvimento e infraestrutura.

Com ferramentas como REA (Reverse Engineer Anything) e os avanços da inteligência artificial, a engenharia reversa e a análise de código estão alcançando níveis de automação que antes exigiam muito mais tempo e conhecimento especializado.

Minha impressão é que nos próximos meses e anos veremos aparecer uma quantidade importante de vulnerabilidades que provavelmente estão ocultas há muito tempo.

Nos espera um processo longo de descobertas, patches, atualizações e certamente as eternas discussões sobre qual linguagem ou tecnologia é mais segura. 😅

Mas também vejo algo positivo: essa pressão pode obrigar a melhorar as práticas de desenvolvimento, auditoria e manutenção do software.

A IA está mudando as regras do jogo, tanto para quem busca vulnerabilidades quanto para quem tem que defender a infraestrutura.

E acho que estamos apenas começando.😅

Clique para expandir...

É exatamente assim!!!
A IA é muito boa, te ajuda muito, mas também tudo isso em resumo, mais dores de cabeça xD.

Sobre o que foi comentado de que o primeiro patch não funcionava, já há uma novidade oficial que vale acrescentar ao tópico, mas com suas condições específicas.

O PHP publicou em 23 de outubro um aviso adicional sobre o progresso de upload de sessões, associado ao CVE-2026-115560. Ele descreve uma combinação pouco comum: configurar session.serialize_handler como php_binary ou php_serialize, trocá-lo para php durante a execução antes de session_start(), e manter habilitado o progresso de upload. Recomendam desativar essa função até a próxima versão corretiva. Se você já a desativou seguindo o aviso anterior, indicam mantê-la assim.

Isso merece atenção, mas não demonstra por si só que as «três vias» mencionadas antes sejam três bypass confirmados do patch. Para afirmar isso seria necessária a referência técnica, a compilação testada e as condições de reprodução. Os dois CVE originais têm suas correções publicadas; este aviso posterior deve ser tratado com o seu próprio alcance.

A diretiva é esta, aplicada no php.ini ou na configuração administrativa que carrega o PHP do site antes de processar as requisições:


Com FPM eu não contaria com colocá-la no .user.ini nem com um ini_set() dentro da aplicação. Depois é preciso reiniciar todos os workers afetados e verificar a configuração deles. Isso não substitui atualizar o interpretador para as duas falhas originais, e pode afetar as barras de progresso que dependam dessa função.

Na minha empresa e com servidores de clientes passei dois dias revisando este incidente; somaram-se também os avisos independentes de Node.js e Java. O que mais deu trabalho foi verificar o que estava realmente em execução: havia vários ramos, processos que continuavam com o binário anterior e componentes com seu próprio runtime. Por isso eu não daria a intervenção por encerrada vendo apenas que o painel foi atualizado ou que um download terminou bem.

A revisão forense foi outra parte do trabalho: cruzar requisições, registros do WAF, erros de processos, arquivos modificados e mecanismos de persistência. Uma requisição com assinatura do exploit comprova uma tentativa; para falar de execução bem-sucedida são necessárias mais provas. Uma data recente em um PHP também não basta para chamá-lo de webshell: pode ser uma atualização legítima, e é preciso conferir antes de mexer nele.

No que revisei não encontrei evidência de exploração bem-sucedida. Isso tem um alcance concreto e eu não o transformaria em «estamos todos blindados». O encerramento que posso explicar a um cliente é qual runtime e compilação ficaram verificados, quais processos foram renovados, quais rastros foram revisados e quais limitações essa revisão teve.

Deixo a atualização do dia 23, que é a fonte para esse cenário adicional: https://www.php.net/archive/2026.php#2026-10-23-1

PHP2Shell: CISA adiciona CVE-2026-109618 e CVE-2026-109619 ao seu catálogo KEV​

A CISA adicionou em 26 de outubro as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell, ao seu catálogo de vulnerabilidades exploradas conhecidas (KEV).

São vulnerabilidades do próprio PHP que, sob determinadas condições, podem permitir execução remota de código (RCE) sem autenticação.

Além da inclusão no KEV, já foi observada atividade tentando explorá-las e existem provas de exploração com RCE bem-sucedido em honeypots.

Quais versões estão corrigidas?​

As atualizações do PHP que resolvem o problema foram publicadas em 21 de outubro.

Para as branches atuais:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Se vocês usam versões fornecidas pela sua distribuição Linux, painel de controle ou provedor de hospedagem, confiram também os avisos deles, já que podem aplicar seus próprios patches ou backports.

Por exemplo, o Plesk já publicou atualizações específicas para as versões de PHP que distribui.

Não é um problema exclusivo do WordPress​

Isto não é uma vulnerabilidade do WordPress nem de um CMS específico, e sim do PHP.

Portanto, pode afetar servidores que tenham WordPress, Joomla, Drupal, scripts próprios ou outras aplicações PHP, desde que estejam usando uma versão vulnerável e existam as condições necessárias para explorá-la.

Se vocês administram o seu próprio VPS ou servidor, eu verificaria qual versão do PHP está rodando e atualizaria o quanto antes se estiver afetada.

Ter firewall, fechar portas que não usamos etc. ajuda, mas não substitui as atualizações de segurança do próprio PHP.

Quantos servidores podem estar expostos?​

A Censys criou um tracker específico para o PHP2Shell usando seus escaneamentos da Internet:

https://php2shell.censys.com/

Ele permite ver a evolução das versões de PHP observadas na Internet, hosts potencialmente afetados, países, redes etc.

Importante: o fato de a Censys detectar uma versão aparentemente vulnerável não significa automaticamente que esse servidor seja explorável. Pode existir um patch aplicado pelo provedor ou pela distribuição sem mudar o número da versão, e também depende da configuração do servidor.

Para quem tiver curiosidade sobre infraestrutura e dispositivos expostos na Internet, também existe o dashboard da Shadowserver:

https://dashboard.shadowserver.org/

Ali é possível consultar estatísticas de serviços e dispositivos expostos, vulnerabilidades observadas, fabricantes, modelos, países etc.

Fontes​

CISA KEV:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Censys - PHP2Shell Exposure Tracker:
https://php2shell.censys.com/

Shadowserver Dashboard:
https://dashboard.shadowserver.org/

Plesk - CVE-2026-109618 / CVE-2026-109619:
https://support.plesk.com/hc/en-us/...mote-code-execution-in-PHP-shipped-with-Plesk

The Record - PHP vulnerabilities adicionadas ao KEV:
https://therecord.media/php-vulnerabilities-cisa-kev

Se vocês têm um VPS administrado por vocês mesmos, eu daria uma olhada na versão do PHP que vocês têm instalada, por via das dúvidas.

Tronlar disse:

PHP2Shell: CISA adiciona CVE-2026-109618 e CVE-2026-109619 ao seu catálogo KEV​

A CISA adicionou em 26 de outubro as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell, ao seu catálogo de vulnerabilidades exploradas conhecidas (KEV).

São vulnerabilidades do próprio PHP que, sob determinadas condições, podem permitir execução remota de código (RCE) sem autenticação.

Além da inclusão no KEV, já foi observada atividade tentando explorá-las e existem provas de exploração com RCE bem-sucedido em honeypots.

Quais versões estão corrigidas?​

As atualizações do PHP que resolvem o problema foram publicadas em 21 de outubro.

Para as branches atuais:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Se vocês usam versões fornecidas pela sua distribuição Linux, painel de controle ou provedor de hospedagem, confiram também os avisos deles, já que podem aplicar seus próprios patches ou backports.

Por exemplo, o Plesk já publicou atualizações específicas para as versões de PHP que distribui.

Não é um problema exclusivo do WordPress​

Isto não é uma vulnerabilidade do WordPress nem de um CMS específico, e sim do PHP.

Portanto, pode afetar servidores que tenham WordPress, Joomla, Drupal, scripts próprios ou outras aplicações PHP, desde que estejam usando uma versão vulnerável e existam as condições necessárias para explorá-la.

Se vocês administram o seu próprio VPS ou servidor, eu verificaria qual versão do PHP está rodando e atualizaria o quanto antes se estiver afetada.

Ter firewall, fechar portas que não usamos etc. ajuda, mas não substitui as atualizações de segurança do próprio PHP.

Quantos servidores podem estar expostos?​

A Censys criou um tracker específico para o PHP2Shell usando seus escaneamentos da Internet:

https://php2shell.censys.com/

Ele permite ver a evolução das versões de PHP observadas na Internet, hosts potencialmente afetados, países, redes etc.

Importante: o fato de a Censys detectar uma versão aparentemente vulnerável não significa automaticamente que esse servidor seja explorável. Pode existir um patch aplicado pelo provedor ou pela distribuição sem mudar o número da versão, e também depende da configuração do servidor.

Para quem tiver curiosidade sobre infraestrutura e dispositivos expostos na Internet, também existe o dashboard da Shadowserver:

https://dashboard.shadowserver.org/

Ali é possível consultar estatísticas de serviços e dispositivos expostos, vulnerabilidades observadas, fabricantes, modelos, países etc.

Fontes​

CISA KEV:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Censys - PHP2Shell Exposure Tracker:
https://php2shell.censys.com/

Shadowserver Dashboard:
https://dashboard.shadowserver.org/

Plesk - CVE-2026-109618 / CVE-2026-109619:
https://support.plesk.com/hc/en-us/...mote-code-execution-in-PHP-shipped-with-Plesk

The Record - PHP vulnerabilities adicionadas ao KEV:
https://therecord.media/php-vulnerabilities-cisa-kev

Se vocês têm um VPS administrado por vocês mesmos, eu daria uma olhada na versão do PHP que vocês têm instalada, por via das dúvidas.

Clique para expandir...

Nossa, e eu pensando que era WordPress!! XDDDDDDDD já estava até criando à parte um site em Node.js, ali praticando, e o nosso amigo @CARLOS Frías mostrou também que o Node.js também tem suas fraquezas :v kkk