Atualizações de segurança de novembro de 2026 corrigem vulnerabilidades graves em componentes SAP NetWeaver, Gateway, Web Dispatcher e SAML. O episódio reforça os riscos associados à exposição de sistemas empresariais e às limitações dos controles tradicionais de identidade.
Quatro vulnerabilidades de severidade máxima colocam sistemas SAP em alerta
A SAP divulgou seu pacote de atualizações de segurança de novembro de 2026, contemplando 35 vulnerabilidades, incluindo quatro classificadas com severidade máxima.
Entre as falhas reportadas estão a CVE-2026-76964, associada ao cenário conhecido como ICM2SHELL, e a CVE-2026-89103, relacionada ao PROXYGATE.
De acordo com as informações divulgadas, essas vulnerabilidades podem permitir execução de código em determinadas configurações, sem exigir autenticação prévia.
O conjunto de correções também contempla uma vulnerabilidade no componente SAML2 Service Provider, responsável por funcionalidades de autenticação federada em ambientes SAP.
O impacto potencial é particularmente relevante porque plataformas SAP frequentemente sustentam processos essenciais de negócio, incluindo operações financeiras, recursos humanos, compras, logística e gestão de fornecedores.
Em muitos casos, esses sistemas também possuem integrações privilegiadas com outras aplicações corporativas.
Uma vulnerabilidade em um componente de infraestrutura SAP pode representar muito mais do que o comprometimento de um servidor: pode abrir caminho para atingir processos críticos de toda a organização.
Quando o ataque acontece antes da autenticação
Um dos aspectos mais preocupantes das vulnerabilidades divulgadas é a possibilidade de exploração sem autenticação prévia em determinadas configurações.
Em uma arquitetura corporativa tradicional, os mecanismos de segurança costumam concentrar esforços na validação da identidade do usuário.
São implementados controles como:
- Single Sign-On (SSO).
- Autenticação multifator (MFA).
- Integração com provedores de identidade.
- Políticas de autorização baseadas em funções.
- Gestão de acessos privilegiados.
- Monitoramento de sessões e atividades.
Esses mecanismos são fundamentais, mas não eliminam vulnerabilidades que podem ser exploradas antes de o processo de autenticação ser executado.
Se um componente exposto permite a execução de código sem validar previamente a identidade do solicitante, os controles de autenticação do usuário podem não participar do fluxo de ataque.
Isso cria uma distinção importante para os responsáveis por segurança:
Ter MFA habilitado para acessar o SAP não significa que todos os componentes da infraestrutura SAP estejam protegidos contra acessos não autenticados.
A proteção precisa considerar não apenas o login dos usuários, mas também a segurança das interfaces, serviços, gateways e componentes responsáveis pela comunicação entre sistemas.
NetWeaver, Gateway e Web Dispatcher: a superfície de ataque além do ERP
Ambientes SAP modernos normalmente envolvem diferentes camadas de infraestrutura e integração.
O SAP NetWeaver fornece componentes tecnológicos utilizados por diversas aplicações empresariais.
O SAP Gateway permite a exposição e o consumo de serviços, incluindo interfaces utilizadas em integrações e aplicações.
Já o SAP Web Dispatcher atua no encaminhamento e na distribuição de requisições HTTP e HTTPS para sistemas SAP.
Esses componentes desempenham funções importantes na arquitetura, mas também ampliam a superfície de exposição quando não são adequadamente atualizados, configurados e protegidos.
Uma vulnerabilidade em um gateway ou componente de comunicação pode permitir que um atacante alcance funcionalidades internas sem necessariamente passar pelo mesmo fluxo de autenticação utilizado pelos usuários finais.
O risco aumenta quando esses componentes possuem conectividade com sistemas críticos, permissões elevadas ou acesso a redes internas sensíveis.
Por isso, a análise de segurança precisa considerar a arquitetura completa de comunicação e integração do ambiente SAP.
Falhas em SAML: quando a confiança entre sistemas se torna um risco
Outro ponto relevante do pacote de novembro envolve o componente SAML2 Service Provider.
O Security Assertion Markup Language (SAML) é amplamente utilizado para implementar autenticação federada e Single Sign-On entre aplicações corporativas e provedores de identidade.
Em um cenário típico, o usuário se autentica em uma plataforma como Microsoft Entra ID, Okta ou outro Identity Provider (IdP), e o sistema SAP recebe uma declaração de autenticação para estabelecer a sessão.
Essa arquitetura permite centralizar políticas de autenticação e reduzir a necessidade de credenciais independentes.
Entretanto, a segurança depende de diversos fatores, incluindo a validação adequada das mensagens SAML, a configuração das relações de confiança e a implementação correta dos componentes envolvidos.
Uma falha no processamento de autenticação federada pode comprometer a confiabilidade desse modelo.
Isso não significa que o protocolo SAML seja inerentemente inseguro, nem que a vulnerabilidade permita automaticamente contornar MFA em todos os ambientes.
O impacto depende do defeito específico, das versões afetadas e das configurações utilizadas.
Ainda assim, o episódio demonstra que a segurança da autenticação federada depende tanto do Identity Provider quanto da aplicação que consome e valida as declarações de identidade.
Um provedor de identidade seguro não consegue compensar, sozinho, uma vulnerabilidade crítica no componente que recebe e processa a autenticação.
O impacto para IAM, IGA e PAM
O caso SAP apresenta implicações importantes para diferentes disciplinas de Identity and Access Management.
Identity Governance and Administration (IGA)
As plataformas de IGA ajudam a controlar quem deve possuir acesso aos sistemas SAP, quais funções podem ser atribuídas e como essas permissões devem ser revisadas.
Entretanto, vulnerabilidades que permitem acesso fora dos fluxos normais de autenticação podem criar caminhos de comprometimento que não aparecem nas certificações tradicionais de acesso.
Isso reforça a necessidade de combinar governança de identidades com gestão de vulnerabilidades e monitoramento de segurança.
Privileged Access Management (PAM)
Contas técnicas, usuários administrativos e identidades de integração frequentemente possuem privilégios elevados nos ambientes SAP.
Caso um componente de infraestrutura seja comprometido, essas identidades podem se tornar alvos relevantes para escalada de privilégios e movimentação lateral.
O PAM deve ser considerado não apenas para proteger o acesso interativo dos administradores, mas também para controlar credenciais técnicas, acessos emergenciais e atividades privilegiadas.
Identity Threat Detection and Response (ITDR)
A capacidade de identificar comportamentos anômalos associados a identidades torna-se essencial em ambientes empresariais críticos.
Tentativas incomuns de autenticação, alterações de permissões, utilização inesperada de contas técnicas e atividades administrativas fora do padrão podem representar indicadores relevantes de comprometimento.
Entretanto, ataques que exploram diretamente vulnerabilidades de infraestrutura também exigem telemetria de aplicações, redes e sistemas operacionais.
A resposta mais eficaz depende da correlação entre essas diferentes fontes de informação.
Cinco prioridades para proteger ambientes SAP
As vulnerabilidades divulgadas exigem atenção das equipes responsáveis por SAP Basis, infraestrutura, segurança e IAM.
1. Identificar sistemas e componentes afetados
Mapear versões, instâncias e componentes SAP presentes no ambiente, incluindo NetWeaver, Gateway, Web Dispatcher e serviços SAML.
Verificar a aplicabilidade das SAP Security Notes correspondentes.
2. Priorizar a aplicação das correções
Tratar vulnerabilidades de severidade máxima como prioridade, especialmente quando envolvem execução de código sem autenticação.
Planejar testes e janelas de manutenção compatíveis com a criticidade dos processos de negócio.
3. Revisar a exposição de gateways e serviços
Avaliar quais interfaces estão acessíveis pela internet ou por redes com menor nível de confiança.
Aplicar segmentação, restrições de conectividade e controles de proteção compatíveis com a arquitetura SAP.
4. Validar a configuração de autenticação federada
Revisar as integrações SAML, as relações de confiança com provedores de identidade, a validação de assertions e as configurações de autenticação.
Confirmar se os componentes afetados estão corrigidos, sem assumir que a utilização de MFA ou SSO elimina o risco.
5. Monitorar identidades e atividades privilegiadas
Revisar contas técnicas, usuários administrativos, permissões sensíveis e eventos de autenticação.
Integrar informações de SAP, IAM, PAM e ferramentas de detecção de ameaças para ampliar a visibilidade sobre possíveis atividades maliciosas.
Zero Trust também precisa proteger os componentes que processam identidades
A estratégia de Zero Trust pressupõe que nenhum acesso deve ser considerado confiável apenas por sua origem ou localização na rede.
No entanto, a aplicação desse princípio exige uma visão abrangente da infraestrutura.
Não basta proteger o usuário no momento do login.
É necessário proteger os serviços que recebem solicitações, validam identidades, processam tokens, estabelecem sessões e executam operações privilegiadas.
Em ambientes SAP, isso inclui os componentes responsáveis pela autenticação federada, gateways, serviços de integração e interfaces administrativas.
A combinação de autenticação forte, segmentação de rede, correções de segurança e monitoramento contínuo ajuda a reduzir os riscos.
O princípio é simples:
A confiança na identidade não pode ser maior do que a confiança na infraestrutura responsável por validá-la.
Conclusão: o ERP mais crítico da empresa pode ser acessado sem senha?
As vulnerabilidades corrigidas pela SAP em novembro de 2026 reforçam um desafio que ultrapassa a gestão tradicional de acessos.
Organizações podem possuir processos maduros de governança, autenticação multifator, certificações periódicas e soluções avançadas de PAM, mas ainda permanecer expostas por falhas em componentes de infraestrutura e integração.
O problema não está na ausência de controles de identidade, mas na existência de caminhos técnicos que podem contorná-los.
Para profissionais de IAM, a principal lição é que a segurança de identidades precisa evoluir de uma visão centrada exclusivamente no usuário para uma abordagem que também contemple aplicações, protocolos, serviços, integrações e identidades não humanas.
Na OWLK Cybersecurity, defendemos uma abordagem integrada de Identity Security, combinando governança, autenticação, proteção de acessos privilegiados e detecção de ameaças.
A segurança de um ambiente SAP não depende apenas de quem está autorizado a entrar.
Depende também de garantir que não existam caminhos vulneráveis capazes de permitir acesso sem passar pelos controles estabelecidos.
Sua organização protege o login do SAP. Mas protege todos os caminhos que podem levar até ele?
