Ataques encadeiam falhas no JFrog Artifactory para obter controle admin e instalar backdoors

11 de Setembro de 2026

Hackers encadearam duas falhas no JFrog Artifactory, o repositório do qual os pipelines de compilação de software extraem artefatos, para assumir o controle administrativo de servidores auto-hospedados e instalar backdoors, informou a empresa de segurança em nuvem Wiz em um relatório.

A Wiz observou os ataques entre 15 de agosto e 8 de setembro. A JFrog já havia corrigido as duas falhas antes disso, então apenas servidores sem atualização ficaram expostos.

Nenhuma das falhas, isoladamente, concede controle administrativo.

CVE-2026-42018 faz o Artifactory entregar a um solicitante que não fez login um token interno de usuário anônimo, mesmo quando o acesso anônimo está desativado.

Já CVE-2026-42016 permite trocar esse token de baixo privilégio por outro com escopo administrativo, porque o Artifactory verifica a assinatura do token e quem o emitiu, mas não o que ele está autorizado a fazer.

Em todos os casos observados pela Wiz, o ataque seguiu o mesmo padrão. O hacker enviava uma requisição sem autenticação a um endpoint de token e recebia um token do usuário anônimo interno, depois o trocava, no endpoint de criação de tokens do Artifactory, por um token com escopo administrativo.

Esse segundo token mantém o nome de usuário anônimo. Assim, as ações administrativas executadas com ele aparecem nos logs como token:anonymous, em vez de serem atribuídas a uma conta identificada.

Em alguns casos, o invasor passou da primeira requisição a uma nova conta administrativa em menos de cinco minutos.

A cadeia de exploração atinge um conjunto mais restrito de builds do que cada falha separadamente. Um servidor precisa ser afetado pelas duas, então corrigir qualquer uma delas interrompe o ataque. Nos intervalos publicados pela JFrog, CVE-2026-42016 termina na versão 7.133.11, deixando as linhas 7.146 e 7.161 fora desse alcance.

A JFrog liberou a correção de CVE-2026-42018 na linha 7.146 em 28 de abril e na linha 7.133 em 12 de agosto, três dias antes do início dos ataques observados pela Wiz.

O que os atacantes fizeram após obter privilégios administrativos variou. Segundo a Wiz, nenhum ator isolado executou todas as etapas observadas.

Nos servidores comprometidos, os hackers criaram contas administrativas e as mantiveram ativas. Eles também instalaram plugins maliciosos em Groovy por meio do framework de plugins do Artifactory, o que lhes deu execução de código no servidor. Em alguns casos, executaram comandos de shell pelo endpoint de execução de plugins para explorar o ambiente e listar arquivos.

Um dropper baixou um binário via HTTP, gravou o arquivo em um diretório com permissão de gravação ampla, como /tmp, e abriu um canal de command and control. A Wiz afirmou ainda ter visto um backdoor personalizado em Rust com recursos de command and control ser implantado em vários casos.

Uma terceira falha no Artifactory, também citada no relatório, CVE-2026-82329 , foi explorada separadamente entre 1º e 8 de setembro, e é ela que faz com que um servidor em uma linha mais nova ainda possa estar exposto.

Trata-se de um bypass de autenticação crítico, classificado com 9,8 na escala CVSS, que mira a configuração padrão do Artifactory e não depende de nenhuma outra falha. Um atacante sem autenticação, com acesso à rede, consegue obter privilégios administrativos por meio dela, sozinho, em seis linhas de lançamento até a 7.161.

Segundo o analistas de segurança, os atacantes já haviam começado a criar tokens administrativos para si mesmos por meio dessa falha poucos dias após a divulgação feita pela JFrog. A CISA incluiu a falha em seu catálogo de vulnerabilidades conhecidas e exploradas em 2 de setembro e fixou 5 de setembro como prazo para agências federais.

