O bypass de WAF do ShinyHunters no Oracle PeopleSoft é um lembrete de que uma regra de firewall não é a mesma coisa que uma correção. De acordo com reportagem do BleepingComputer, o grupo de extorsão está usando um truque de codificação de URL para contornar regras de web application firewall (WAF) que deveriam mitigar a falha do Oracle PeopleSoft rastreada como CVE-2026-35273. O resultado: os atacantes conseguiram retomar a exploração generalizada de servidores vulneráveis.

Para organizações que se apoiaram em uma regra de WAF como sua principal defesa, este é um momento de reavaliar.

Como o truque de codificação de URL passa pelas regras de WAF

Um WAF fica na frente de uma aplicação web e inspeciona as requisições recebidas. Muitas mitigações para uma falha recém-divulgada funcionam correspondendo a um padrão malicioso conhecido em uma requisição, como um caminho ou string específico, e bloqueando-o.

A codificação de URL é uma forma padrão de representar caracteres em um endereço web, por exemplo, escrevendo um caractere como um sinal de porcentagem seguido por um código. Os servidores web decodificam esses valores antes de processá-los. Isso cria uma lacuna: se a regra do WAF procura o padrão literal, mas a aplicação entende uma versão codificada da mesma requisição, os dois podem interpretar o tráfego de forma diferente. Segundo o relatório, é esse tipo de diferença que o ShinyHunters está explorando para passar pelas regras de WAF voltadas ao PeopleSoft.

O artigo original não publica detalhes técnicos completos das requisições codificadas, e não vamos especular além do que foi reportado. O que importa para os defensores é o princípio. Um bloqueio baseado em assinatura de uma forma de requisição maliciosa frequentemente pode ser contornado apresentando essa requisição de uma forma diferente, mas equivalente.

Pesquisadores terceiros que acompanham a campanha descreveram execução remota de código não autenticada no Oracle PeopleSoft PeopleTools e implantação de web shell em sistemas não corrigidos. Mandiant e Google Threat Intelligence Group também foram citados como identificadores da exploração renovada. Se essas descrições se confirmarem, uma requisição bem-sucedida não apenas vaza um registro; ela pode dar ao atacante um ponto de apoio no servidor.

Por que um WAF é uma medida paliativa, não um patch para CVE-2026-35273

Regras de WAF são frequentemente chamadas de patches virtuais, e têm um papel real. Quando uma correção do fornecedor ainda não está disponível ou não pode ser implantada imediatamente, uma regra pode reduzir a exposição enquanto as equipes preparam uma atualização adequada.

Mas um patch virtual protege a porta, não o ambiente atrás dela. O código vulnerável ainda está presente no servidor. Qualquer um que encontre um formato de requisição que o WAF não reconhece pode alcançá-lo. É exatamente essa a situação descrita aqui.

Um patch real altera o próprio comportamento vulnerável, então não depende de como uma requisição é escrita ou codificada. É por isso que a orientação em casos como este é consistente: aplique a correção do fornecedor e trate qualquer regra de WAF como uma medida temporária que ganha tempo em vez de encerrar o problema.

Há também uma lição de processo. Se o seu registro de riscos lista uma vulnerabilidade como "mitigada" porque existe uma regra de WAF, esse status pode estar superestimado. Considere marcar tais itens como "controle compensatório em vigor, patch pendente" para que permaneçam visíveis até que a correção seja aplicada.

O que o modelo de extorsão do ShinyHunters significa para organizações expostas

O ShinyHunters é conhecido como um grupo de extorsão, o que molda o risco. O objetivo normalmente é obter dados sensíveis ou acesso, e então pressionar a vítima a pagar. O PeopleSoft frequentemente sustenta sistemas de recursos humanos, folha de pagamento e sistemas estudantis, que guardam exatamente o tipo de registros que dão alavancagem aos extorsionistas.

A atividade anterior do grupo oferece um panorama de como isso se desenrola. No vazamento de dados do Udemy ligado ao ShinyHunters, o grupo reivindicou responsabilidade por uma violação da plataforma de aprendizado online, ilustrando um padrão de atacar organizações que detêm grandes volumes de dados de usuários.

