O zero-day do Oracle PeopleSoft explorado pelo ShinyHunters eram afinal três falhas encadeadas

A vulnerabilidade crítica no Oracle PeopleSoft que o grupo de extorsão ShinyHunters tem vindo a abusar desde o final de maio não é um único bug. Os detalhes técnicos agora disponíveis mostram que a CVE-2026-35273, o identificador que a Oracle usou ao publicar a correção de emergência a 10 de junho, abrange três fragilidades distintas em dois componentes do PeopleSoft. Encadeadas, permitem a um atacante sem credenciais executar comandos no servidor.

Estão a ser atribuídos identificadores CVE separados para cada falha, mas, por agora, o de junho continua a ser o único registado. As equipas que acompanham "uma só CVE" devem perceber que lidam, na verdade, com uma cadeia.

O que aconteceu

A CVE-2026-35273 afeta o PeopleSoft PeopleTools 8.61 e 8.62, tem uma pontuação CVSS de 9,8 e permite tomar o controlo do servidor através da rede sem autenticação. A Oracle corrigiu-a num alerta de segurança fora do ciclo habitual, a 10 de junho, e a falha consta agora do catálogo de vulnerabilidades exploradas conhecidas (KEV) da CISA.

A correção chegou tarde para as primeiras vítimas. A atividade atribuída ao ShinyHunters (também seguido como UNC6240) explorou a falha entre 27 de maio e 9 de junho, sobretudo contra universidades. Como antecedeu o aviso da Oracle, foi um verdadeiro zero-day durante toda essa janela. Uma segunda vaga, maior, em setembro, foi além do ensino e atingiu tecnologia, serviços de TI, saúde, agricultura, transportes e administração pública, afetando dezenas de sistemas em todo o mundo.

Como funciona a cadeia

Estão envolvidas duas aplicações web. O Integration Gateway (PSIGW) troca mensagens com sistemas externos e foi concebido para ser acessível. O Environment Management Hub (PSEMHUB) é uma interface interna de administração que só deveria responder a anfitriões de confiança.

1. Server-side request forgery no gateway. O conector de escuta do PSIGW aceita um pedido e reencaminha-o, e quem o envia controla tanto o endereço de destino como todo o conteúdo. Nada verifica se o destino é legítimo.
2. Uma predefinição que confia no loopback. O PSEMHUB decide em quem confiar comparando o requerente com uma lista no ficheiro allowedhosts.properties. Esse ficheiro vem de origem com o 127.0.0.1 já incluído. Basta apontar o SSRF ao endereço local de loopback para que o pedido pareça vir da própria máquina: a verificação passa e o hub "interno" fica subitamente acessível a partir da internet.
3. Escrita arbitrária de ficheiros no hub. Com o hub acessível, um comando pensado para escrever entradas de registo permite ao requerente escolher tanto o conteúdo do ficheiro como o caminho exato no disco.

A partir daí, duas rotas levam à execução de código. A direta deixa uma web shell no diretório da aplicação e executa comandos com a conta de serviço do PeopleSoft. A discreta escreve um ficheiro XML malicioso que o hub interpreta com o XMLDecoder do Java no próximo arranque do serviço, executando o código do atacante no reinício sem deixar qualquer web shell para trás. Essa via alternativa dá muito menos para detetar aos mecanismos habituais.

Porque é que importa

A lição central é de conceção: uma verificação de confiança baseada no IP de origem não vale nada assim que existe um SSRF no mesmo anfitrião, e a entrada de loopback na lista predefinida tornou-a inútil desde o primeiro dia. As organizações que assumiram que uma firewall à frente do PSEMHUB as protegia enganaram-se, porque o pedido hostil chega de dentro.

A vaga de setembro mostrou também como o "patch virtual" é frágil. As regras de web application firewall que bloqueavam o caminho literal /PSEMHUB/ foram contornadas codificando em URL um único carácter e pedindo /%50SEMHUB/. Muitas assinaturas de WAF comparam o texto literal, enquanto o servidor PeopleSoft o descodifica sem problemas e serve a página.

Por fim, o modo de atuação do ShinyHunters é roubo de dados seguido de um pedido de pagamento, pelo que um anfitrião PeopleSoft comprometido é uma violação de dados com nota de extorsão, e não apenas um problema de disponibilidade.

O que fazer

• Aplique o patch. Instale a correção do alerta de segurança da Oracle para a CVE-2026-35273 e mantenha-se numa versão suportada do PeopleTools. O bloqueio de caminhos na WAF não substitui o patch.
• Se não puder aplicar o patch de imediato, desative o serviço Environment Management Hub em instalações multi-servidor ou remova a aplicação PSEMHUB em instalações de servidor único. Restringir estes endpoints de administração não interrompe as sessões dos utilizadores.
• Procure a via discreta. Verifique se existem ficheiros JSP inesperados no diretório web do PSEMHUB e ficheiros XML inesperados ou alterados recentemente na pasta de metadados do ambiente, onde fica a carga de execução diferida.
• Se já puder estar comprometido, trate qualquer anfitrião com web shell como totalmente comprometido, preserve as evidências e rode todas as credenciais alcançáveis a partir da camada PeopleSoft: contas de base de dados, credenciais de integração, contas de serviço e chaves API armazenadas. Prepare-se para uma tentativa de extorsão.
• Não assuma que o patch expulsa o intruso. Aplicar a correção fecha a porta, mas nada nas orientações do fabricante indica que remova o acesso que um atacante já tenha estabelecido. A rotação de credenciais e a caça a web shells partem precisamente do princípio de que não o faz.

Fragilidades encadeadas como esta, em que cada peça parece tolerável isoladamente, são exatamente o que um scanner que verifica um número de versão não consegue dizer-lhe e o que um teste de intrusão bem delimitado foi concebido para revelar. Os trabalhos de penetration testing da nossa equipa exercitam pivôs SSRF para serviços internos, pressupostos de confiança por defeito e contornos de WAF em aplicações de negócio expostas ao exterior como o PeopleSoft, para que a cadeia seja encontrada por nós e não pelo próximo grupo de extorsão.