Três vulnerabilidades no JFrog Artifactory estão sob exploração ativa e permitem bypass de autenticação em instâncias self-hosted expostas à internet, com invasores obtendo acesso administrativo persistente em menos de cinco minutos, segundo a empresa de segurança Wiz.io, que divulgou as falhas. Os ataques exploram as CVEs 2026-42018, 2026-42016 e 2026-82329, encadeadas para escalonamento de privilégios e controle total do servidor.
A Wiz.io descreve as falhas como triviais de explorar: bastam algumas requisições HTTP não autenticadas. A recomendação da empresa é direta: quem tinha instância exposta enquanto vulnerável deve assumir comprometimento e caçar artefatos de pós-exploração, porque atualizar fecha a porta, mas não expulsa quem já entrou.
Quais são as três vulnerabilidades do artifactory?
As três falhas têm gravidades distintas e mecânicas diferentes, mas funcionam bem em conjunto. A tabela abaixo resume o que a Wiz.io divulgou sobre cada uma.
| CVE | Gravidade | Efeito |
|---|---|---|
| CVE-2026-42018 | Alta | Artifactory devolve token interno de usuário anônimo a requisitantes não autenticados, mesmo com acesso anônimo desabilitado |
| CVE-2026-42016 | Alta | Falha na validação de escopo do token permite a usuário com privilégio baixo executar ações não autorizadas e elevar privilégios |
| CVE-2026-82329 | Crítica | Atacante não autenticado obtém controle administrativo diretamente |
Arraste para o lado para ver toda a tabela.
Duas dessas vulnerabilidades podem ser encadeadas em um ataque que resulta em contas de administrador persistentes e pós-exploração adicional. A CVE-2026-82329, por si só, já entrega token com escopo administrativo.
# publicidade
Como funciona a cadeia de exploração observada?
A Wiz.io documentou um padrão recorrente nos ataques. Primeiro, uma requisição POST não autenticada para /access/api/v1/aws/token/, com barra no final, retorna HTTP 200 com um JWT do usuário anônimo interno: é a CVE-2026-42018 em ação. Em seguida, o invasor troca esse JWT por um token com escopo de administrador via POST em /access/api/v1/tokens, explorando a falha de validação de escopo da CVE-2026-42016.
O detalhe perigoso: o token escalado mantém o nome de usuário anônimo, mas carrega autoridade administrativa. Nos logs, as requisições posteriores aparecem com o ator token:anonymous, o que complica a detecção. Quem atua com DevOps e monitoramento de pipelines deve incluir esse padrão nas regras de detecção imediatamente.
Atenção: busque nos logs requisições HTTP 200 para /access/api/v1/aws/token/ com barra final e atividade administrativa atribuída a token:anonymous. São os indicadores de comprometimento citados pela Wiz.io.
Mas o que os invasores fazem depois de entrar? Segundo a Wiz.io, as ações observadas incluem criação de contas administrativas persistentes, implantação de plugins Groovy maliciosos para execução de código, roubo de credenciais e das chaves de assinatura do Access, instalação de backdoors e mecanismos antifforenses. Em alguns casos, todo o ciclo até o acesso administrativo levou menos de cinco minutos.
Por que o risco à cadeia de suprimentos de software é elevado?
O Artifactory fica no centro dos pipelines de build de muitas organizações, e é justamente isso que amplifica o impacto. O especialista em cibersegurança Erik York comentou no LinkedIn que o Artifactory está no centro de muitas cadeias de suprimentos de software e que esse é exatamente o tipo de falha que pode virar a próxima história estilo SolarWinds se não for corrigida rápido.
Supply chain é o conjunto de ferramentas, dependências e serviços que participam da construção e distribuição de software. Um repositório de artefatos comprometido pode distribuir código adulterado para centenas de aplicações.
Jim Nitterauer, diretor sênior de segurança da informação na Graylog, reforçou o ponto: como o Artifactory fica no coração dos pipelines de build, um comprometimento é um risco direto de supply chain, e a adoção de patches tem ficado muito atrás, com ataques observados apenas quatro dias após a divulgação da terceira falha. O cenário se soma a outras pressões recentes sobre a cadeia de suprimentos, como a nova trava de segurança do VS Code contra ataques de supply chain e iniciativas de defesa coletiva como a Athena Coalition, que usa IA e colaboração global para blindar o open source.
Quais versões corrigem as falhas e o que fazer agora?
A correção exige atualização imediata de todos os ambientes Artifactory self-hosted para qualquer versão que corrija as vulnerabilidades, conforme o branch implantado. As versões corrigidas citadas são: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 ou mais recentes.
- Identifique a versão do seu Artifactory self-hosted e compare com as versões corrigidas na documentação das CVEs.
- Atualize para 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 ou versão superior do seu branch.
- Revise logs procurando os padrões de exploração citados pela análise da Wiz.io: POST com barra final no endpoint de token AWS e atividade como
token:anonymous. - Audite contas administrativas criadas recentemente, plugins Groovy instalados e as chaves de assinatura do Access. Se houver dúvida, rotacione credenciais.
- Se a instância ficou exposta à internet enquanto vulnerável, trate como comprometida e inicie resposta a incidente.
Dica: atualizar sozinho não basta. Como a Wiz.io alerta, o patch fecha a porta, mas não remove um invasor já estabelecido. Combine a atualização com caça a ameaças e rotação de segredos.
Na avaliação do Mercado de TI, o episódio expõe um gargalo clássico de infraestrutura crítica: ferramentas centrais de build recebem menos atenção de segurança do que aplicações voltadas ao usuário, embora concentrem credenciais, chaves e artefatos de distribuição.
Para times brasileiros que mantêm Artifactory self-hosted, a prioridade nesta semana é simples: patchear, caçar artefatos e revisar quem tem privilégio administrativo. Com exploração trivial e ataques quatro dias após a divulgação, a janela de tolerância já fechou.
Fonte: Infoq