A Fastly, rede de distribuição de conteúdo, disse em uma análise que um exploit público surgiu em 1º de setembro e, em seguida, vieram as varreduras. A empresa contabilizou cerca de 406.000 tentativas de exploração em sua plataforma em 2 de setembro, o dia de maior volume. Trata-se de tentativas observadas no tráfego, não de compromissos confirmados.

Nos servidores tomados por meio dessa falha, a Wiz viu os atacantes lerem a configuração do sistema e, em vários casos, obterem a cluster join key, o segredo compartilhado usado pelos nós do Artifactory para se registrarem uns aos outros.

O que instalar

Atualize o Artifactory auto-hospedado para a versão corrigida da sua linha de lançamento, conforme listado nos avisos de segurança da JFrog. A empresa afirma que instâncias em cloud não exigem ação.

| CVE | O que faz | Afetado | Corrigido em |
|---|---|---|---|
| CVE-2026-42018 | Retorna um token interno de usuário anônimo a um solicitante que não fez login | Abaixo de 7.111.20, 7.117.27, 7.125.19, 7.133.28 e 7.146.8 nessas linhas | 7.111.20, 7.117.27, 7.125.19, 7.133.28, 7.146.8 |
| CVE-2026-42016 | Permite que um token de baixo privilégio seja trocado por um token com escopo administrativo | Antes de 7.133.11 | 7.133.11 |
| CVE-2026-82329 | Concede privilégios administrativos a um atacante sem autenticação, por si só | Abaixo de 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 e 7.161.20 nessas linhas | 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 |

A JFrog lista uma única versão corrigida para CVE-2026-42016 , a 7.133.11, e não traz correção separada para cada linha. O comunicado não informa se uma build mais recente em uma linha mais antiga, como a 7.117.28, também elimina a falha. Analistas perguntaram isso à JFrog e também perguntou à Wiz em quais versões os servidores comprometidos estavam rodando.

Para CVE-2026-82329 , a JFrog publica um workaround para quem não puder atualizar rapidamente: gere um valor aleatório e adicione-o como um join key extra em system.yaml, para que apenas suas próprias chaves sejam aceitas quando um serviço se registrar.

Não há opção intermediária para as duas falhas encadeadas em nenhum dos avisos ou relatórios consultados.

O que a correção não reverte

As contas administrativas criadas pelos atacantes não desaparecem quando o software é atualizado. A Wiz viu essas contas serem criadas tanto pela cadeia das duas falhas quanto por CVE-2026-82329 .

No caso de CVE-2026-82329 , a Fastly recomenda tratar qualquer servidor exposto como comprometido. “Uma correção não revoga tokens já emitidos”, disse a empresa.

A atualização também não altera um join key que os atacantes já tenham obtido. A Fastly recomenda rotacionar o join key da plataforma, revogar os tokens de acesso emitidos desde 28 de agosto e revisar contas administrativas, repositórios e mudanças de configuração.

Como verificar

O sinal mais claro é uma conta executando ações que seu nível de privilégio não deveria permitir: o usuário anônimo interno, ou qualquer conta de baixo privilégio, criando tokens, listando usuários ou lendo e gravando plugins.

Depois, procure por contas administrativas que ninguém criou de propósito. A maioria das observadas pela Wiz traz nomes típicos de prova de conceito, como 0xTerror, ou prefixos como svc_ e labadmin_ seguidos de caracteres aleatórios. Algumas foram criadas para parecer legítimas, com nomes como jfrog-distribution, jfrog-insight e repo-service. O relatório da Wiz lista endereços dos atacantes e o hash de um payload.

CVE-2026-42016 foi publicada em 27 de julho como parte de um conjunto de avisos do Artifactory, vários deles creditando pesquisadores da OpenAI, incluindo este. Segundo o The Hacker News, em julho a JFrog confirmou que modelos da OpenAI exploraram um zero-day do Artifactory durante uma avaliação interna, e nenhuma das empresas informou quais registros CVE correspondem às falhas usadas.

Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...