Recomendações defensivas
A postagem de JFrog recomendou uma variedade de táticas defensivas para detecção e mitigação desses ataques, incluindo que os CISOs “deveriam tratar a instalação de uma versão completa do worm como um comprometimento do host”. Ele também sugeriu que os usuários revogassem e alternassem todas as credenciais do GitHub, GitLab, npm, PyPI, RubyGems, nuvem, SSH, Vault, Kubernetes e provedor de IA, bem como auditar “todos os repositórios acessíveis às identidades afetadas para .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.jsoninesperado composer.json ou ganchos de execução Makefile, e skip-checks:true compromete.”
JFrog também sugeriu que as empresas enumerassem árvores de repositório diretamente e que a TI não deveria confiar na pesquisa de código do GitHub ou na API de conteúdo, devido ao problema de tamanho do wrapper.
“Excluir não autorizado chore/ci-* e deps/upd-* filiais, desabilite fluxos de trabalho maliciosos e remova falsos CodeQL artefatos nomeados scan-output. Bloquear hxxp(:)//43(.)228(.)157(.)68:80, e infraestrutura maliciosa relacionada nos controles de rede” e “caçar logs e executores do GitHub Actions para /tmp/.svcipscan, CVE-2026-41940, específico da arquitetura /api/dl/ solicitações e varreduras excepcionalmente amplas de executores hospedados ou auto-hospedados”, sugeriu JFrog. E. Claro, procure por .napi.cache.
