[INCIDENTE GRAVE] PHP2Shell, Node.js e Java: o que as manchetes não contam e como verificar o patch

Carlos Frias · Ontem às 13:46

Uma semana, três frentes de segurança
PHP2Shell · Node.js · Java
Diagnóstico, mitigação e verificação · Data de corte: 25 de outubro de 2026

Passei dois dias intervindo em servidores da minha empresa e de clientes por causa do PHP2Shell; somaram-se os avisos de Node.js e Java. Encontrei um problema repetido: instalar uma atualização e dar um serviço por encerrado sem verificar o que continua em execução.

Este guia cobre hospedagem compartilhada, VPS, painéis, contêineres e aplicações Java: diagnóstico, mitigações, correção e evidências para informar o cliente.

Por que trato isso como incidente grave: coincidem falhas graves em runtimes muito utilizados. É uma prioridade operacional; não implica um exploit compartilhado, gravidade idêntica nem comprometimento de qualquer servidor.

Leitura: hospedagem compartilhada, seção 8; administradores, inventário e frente correspondente. Identifique serviço, conta e runtime antes de agir. Não teste exploits em produção.

1. O mapa do que aconteceu

Frente	O que revisar	Objetivo
PHP2Shell	PHP de cada site	Patch e workers renovados
Node.js	Runtime e decodificação	Versão corrigida em cada aplicação
Java	JDK/JRE e confiança TLS	Build e truststore efetivos

Em 20 de outubro a Oracle publicou sua atualização trimestral. No dia 21 chegaram as correções principais de PHP e Node.js, e outro alerta da Oracle sobre certificados. No dia 23 o PHP acrescentou um aviso específico sobre sessões. No dia 24 a Oracle publicou outro alerta de certificados. Essa sequência importa: uma revisão feita no dia 21 pode precisar de verificações adicionais no dia 25.

2. O que as manchetes não contam

Pacote novo não equivale a processo renovado. Vi executáveis atualizados com processos anteriores em memória. Verifique caminhos e inicialização depois de renovar os afetados.

O console pode mostrar outro runtime. Cruze domínio ou serviço → processo → executável → pacote ou imagem → revisão corrigida. Inclua instalações privadas, por usuário e contêineres.

Um backport pode manter o número base. No CloudLinux e em outras distribuições, compare a revisão com o aviso do fabricante; PHP_VERSION sozinho não demonstra correção nem vulnerabilidade.

O WAF filtra determinadas requisições. Não comprova o patch, não garante cobrir todas as vias e não elimina persistência prévia.

«Não encontrei indícios» tem alcance. Documente datas, registros e sistemas revisados; isso não equivale a demonstrar que nunca aconteceu nada.

3. Primeiro: saber o que você executa

Guarde um retrato de sites e serviços, configuração, backups e recuperação viável. Anote o horário. Se houver indícios de intrusão, preserve registros e arquivos antes de modificá-los.

No Linux, um primeiro inventário de processos sem despejar argumentos completos:

Bash:

ps -eo pid,user,lstart,comm
ss -lntp

Depois identifique o PID que realmente atende o serviço. Este bloco pede um, valida que seja numérico e apenas consulta:

Bash:

read -r -p 'PID del proceso que vas a revisar: ' runtime_pid
case "$runtime_pid" in
  ''|*[!0-9]*) printf '%s\n' 'PID inválido'; exit 1 ;;
esac
readlink "/proc/$runtime_pid/exe"
ps -p "$runtime_pid" -o pid,user,lstart,comm

«(deleted)» após atualizar pode indicar um executável anterior ainda em uso; sua ausência não certifica o patch. Revise bibliotecas e resolva os caminhos no namespace real do processo.

Não publique saídas com dados de clientes ou infraestrutura privada.

4. PHP2Shell: patch e configuração

CVE-2026-109618 e CVE-2026-109619 afetam o gerenciamento de memória e o estado das requisições. Correções iniciais: 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Compare os backports do fornecedor; para ramos antigos, exija cobertura explícita ou migre para um ramo com suporte. [1][2][3]

Verifique o PHP de cada domínio, não só «php -v». Um diagnóstico mínimo, colocado apenas em um acesso privado e restrito da aplicação, pode mostrar o contexto de uma requisição:

PHP:

