ShinyHunters explora zero-day Oracle PeopleSoft, 100+ vítimas

A Oracle publicou o aviso de segurança do CVE-2026-35273 em 10 de junho. O problema: o ShinyHunters estava explorando a falha desde 27 de maio. Catorze dias de exploração ativa sem patch, sem aviso público, sem chance real de defesa para quem rodava PeopleSoft exposto à internet.

O que é o Oracle PeopleSoft e por que tantas universidades foram atingidas

PeopleSoft é um conjunto de aplicações empresariais da Oracle amplamente usado por universidades e grandes corporações para gerenciar RH, finanças, matrículas, folha de pagamento e registros acadêmicos. É o sistema que guarda dados pessoais, notas e informações financeiras de estudantes — exatamente o tipo de dado que o ShinyHunters coloca à venda.

A concentração no ensino superior não é coincidência: 68% das mais de 300 instâncias vulneráveis identificadas durante a campanha estavam em universidades, a maioria nos Estados Unidos. Instituições de ensino costumam manter sistemas legados com ciclos lentos de atualização — um ambiente ideal para exploração de zero-days com CVSS 9.8.

Como funciona o CVE-2026-35273

A falha está no componente Environment Management Hub (PSEMHUB), responsável por gerenciar atualizações dentro do PeopleSoft Enterprise PeopleTools. Com pontuação máxima de 9.8 no CVSS, ela permite execução remota de código sem autenticação e sem interação do usuário — basta acesso de rede via HTTP para comprometer o servidor.

O Mandiant (Google Cloud), que rastreia o grupo como UNC6240, descreve o ataque como uma gadget chain: uma sequência que encadeia o CVE-2026-35273 com vulnerabilidades mais antigas e já conhecidas. Isoladas, essas falhas seriam difíceis de explorar; encadeadas, abrem caminho direto para execução de código no servidor sem nenhuma credencial. É a mesma lógica de encadeamento de vulnerabilidades que vimos em incidentes anteriores de supply chain — a novidade aqui é a escala e a velocidade.

A campanha: 14 dias de zero-day, 100+ organizações

Segundo o Mandiant, a atividade foi registrada entre 27 de maio e 9 de junho de 2026. Mais de 100 organizações foram comprometidas, com cerca de 300 instâncias vulneráveis identificadas no total. A University of Nottingham confirmou publicamente a invasão ao seu sistema PeopleSoft, com roubo de 40 GB de dados pessoais e registros financeiros de centenas de milhares de estudantes ativos e ex-alunos.

A Oracle emitiu um patch fora do ciclo normal apenas em 10 de junho — um dia depois do período de exploração documentado ter encerrado. Para quem já estava comprometido, a correção chegou tarde demais.

É o terceiro grande incidente atribuído ao ShinyHunters em poucas semanas. Antes disso, o grupo foi responsável pelo vazamento de 275 milhões de registros do Canvas LMS e pelo breach na Carnival Corporation afetando 6 milhões de passageiros. O padrão é consistente: alvos com grandes bases de dados pessoais e ciclos de patch lentos.

O que acontece depois da invasão

Uma vez dentro do servidor, o script de pós-exploração [vítima]_fanout.sh entra em ação. Ele lê o arquivo /etc/hosts para mapear hosts internos da rede, tenta movimentação lateral via SSH usando listas de usuários e senhas hardcoded, e deposita um arquivo chamado README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT nos diretórios do PeopleSoft — uma marcação que indica comprometimento confirmado e facilita o rastreamento das instâncias invadidas.

A movimentação lateral via SSH é o ponto mais crítico: uma vez que o atacante sai do servidor PeopleSoft para a rede interna, o alcance do dano cresce rapidamente. Vale revisar as políticas de hardening SSH nos servidores Linux — acesso entre hosts internos sem restrição é um vetor que nunca some da lista de riscos, independente do vetor inicial.

O problema estrutural: zero-day não respeita calendário de patch

O que chama atenção neste caso é menos a sofisticação do ataque e mais o timing da resposta. A Oracle seguiu seu ciclo habitual — o problema é que catorze dias de zero-day ativo resultam em mais de 100 organizações comprometidas antes de qualquer aviso público.

O cenário repete uma lógica já vista antes: o MoVEIT Transfer em 2023 seguiu o mesmo padrão — exploit disponível, exploração em massa antes do patch, dano irreversível acumulado durante a janela de zero-day. Três anos depois, a dinâmica continua a mesma. A diferença agora é que grupos como o ShinyHunters operam em escala industrial, com scripts prontos para varredura e pós-exploração automatizada.

O que fazer se você gerencia PeopleSoft

Se você administra instâncias Oracle PeopleSoft em produção, as ações imediatas são:

• Aplicar o patch publicado pela Oracle em 10 de junho — fora do ciclo normal de CPU (Critical Patch Update)
• Verificar logs de acesso ao PSEMHUB entre 27 de maio e 10 de junho em busca de requisições HTTP não autenticadas anômalas
• Procurar pelo arquivo README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT nos diretórios PeopleSoft — sua presença confirma comprometimento
• Auditar conexões SSH originadas do servidor PeopleSoft no mesmo período, especialmente para hosts internos
• Segmentar o servidor PeopleSoft da rede interna onde possível, restringindo saída SSH não autorizada por firewall ou ACL

Organizações que encontrarem o arquivo README devem tratar a situação como breach confirmado e acionar o processo de resposta a incidentes. No Brasil, a LGPD exige notificação à ANPD e aos titulares em caso de incidente de segurança com risco relevante — o prazo começa a contar a partir da ciência do evento, não da data da exploração.

Se você identificou atividade suspeita nos seus sistemas ou já aplicou o patch, conta nos comentários como foi o processo. E se sua organização usa PeopleSoft e ainda não validou os logs desse período, esse é um bom momento para começar.