Três correções, uma única cadeia de ataque
A JFrog lançou correções para três vulnerabilidades distintas do Artifactory desde 27 de julho de 2026, e os atacantes passaram semanas a encadear as duas primeiras antes de a terceira se tornar pública.
| CVE | Divulgada | Vulnerável agora |
|---|---|---|
| CVE-2026-42016 | 27 Jul 2026 | 59% (+6 wk) |
| CVE-2026-42018 | 12 Aug 2026 | 62% (+4 wk) |
| CVE-2026-82329 | 28 Aug 2026 | 49% (+2 wk) |
A CVE-2026-42016 permite trocar um token de baixo privilégio por um token com âmbito de administrador. A CVE-2026-42018 entrega um token interno de utilizador anónimo a quem nunca iniciou sessão, mesmo com o acesso anónimo desativado. A CVE-2026-82329, divulgada a 28 de agosto com uma pontuação CVSS de 9,8, permite a um atacante não autenticado obter privilégios de administrador diretamente numa configuração predefinida.
Os passos exatos que transformam um convidado num administrador
A empresa de segurança Wiz documentou o mecanismo exato: os atacantes enviam um pedido POST para /access/api/v1/aws/token/, com uma barra final, que devolve um JWT anónimo apesar de o acesso anónimo estar desativado. Depois enviam esse token para /access/api/v1/tokens para pedir um token com âmbito de administrador, que o Artifactory emite sem verificar corretamente o nível real de privilégio de quem o solicita.
Para a falha mais recente, a CVE-2026-82329, a Wiz encontrou um atalho ainda mais direto: um único POST para /access/api/v1/registry/join devolve diretamente um token de administrador, sem ser preciso encadear nada. Uma vez lá dentro, os atacantes criaram contas de administrador persistentes, instalaram plugins Groovy maliciosos através da própria estrutura de plugins do Artifactory para executar código no servidor, e em alguns casos implantaram backdoors escritas em Rust com capacidade de comando e controlo. A Wiz observou os ataques encadeados a decorrer entre 15 de agosto e 8 de setembro de 2026, com uma onda separada a explorar a CVE-2026-82329 entre 1 e 8 de setembro.
Corrigido não significa resolvido
A diferença entre existir uma correção e um servidor a executá-la de facto é a verdadeira história aqui, e mede-se em meses, não em dias. A JFrog corrigiu a CVE-2026-42016 na versão 7.133.11 a 27 de julho; seis semanas depois, segundo a telemetria da Wiz, 59 por cento das organizações continuavam vulneráveis a ela.
A CVE-2026-42018 não se saiu melhor: corrigida em cinco ramos até 12 de agosto, quatro semanas depois 62 por cento das organizações continuavam expostas. A CVE-2026-82329 moveu-se mais rápido, passando de 67 por cento vulneráveis na divulgação para 49 por cento depois de duas semanas, mas isso ainda deixa cerca de metade de todas as implementações do Artifactory abertas a uma falha com gravidade 9,8 em 10. A escala das tentativas automatizadas de exploração contra servidores não corrigidos não é teórica: a Fastly registou cerca de 406 mil tentativas de exploração contra a CVE-2026-82329 num único dia, 2 de setembro, o mesmo dia em que a CISA a adicionou ao seu catálogo de vulnerabilidades exploradas conhecidas.
A obrigação europeia que ainda ninguém faz cumprir
A CISA deu às agências federais dos EUA um prazo fixo, 5 de setembro, três dias depois de adicionar a CVE-2026-82329 ao seu catálogo KEV a 2 de setembro. A UE não tem uma ordem pública equivalente com data para empresas privadas, ainda que o artigo 21 da NIS2 já exija a muitas empresas médias de software e de serviços de TI manter um processo documentado de gestão de vulnerabilidades que cubra exatamente este tipo de ferramenta de cadeia de fornecimento exposta à internet e não corrigida.
Isso deixa um vazio real para qualquer empresa sediada na UE que hospede o Artifactory por conta própria: existe uma obrigação legal de gerir este risco nos termos da NIS2, mas não há um prazo nacional ou a nível da UE publicado que force a questão da forma como a ordem da CISA o faz nos Estados Unidos. Por agora, o único motor fiável para corrigir uma instância do Artifactory alojada na UE é a própria equipa de segurança de uma empresa a ler um aviso do fornecedor e a agir em conformidade, não o relógio de um regulador.
Leia a seguir: A Falha Pior Classificada do GitLab Só Precisa de Um Projeto Público | O Erro Que Quebrou Aquilo De Que O Patching Depende
