Uma nova onda de ataques à cadeia de suprimentos de software atingiu a SAP na virada de abril para maio de 2026, com a publicação de versões maliciosas de pacotes oficiais no repositório npm.
Segundo alertas de pesquisadores de segurança, os pacotes contaminados foram distribuídos em um intervalo de poucas horas e tinham como foco roubar segredos de desenvolvedores e de esteiras de CI/CD.
A SAP reconheceu o problema por meio de comunicados e orientações a clientes, enquanto a comunidade de segurança aponta que o caso expõe fragilidades práticas no “trusted publishing” usado por grandes fornecedores.
O que este artigo aborda:
- O que aconteceu: pacotes oficiais do ecossistema CAP foram adulterados
- Como o malware agia: “preinstall” como gatilho e coleta de segredos
- Por que isso importa para empresas: risco “invisível” fora do radar do SOC
- Principais sinais de alerta que times devem revisar agora
- Resposta e próximos passos: lições para “clean build” e dependências
O que aconteceu: pacotes oficiais do ecossistema CAP foram adulterados
O incidente envolveu bibliotecas ligadas ao SAP Cloud Application Programming Model (CAP) e a ferramentas de build usadas por times que desenvolvem aplicações na plataforma.
De acordo com análises públicas, quatro versões publicadas no npm foram marcadas como maliciosas por conterem scripts executados automaticamente durante a instalação.
As versões citadas por múltiplas análises incluem @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, @cap-js/db-service 2.10.1 e mbt 1.2.48.
Em nota e páginas de orientação, a própria SAP listou os pacotes e versões afetadas e consolidou o episódio como alerta crítico, dentro do seu fluxo de publicações de segurança, em um boletim que menciona explicitamente as versões comprometidas.
O objetivo do código malicioso, segundo pesquisadores, era capturar credenciais e tokens presentes em ambientes de desenvolvimento, além de segredos armazenados em pipelines automatizados.
Como o malware agia: “preinstall” como gatilho e coleta de segredos
O mecanismo mais crítico foi a inclusão de um gancho de instalação (“preinstall”), que dispara antes mesmo do pacote ser usado pelo aplicativo.
Isso cria um cenário em que apenas executar “npm install” pode ser suficiente para rodar código não esperado no computador do desenvolvedor ou em um agente de CI.
Relatos técnicos indicam tentativa de coleta de tokens de serviços comuns do fluxo de engenharia, como repositórios de código, registries e provedores de nuvem.
Em resumo, o alvo não é “o ERP” diretamente, mas a cadeia de ferramentas que pode dar acesso a repositórios, chaves e ambientes que, por sua vez, conectam-se a sistemas corporativos.
- Ambiente local: variáveis de ambiente, tokens e arquivos de configuração em estações de trabalho.
- CI/CD: segredos em jobs automatizados, runners e integrações com registries.
- Cloud: credenciais que permitem movimentação lateral em contas de nuvem usadas por apps.
Uma base de dados de incidentes, citando análises de diferentes fornecedores, descreveu a inclusão de scripts maliciosos e o foco em segredos de desenvolvimento e CI/CD, em um resumo técnico do caso datado de 29 de abril de 2026.
Por que isso importa para empresas: risco “invisível” fora do radar do SOC
O ataque reforça uma tendência: criminosos priorizam o ponto mais fácil para entrar, que muitas vezes é o desenvolvimento, e não o data center.
Em várias empresas, o SOC monitora endpoints e servidores, mas a telemetria de pipelines de build e dependências open source ainda é fragmentada.
No caso SAP, a relevância cresce porque CAP e ferramentas associadas são usadas para construir integrações e extensões, inclusive em ambientes com dados sensíveis.
Mesmo sem evidência pública de impacto generalizado em clientes finais, a natureza do ataque exige postura de “assuma comprometimento” para quem instalou versões afetadas.
Principais sinais de alerta que times devem revisar agora
Equipes de engenharia e segurança têm uma janela curta para identificar instalações realizadas nos dias do incidente e, principalmente, o que foi exposto em pipelines.
- Auditar logs de CI/CD para instalações de dependências nas datas do incidente.
- Verificar “package-lock.json” e artefatos buildados, procurando versões específicas citadas nos alertas.
- Rotacionar tokens e chaves potencialmente acessados por jobs de build e runners.
- Revisar permissões de repositórios e chaves com acesso de escrita e publicação.
Na cobertura internacional do tema, a SecurityWeek detalhou a lista de pacotes e versões sinalizadas como maliciosas, além do contexto do ataque à cadeia de suprimentos, em uma reportagem publicada em 30 de abril de 2026.
Resposta e próximos passos: lições para “clean build” e dependências
O caso pressiona empresas a tratar o gerenciamento de dependências como controle de segurança, e não como detalhe operacional do time de desenvolvimento.
Também reforça a importância de separar credenciais por ambiente, reduzir o escopo de tokens e minimizar segredos disponíveis para jobs que não precisam deles.
Outra mudança prática é endurecer a política de instalação: bloquear scripts de instalação quando possível, usar allowlists de pacotes e exigir verificação em registry interno.
Para organizações que desenvolvem extensões e integrações SAP, o recado é direto: o “perímetro” começa no repositório e no pipeline, e termina em produção.
O que fica em aberto: ainda não há uma narrativa pública única sobre o vetor inicial (compromisso de token, CI mal configurado ou conta de mantenedor), e investigações costumam evoluir em etapas.
Enquanto isso, a recomendação operacional é tratar qualquer ambiente que tenha instalado as versões afetadas como potencialmente exposto, priorizando rotação de segredos e revisão de builds.
Aviso Editorial
Este conteúdo foi estruturado com o auxílio de Inteligência Artificial e submetido a rigorosa curadoria, checagem de fatos e revisão final pelo editor-chefe [email protected]. O Canal ERP reafirma seu compromisso com a ética jornalística, garantindo que o julgamento editorial e a validação das informações são de inteira responsabilidade humana, do editor.
Sobre o Autor:
Editor: [email protected]
Transparência: Política Editorial | Política de Uso de IA | Política de Correções | Contato