<?php
header('Content-Type: application/json; charset=utf-8');
echo json_encode([
    'version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
    'binario' => PHP_BINARY,
    'ini' => php_ini_loaded_file(),
    'pid' => getmypid(),
], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);

Não mostra automaticamente a revisão RPM nem comprova todos os workers. Evite exposição ao terminar e verifique cada nó, pool e réplica.

Como exemplo para FPM do EasyApache, PHP 8.3, o administrador pode identificar o pacote do executável e consultar seu histórico:

Bash:

rpm -qf /opt/cpanel/ea-php83/root/usr/sbin/php-fpm
rpm -q --changelog ea-php83-php-fpm | grep -E 'CVE-2026-(109618|109619)'

Adapte binário e pacote ao LiteSpeed, alt-php ou à sua distribuição. Um grep sem correspondências exige comparar revisão e aviso; não dá um veredito. Com painel, use primeiro os mecanismos oficiais dele.

Se você ainda não pode aplicar o patch: as medidas do advisory reduzem vias concretas; não há um bloco de configuração que substitua a correção completa. No php.ini, aplicado antes de processar requisições:

INI:

session.upload_progress.enabled = Off

; Solo para PHP 8.5
fatal_error_backtraces = Off

Em um pool FPM a sintaxe administrativa é diferente:

INI:

php_admin_flag[session.upload_progress.enabled] = off

; Solo para pools de PHP 8.5
php_admin_flag[fatal_error_backtraces] = off

Não confie em .user.ini nem em ini_set() para um caminho anterior ao script. Guarde a configuração, valide com o FPM correto, reinicie os workers e verifique. Desativar o progresso de upload pode afetar quem o utiliza. [2][3][4]

memory_limit = -1 é temporário. Elimina o limite controlável do PHP, não todas as falhas de alocação; pode esgotar recursos. RLIMIT_AS/DATA podem provocar a rota vulnerável e não servem como substitutos. Com cgroups, verifique o que um OOM mataria: agrupar master e workers pode derrubar o serviço. Não assuma que «LVE/cgroups» basta. [2]

Limite entradas no frontend de acordo com o advisory e a aplicação. Bloquear multipart quebra os uploads que precisem dele; não substitui atualizar.

Aviso do dia 23: manter desativado o progresso de upload cobre outro cenário, CVE-2026-115560: trocar o serializador php_binary/php_serialize para php durante a execução antes de session_start(), com essa função ativa. Consulte condições e a próxima correção. [1]

5. Node.js: npm update não basta

Releases corrigidas: 22.23.4, 24.22.1 e 26.12.1, conforme o ramo. Valide compatibilidade; não pule de ramo principal às cegas. Se estiver fora de suporte, planeje migração e cobertura. [5]

CVE-2026-111497, HIGH: Brotli malformado que a aplicação descomprime com node:zlib pode corromper a memória, com possível queda, vazamento ou execução de código. Revise entradas e respostas externas que cheguem a esse decodificador. Não implica RCE automático em todo Node exposto. [5]

CVE-2026-	Área	Ramos
105482	DNS e NUL	22/24/26
105483	Validação TLS	24/26
106069	IP não canônico e TLS	22/24/26
106072	SAN DNS versus IP	22/24/26
105481	Resposta HTTP e keep-alive	22/24/26
106074	Entropia em snapshots/SEA	22/24/26
106070	Validação ZIP	26
106071	Permissões e curingas	26
106073	Permissões e realpathSync	22/24/26

Consulte condições e gravidade individual no aviso: os dez problemas não afetam igualmente todos os ramos nem todas as aplicações. As releases também atualizam dependências e certificados. [5]

Para identificar o Node que o seu console invoca:

Bash:

node -p 'JSON.stringify({version:process.version,exe:process.execPath,openssl:process.versions.openssl},null,2)'

A consulta anterior não interroga sua aplicação em execução: cruze-a com PID, usuário, serviço e interpretador. npm update não substitui o Node. O nvm pode deixar caminhos antigos fixados; com PM2, revise e renove a aplicação específica, não todos os clientes.

Correção: faça backup e teste a compatibilidade; instale a release corrigida pelo canal oficial; atualize o caminho persistente, reconstrua e renove os processos; verifique runtime e funcionamento. Reconstrua também snapshots e executáveis SEA: atualizar o host não modifica esses artefatos.