A implicação prática é que a exposição não se limita ao momento da intrusão. Mesmo depois que um servidor é limpo, os dados roubados podem ser usados para pressão, e uma web shell deixada para trás pode permitir a reentrada. Organizações que executam PeopleSoft exposto à internet devem pensar em termos de prevenção e avaliação de comprometimento.

O que isso significa para você

Se você executa Oracle PeopleSoft, particularmente com componentes expostos à internet, o ponto-chave é simples: não assuma que seu WAF cobre você para o CVE-2026-35273. Os atacantes demonstraram que conseguem contornar essas regras.

Se você é estudante, funcionário ou cliente de uma organização que usa PeopleSoft, você não pode corrigir o servidor por conta própria, mas pode limitar as consequências se os dados forem expostos. Fique atento a e-mails ou mensagens inesperadas que façam referência à sua conta, já que campanhas de extorsão frequentemente levam a phishing. Use senhas únicas e ative a autenticação multifator onde for oferecida. As descobertas do State of Ransomware 2026 são um lembrete útil de que logins roubados e phishing continuam sendo as principais formas de os atacantes entrarem, então a higiene de contas ainda importa mesmo quando a violação inicial não é culpa sua.

Passos práticos: correção, defesas em camadas e monitoramento

Para equipes de TI e segurança, uma ordem sensata de operações é assim:

  • Corrija primeiro. Aplique a correção da Oracle para o CVE-2026-35273 em todas as instâncias afetadas do PeopleSoft o mais rápido que seu processo de mudança permitir.
  • Mantenha o WAF, mas não dependa dele. Atualize as regras onde puder, e considere normalizar ou decodificar requisições antes da inspeção, mas trate isso como uma camada de apoio.
  • Reduza a exposição. Restrinja o acesso ao PeopleSoft para que apenas os componentes que realmente precisam de acesso à internet o tenham.
  • Procure sinais de comprometimento. Como web shells foram reportadas em sistemas não corrigidos, revise os servidores em busca de arquivos inesperados, processos incomuns e conexões de saída estranhas, especialmente se você ficou sem correção em algum momento.
  • Monitore e registre. Mantenha logs detalhados de web e servidor para que você possa investigar após o fato.
  • Prepare um plano de incidentes. Saiba quem decide, quem comunica e como você responderia a uma exigência de extorsão.

A conclusão

O bypass de WAF do ShinyHunters no Oracle PeopleSoft mostra quão rapidamente uma medida paliativa pode falhar quando os atacantes estão motivados. Corrija o PeopleSoft prontamente, trate seu WAF como uma camada entre várias, e verifique sinais de comprometimento em tudo que esteve exposto. Para uma visão do histórico do grupo, leia nossa cobertura do vazamento do Udemy pelo ShinyHunters, e para contexto mais amplo sobre como os atacantes entram nas redes, veja o relatório de ransomware 2026 linkado acima.

FAQ: Q1: O que é o bypass de WAF do ShinyHunters no Oracle PeopleSoft? A1: O ShinyHunters está usando um truque de codificação de URL para contornar regras de WAF que deveriam mitigar a falha do Oracle PeopleSoft rastreada como CVE-2026-35273, permitindo que retomem a exploração generalizada de servidores vulneráveis. Q2: Como o truque de codificação de URL contorna as regras de WAF? A2: Se uma regra de WAF procura o padrão literal de uma requisição maliciosa, mas a aplicação entende uma versão codificada da mesma requisição, os dois podem interpretar o tráfego de forma diferente, permitindo que os atacantes passem pela regra. Q3: Por que uma regra de WAF não é uma correção real para o CVE-2026-35273? A3: Uma regra de WAF é um patch virtual que protege a porta, não o ambiente atrás dela — o código vulnerável ainda está presente no servidor, então qualquer um que encontre um formato de requisição que o WAF não reconhece pode alcançá-lo. Q4: O que um patch real faz de diferente de uma regra de WAF? A4: Um patch real altera o próprio comportamento vulnerável, então não depende de como uma requisição é escrita ou codificada. Q5: O que os pesquisadores observaram nesta campanha? A5: Pesquisadores terceiros descreveram execução remota de código não autenticada no Oracle PeopleSoft PeopleTools e implantação de web shell em sistemas não corrigidos, com Mandiant e Google Threat Intelligence Group citados como identificadores da exploração renovada.

---END---