Falhas KEV do JFrog Artifactory: o âmbito do token importa mais do que o patch

A CISA adicionou duas vulnerabilidades do JFrog Artifactory ao seu catálogo de Vulnerabilidades Exploradas Conhecidas a 11 de setembro de 2026, dando às agências federais até 25 de setembro para as remediar ao abrigo da Diretiva Operacional Vinculativa 26-04. Os investigadores de segurança da Wiz afirmam que os atacantes já encadearam as duas falhas em contexto real para escalar de uma ligação anónima para acesso administrativo total em instâncias do Artifactory autoalojadas.

O que fazem os dois CVE

A CVE-2026-42018 é uma falha de autenticação imprópria que pode fazer com que o Artifactory entregue um token interno de utilizador anónimo a um pedido não autenticado, mesmo quando o acesso anónimo está desativado. A CVE-2026-42016, classificada com CVSS 8.1, é um problema de escalada de privilégios: o Artifactory valida a assinatura e o emissor de um token, mas não o seu âmbito, pelo que um token destinado a cobrir uma ação restrita pode ser reutilizado para mais do que aquilo que deveria permitir.

A Wiz relata que os atacantes têm usado a combinação desde pelo menos meados de agosto de 2026 para criar contas de administrador persistentes, instalar plugins maliciosos para execução de código e extrair dados de configuração e chaves de cluster. Na altura da divulgação, a Wiz mediu que cerca de dois terços das organizações que executam o Artifactory ainda mantinham pelo menos uma instância vulnerável.

Porque é que "assinado e válido" não é o mesmo que "com âmbito correto"

Para os MSP da UE que auditam instâncias de clientes, a questão operativa não é se a assinatura de um token é válida — normalmente é — mas se a plataforma impõe separadamente qual o tenant, repositório, caminho e verbo que esse token pode tocar. A validação de assinatura e emissor responde a "quem emitiu isto?" e "foi adulterado?". Não responde a "o que é que isto tem permissão para fazer?". Peça a qualquer fornecedor, incluindo a JFrog, que demonstre a aplicação do âmbito e o registo de negações com provas não produtivas antes de tratar um número de versão corrigido como o fim da revisão.

O que voltar a verificar após aplicar o patch

• Atualizar para uma versão corrigida do Artifactory — 7.161.20, 7.146.38, 7.133.29, 7.125.20, 7.117.28 ou 7.111.21 — correspondente ao ramo em utilização.
• Reauditar as definições de acesso anónimo e as permissões dos repositórios, não apenas a cadeia de versão.
• Rever os públicos dos tokens de contas de serviço e revogar tudo o que tenha sido emitido antes do patch.
• Confirmar que os limites entre tenants se mantêm sob o mesmo teste de âmbito usado para validar a correção.

O patch fecha o bypass específico; não restringe retroativamente tokens que já estavam com âmbito excessivo. Trate a rotação de credenciais e a revisão de âmbitos como parte da remediação, não como um acompanhamento opcional.

Fontes: Catálogo KEV da CISA, Avisos de segurança da JFrog, SecurityWeek.