Enquanto você atualiza: evite que Brotli não confiável chegue ao decodificador vulnerável, incluindo respostas externas. Desativar a compressão de saída no nginx não desativa a descompressão dentro do Node. Tamanhos máximos e WAF não corrigem corrupção de memória. Não desative a validação TLS para consertar conexões.

6. Docker: o host não é o contêiner

Um inventário inicial, com as permissões do ambiente:

Bash:

docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}'
read -r -p 'Nombre del contenedor Node que vas a consultar: ' runtime_container
docker exec "$runtime_container" node -p 'process.version + " | " + process.execPath'
docker inspect --format '{{.Id}} {{.Image}}' "$runtime_container"

docker exec cria outro processo: mostra o runtime disponível, não o que continua carregado na aplicação antiga. Verifique também o processo principal.

Corrija a imagem e o deploy: atualize a base ou a imagem do fabricante, reconstrua se for própria e recrie o serviço. Um docker cp pode se perder ao recriá-lo; reiniciar mantém a imagem anterior.

Com Compose, depois de fixar e revisar a imagem corrigida no arquivo do projeto, um exemplo limitado a um serviço é:

Bash:

read -r -p 'Servicio Compose que vas a actualizar: ' runtime_service
docker compose pull "$runtime_service"
docker compose up -d --no-deps "$runtime_service"

Verifique cada passo antes de continuar. O exemplo usa imagem publicada; uma própria exige reconstrução. Revise volumes, compatibilidade, segredos e recuperação. No Swarm/Kubernetes, revise todas as réplicas com seu deploy declarativo. Não faça purge de imagens nem de volumes. [6]

7. Java: build, JVM e confiança TLS

Aqui é preciso distinguir três publicações. O CPU da Oracle de 20 de outubro incorpora 55 patches de Java SE; sua matriz aponta 49 vulnerabilidades potencialmente exploráveis pela rede sem autenticação, sob suas respectivas condições. Não são 49 RCE universais contra qualquer Spring ou Tomcat. [7]

No dia 21 a Oracle publicou o CVE-2026-91403 para retirar a confiança de intermediárias relacionadas à eMudhra. No dia 24 publicou o CVE-2026-114820 para retirar determinadas raízes de confiança. São alertas de JSSE/TLS, com impacto em confidencialidade e integridade; eu não os descreveria como uma webshell remota em cada JVM. [8][9]

A armadilha do número curto: 21.0.13 fez parte do CPU, mas depois houve revisões adicionais. Para o Oracle JDK, a baseline publicada no dia 24 é:

Família	Build Oracle de 24/10
8	1.8.0_511-b33
11	11.0.33.0.3+1
17	17.0.21.0.3+1
21	21.0.13.0.3+1
25	25.0.5.0.3+1

Estas builds são da Oracle: Temurin, Corretto, Zulu e as distribuições têm revisões e prazos próprios. Compare fornecedor e plataforma; para GraalVM ou outra família, a matriz correspondente. Valide compatibilidade e licença. [10]

Pelo console:

Bash:

java -version
read -r -p 'PID de la JVM de la aplicación: ' runtime_java_pid
jcmd "$runtime_java_pid" VM.version
jcmd "$runtime_java_pid" VM.system_properties | grep -E '^(java.home|javax.net.ssl.trustStore|javax.net.ssl.trustStoreType)='

O jcmd exige o contexto e as permissões adequadas, normalmente o mesmo usuário efetivo e um JDK compatível; resolva namespaces em contêineres. Um attach que falha não é evidência de segurança. Não publique todas as propriedades. [11]

Verifique o truststore efetivo. Pode ser o cacerts, um privado via javax.net.ssl.trustStore ou uma configuração da biblioteca. Atualizar o JDK não altera necessariamente uma cópia privada. A propriedade não aparecer não prova o que cada biblioteca usa.

A correção preferencial é a build atualizada do fornecedor, revisar os repositórios privados e reiniciar as JVMs que os usam. Se você ainda não pode instalá-la, a Oracle documenta opções temporárias: cópia do keystore antes de retirar as raízes indicadas, ou verificação de revogação. Não apague todas as CAs nem desative a verificação de certificados para resolver um erro TLS. [12]

Para aplicações TLS em que caiba a alternativa oficial de revogação, as propriedades de inicialização são:

Inserir CODE, HTML ou PHP:

-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=true

