Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
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
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 -lntpDepois 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 = OffEm 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] = offNã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 |
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=trueVerifique 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:
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_registeredOs 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
- PHP: avisos de 21 e 23 de outubro, versões e condições
- PHP: CVE-2026-109618, OOM e limites da mitigação
- PHP: CVE-2026-109619, ciclo de vida e auditoria
- PHP-FPM: configuração administrativa de pools
- Node.js: dez avisos, ramos e downloads corrigidos
- Docker: recriação de serviços com Compose
- Oracle: CPU de outubro e matriz do Java SE
- Oracle: alerta de 21 de outubro, intermediárias
- Oracle: alerta de 24 de outubro, raízes
- Oracle: builds e baseline de 24 de outubro
- Oracle: requisitos e comandos do jcmd
- Oracle: repositórios de confiança, alternativas e CheckCerts
- WordPress: documentação oficial do WP-CLI
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
