A SAP corrigiu no Patch Day de 8 de setembro de 2026 duas falhas no kernel SAP que permitem executar comandos no servidor sem nenhuma credencial. A OVERPASS (CVE-2026-44756) recebeu CVSS 10.0, a nota máxima, e a S4GET (CVE-2026-58240) recebeu 9.8. As duas foram encontradas pela Onapsis, que até agora não observou exploração ativa. Como o kernel é a base de praticamente todo sistema SAP on-premises, de S/4HANA e ECC a PI/PO e Solution Manager, a pergunta para quem tem SAP em produção não é se está no escopo, e sim quantos sistemas estão.

A notícia foi publicada pelo The Hacker News, com base nos alertas técnicos da Onapsis sobre a OVERPASS e a S4GET.

Resumo para quem decide

• Risco: um atacante sem usuário nem senha pode assumir o servidor SAP, ler credenciais do banco de dados e dados de negócio, e alcançar outros sistemas SAP conectados.
• Quem é afetado: sistemas SAP on-premises e clientes RISE with SAP. Segundo a Onapsis, os sistemas de nuvem pública já estavam corrigidos quando o patch saiu.
• Controles de acesso não ajudam: perfis, bloqueio de usuários, segregação de funções (SoD) e política de senha não estão no caminho do ataque, porque a falha é atingida antes da autenticação.
• Custo da correção: é um patch de kernel, então exige janela de parada e reinício. Cliente RISE precisa abrir uma solicitação à SAP para agendar essa janela.
• O que mandar fazer agora: inventariar os sistemas e a versão de kernel de cada um, corrigir primeiro o que está exposto à internet e, em seguida, todo o resto da rede interna.

OVERPASS (CVE-2026-44756): três caminhos para a mesma falha

A falha está no código do kernel SAP que processa o Extended Passport (EPP), uma estrutura de rastreamento que o cliente anexa às requisições para medir desempenho entre sistemas. Falta validação de limites quando o kernel lê campos de tamanho enviados pelo cliente, o que causa corrupção de memória. Uma requisição manipulada permite tomar o controle do processo e executar comandos no sistema operacional com a conta dona da instalação SAP.

O EPP é processado no momento em que a sessão é aberta, antes de qualquer checagem de usuário. E, como o mesmo código atende vários protocolos, a Onapsis confirmou três rotas até a falha, todas sem autenticação:

1. Camada web: o Internet Communication Manager (ICM) e o SAP Web Dispatcher, que servem Fiori, WebGUI, web services e APIs. É a camada que as empresas costumam publicar na internet.
2. Camada SAP GUI: o Dispatcher, por onde passa todo logon do SAP GUI clássico.
3. Camada RFC: a conexão entre sistemas SAP e a base de muitas integrações com terceiros.

A consequência prática é que proteger uma rota não resolve as outras. Um sistema com a camada web bem protegida continua alcançável pelo SAP GUI e pelo RFC. Só o patch fecha as três.

O que um atacante consegue depois de explorar

Com a conta que roda o SAP, o atacante lê o secure store e recupera credenciais do banco de dados e hashes de senha, lê a sessão de usuários conectados naquele momento, extrai credenciais para entrar em outros sistemas SAP que confiam no comprometido e altera dados, configuração e os próprios binários do SAP. Isso abre caminho para ransomware, desvio de pagamentos com troca de dados bancários de fornecedores, criação de usuários privilegiados e roubo de dados financeiros e de RH.

Tamanho da exposição

A Onapsis identificou mais de 10 mil endereços IP com interface web SAP acessível pela internet e considera o número conservador, porque o Web Dispatcher não se identifica como SAP para os buscadores. Mas a rota do SAP GUI muda a conta para quem não publica nada na internet: essa porta fica aberta na rede interna para todo usuário por necessidade do negócio. Um atacante que já esteja dentro da rede, por uma estação comprometida por phishing, por uma VPN de terceiro ou por credenciais corporativas vazadas por infostealers, já está em posição de explorar.