Verifique se a aplicação aplica essa política, alcança os serviços de revogação e mantém as conexões legítimas. Não corrige o restante do CPU. A Oracle oferece o CheckCerts.java: revise o programa oficial antes de executá-lo e verifique cada runtime e repositório. [12]

8. Se você está em hospedagem compartilhada

Peça evidências referentes à sua conta e ao seu nó. Você pode adaptar este texto:

Preciso confirmar a correção das vulnerabilidades aplicáveis ao runtime que executa meu domínio ou aplicação. Por favor, informem o ramo e o handler, o nome e a revisão completa do pacote ou build, a referência oficial que comprova a correção e a renovação dos seus processos. Se houver backport, preciso da revisão do fornecedor, não só do número base. Para Java, confirmem também os avisos de certificados de 21 e 24 de outubro e o truststore utilizado. Se alguma medida continuar sendo temporária, informem o seu alcance e o próximo passo.

Não peça dados de outros clientes. Não mude todos os sites de ramo principal sem verificar compatibilidade nem declare vulnerável um backport pela sua versão base.

9. A parte forense: procurar uma intrusão prévia

O patch não elimina uma intrusão anterior. Trabalhe com linha do tempo, originais preservados, horário, fuso e cobertura de cada fonte.

Requisições e WAF: data, caminho, método, regra, resposta e corpo disponível. Um 403 comprova essa rejeição, não todas as tentativas. Um 200 pode ser a página inicial normal; é preciso seguir a evidência.
Processos e erros: quedas, erros de memória, filhos inesperados e conexões novas. Não atribua um crash ao exploit sem correlação e diagnóstico.
Arquivos: alterações e proprietários comparados com deploys e fontes confiáveis. Um plugin atualizado hoje ou uma assinatura de antivírus que contém código suspeito não são automaticamente malware.
Persistência: crons, timers, unidades, chaves autorizadas, tarefas da aplicação e inicializações de contêineres. Compare com o estado conhecido, sem apagar por heurística.
Acessos e segredos: administradores, senhas de aplicação e alterações de permissões. Se houver comprometimento, contenha e limpe a causa antes de trocar credenciais a partir de um ambiente confiável.

Para um WordPress, com a conta dele e a partir da sua pasta, uma verificação limitada útil é:

Bash:

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_registered

Os checksums precisam de referência de versão e procedência: um plugin comercial pode não tê-la. Analise arquivos adicionais; estes comandos não auditam o host. [13]

Na minha intervenção não encontrei evidência de exploração bem-sucedida no que foi revisado. Reservo as identidades e os dados dos clientes: o útil é o método e as provas.

10. Quando dar o trabalho por concluído

Inventário de domínios, serviços, runtimes privados, contêineres e réplicas reconciliado.
Versão completa ou backport comparado com o fabricante; downloads e assinaturas verificados pelo procedimento dele.
Processos renovados e inicializações persistentes apontando para o runtime previsto.
Configuração efetiva verificada, incluindo sessões PHP e repositórios TLS do Java quando se aplicarem.
Testes funcionais dos sites e aplicações: login, upload, tarefas, API e conexões externas pertinentes.
Revisão de indícios com datas e limites documentados; erros prévios separados das alterações introduzidas.
Backup recuperável e plano de reversão preservados. Uma mitigação pendente continua constando como pendente.

Se algo falhar após atualizar, diagnostique a incompatibilidade. Não desative controles nem volte silenciosamente a uma versão vulnerável; avalie isolamento e uma alternativa controlada.

Atualizar, mitigar e verificar são trabalhos diferentes. Quando os três são documentados, dá para informar o cliente com algo mais sólido do que um print do painel.

Fontes primárias e documentação

Informações verificadas em 25 de outubro de 2026. As novas releases e revisões dos fabricantes podem mudar as recomendações; guarde sempre a referência e a data da sua verificação.

Até a próxima 🙂

CF

Plaga · Ontem às 14:49

Muito obrigado por esta contribuição tão detalhada e técnica. Você tem toda a razão ao apontar que a vulnerabilidade do Node.js não recebeu a mesma divulgação que a do PHP; na verdade, essa nem passou pela minha cabeça. De qualquer forma, vou dar uma revisada nos meus serviços por pura precaução.

insomniaw · Hoje às 00:03

Muito obrigado, uma info excelente.

[INCIDENTE GRAVE] PHP2Shell, Node.js e Java: o que as manchetes não contam e como verificar o patch

Carlos Frias

Plaga

insomniaw