Versões afetadas

A nota SAP 3747649 lista como afetados os kernels 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 e 9.20, as variantes KRNL64NUC 7.22 e 7.22EXT e KRNL64UC 7.22, 7.22EXT, 7.53 e 8.04.

Sobre o Web Dispatcher há uma divergência entre as publicações: o portal da SAP lista WEBDISP 9.16, 9.18, 9.19 e 9.20, enquanto o resumo da Onapsis diz que o patch cobre a versão 9.16 e que as demais não são afetadas. Na dúvida, vale o que está na nota 3747649.

Os patch levels corrigidos da OVERPASS estão na própria nota 3747649, que exige acesso ao portal de suporte da SAP. A SAP também publicou a nota de perguntas frequentes 3776034 e, na nota 3756304, contornos para impedir a exploração pelo tráfego HTTP enquanto a janela de parada não sai.

S4GET (CVE-2026-58240): o Message Server passa a confiar no atacante

O Message Server é o componente que controla quais servidores de aplicação estão ativos no cluster e distribui os logons do SAP GUI. Por isso ele escuta numa porta pública (36NN), que todo cliente SAP GUI precisa alcançar. O Gateway, porta de entrada RFC de cada servidor de aplicação, decide quem é “interno” com base no que o Message Server informa.

A S4GET é um erro de lógica, não de configuração. Com um pacote manipulado enviado à porta pública, um atacante sem credencial faz um endereço IP ser tratado como confiável. O Message Server propaga essa confiança para todos os servidores de aplicação do cluster. O atacante então se conecta ao Gateway a partir desse IP, é aceito como interno, chama programas externos via RFC e executa código como <sid>adm, o usuário de sistema operacional que roda o SAP, em todos os servidores do cluster.

As proteções que as equipes SAP Basis costumam usar não estão no caminho. Comunicação segura habilitada e as listas de acesso secinfo``reginfo e ms/acl_info bem configuradas não impedem o ataque. Existe uma lista de acesso separada para a porta externa do Message Server, mas ela raramente é mantida e, segundo a Onapsis, funciona como endurecimento, não como substituto do patch.

Quem acompanha SAP há alguns anos vai lembrar do 10KBLAZE, de 2019. A diferença é que o 10KBLAZE dependia de uma porta interna (39NN) mal configurada, que se corrigia ajustando a lista de acesso. A S4GET chega ao mesmo resultado pela porta pública, e fechar essa porta quebra o logon dos usuários.

Quem está exposto: olhe a versão do kernel SAP, não o produto

A S4GET afeta os kernels 9.16, 9.18, 9.19 e 9.20. A Onapsis alerta para dois erros de avaliação:

• Achar que só o S/4HANA 2025 é afetado. O 9.16 é o kernel nativo do S/4HANA 2025, mas as linhas 9.x estão disponíveis para versões anteriores, e um S/4HANA 2023 pode já estar rodando uma delas.
• Parar no S/4HANA. O kernel é compartilhado por todo sistema ABAP, então outros sistemas ABAP da empresa com essas linhas de kernel estão igualmente expostos.

Os patch levels corrigidos, segundo a nota 3759472, são:

Qualquer patch level abaixo desses é vulnerável. Para conferir, abra no SAP GUI o menu System → Status e veja as informações do kernel, ou rode disp+work -version no sistema operacional como <sid>adm.

Em que ordem corrigir

Os alertas da Onapsis para as duas falhas seguem a mesma ordem:

1. Inventário completo. Liste todos os sistemas SAP com versão de kernel e patch level, inclusive os esquecidos: sistemas antigos que ainda estão ligados, sandboxes e ambientes de desenvolvimento e teste com cópia de dados de produção, que costumam ser menos segmentados. É um risco que já tratamos em segurança em ambientes de homologação. Registre também quais redes alcançam cada sistema.
2. Sistemas expostos à internet primeiro. Qualquer sistema com camada web publicada, e qualquer Message Server acessível de fora. A exposição direta do Message Server é rara, mas vale confirmar que essa lista está vazia em vez de supor.
3. Sistemas internos em seguida, sem tratar como opcional. São a maior parte do parque e estão uniformemente expostos pela rota do SAP GUI. Vêm em segundo lugar na ordem, não na importância.
4. Reduzir o alcance onde a arquitetura permitir. Colocar o acesso SAP GUI atrás de SAProuter ou de servidores de salto, e o acesso web atrás do Web Dispatcher, sem publicá-lo na internet. Isso diminui a exposição, mas não substitui o patch.
5. Monitorar a camada de aplicação SAP para detectar tentativas de exploração enquanto a correção não chega a todos os sistemas.

Por que não esperar a próxima janela

Duas referências mostram quanto tempo sobra. Em 2020, atacantes levaram cerca de 72 horas para transformar o patch da RECON (CVE-2020-6287) em exploit, e a Onapsis avalia que esse prazo continua encolhendo com ferramentas de IA. Em 2025, a CVE-2025-31324, falha de upload sem autenticação no NetWeaver, foi explorada em várias ondas antes de muitas empresas conseguirem aplicar a correção, e o relatório M-Trends 2026 da Mandiant a apontou como a vulnerabilidade mais explorada do ano. Não é a primeira falha crítica em SAP que tratamos aqui, como mostra o caso da vulnerabilidade crítica que pode permitir invasão total de sistemas corporativos.

Outras notas críticas do mesmo Patch Day

• CVE-2026-76969 (CVSS 9.4), nota 3798315: aplicações multitenant feitas com o SAP Cloud Application Programming Model (CAP). A biblioteca @sap/cds-mtxs nas versões até 1.18.3, 2.7.6, 3.9.6 e 4.0.2 permite que um atacante sem credencial obtenha credenciais e substitua ou apague dados dos tenants, os clientes da aplicação. Para quem não está no Cloud Foundry existe contorno na nota 3802171.
• CVE-2026-66768 (CVSS 9.0), nota 3781729: o SAP GUI for Java 8.10 não aplica corretamente a política de confiança para funções chamadas por um sistema conectado. Um sistema backend manipulado consegue executar comandos na máquina do usuário.
• CVE-2026-58231 (CVSS 10.0), nota 3771065: atualização de uma nota de agosto sobre o SAP Commerce Cloud (Data Hub Adapter). A atualização esclarece que ambientes sem modificação não estão expostos por padrão e traz um FAQ para verificar a configuração.

Perguntas frequentes

As falhas OVERPASS e S4GET já estão sendo exploradas?
Não há exploração ativa conhecida. A Onapsis, que descobriu as duas, não havia observado ataques nos alertas atualizados em 14 e 15 de setembro de 2026, e informa que vai atualizá-los se isso mudar.

Minha empresa usa SAP na nuvem. Preciso fazer algo?
Segundo a Onapsis, sistemas de nuvem pública já estavam corrigidos quando o patch foi publicado. Clientes RISE with SAP afetados foram avisados e precisam abrir uma solicitação para agendar a janela de parada do patch de kernel.

Bloquear a porta no firewall resolve?
Não. No caso da S4GET, a porta explorada é a mesma do logon do SAP GUI, e fechá-la derruba o acesso dos usuários. No caso da OVERPASS, há três rotas diferentes até a falha. Restringir o acesso reduz a exposição, mas só o patch corrige.

Como sei se meu kernel SAP está vulnerável à S4GET?
Confira a versão e o patch level do kernel no SAP GUI (menu System → Status) ou com disp+work -version. Kernels 9.16 abaixo do PL 100, 9.18 abaixo do PL 32, 9.19 abaixo do PL 17 e 9.20 abaixo do PL 7 estão vulneráveis.

Perfis de acesso e segregação de funções protegem contra essas falhas?
Não. As duas falhas são atingidas antes de qualquer autenticação, então bloqueio de usuários, perfis restritos e política de senha não interferem no ataque.