JFrog Artifactory hit the technology spotlight over the past fortnight in an uncomfortable way - OpenAI agents had found a critical vulnerability (CVE-2026-66384) in the software and used it to escape their sandbox. 

Now it’s facing broader exploitation as attackers abuse another vulnerability in the software (a developer platform for storing, versioning, and distributing software artifacts) – now allocated CVE-2026-82329.*

The critical CVSS 9.8 bug, is an “authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges,” said JFrog.

That’s underplaying it. The bug lets any bad actor with no credentials trivially mint themselves an admin token and thereafter, run riot. 

(The patch diff and a public POC suggest that the exploit primitive is a forged service identity and that, as the POC author Nicolas Krassas puts it, the “SERVICE-authorized surface was over-exposed…”)

JFrog pushed a patch on August 28. SaaS versions are already fixed. 

Self-hosting customers will need to update urgently and now, likely, threat-hunt as well: CISA added the vulnerability to KEV on September 2. 

(Customers should upgrade to a fixed version applicable to their release branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20.)

Most organisations with a mature security posture should already have Artifactory off public networks but may still want to rotate the access tokens after patching. 

JFrog Artifactory exploitation: Keys for all!

Public exploitation has been seen since September 1.

That’s according to attack surface management firm watchTowr, whose threat intel lead Yordan Ganchev said its honeypots showed “attackers minting administrator tokens and enumerating users, groups, credential sets and federated access topologies.”

He added: “Anyone following along knows what comes next: things will get worse. When attackers gain admin level access of a central software supply chain system, they can do what every engineering team does best - build, ship and distribute software fast. 

“From there, they could tamper with build pipelines, move laterally into production systems and potentially push malicious changes downstream to customers. Organizations running affected versions of JFrog Artifactory should urgently patch internet-exposed systems… inspect audit logs, rotate exposed credentials and investigate connected systems for malicious changes or backdoor access” 

Krassas suggested looking out for the following IOCs.

Access request log: POST /access/api/v1/registry/join from non-cluster hosts, especially followed immediately by POST /access/api/v1/tokens.

Access service log: the line Adding join key with kid: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 … means the blank join key is trusted (present on unpatched defaults).

Access audit / token store: unexpected non-expiring tokens with scope=applied-permissions/admin, audience=*, or service-subject admin tokens (sub=<svc>, scp=admin, aud=<access-id>).

Join JWTs whose kid claim equals SHA256("") (e3b0c442…b855).

It was not immediately clear how many organisations had publicly exposed their self-hosted Artifactory instances to the internet. Even those who haven't made themselves vulnerable to opportunistic attacks starting with automated scans for exposed instances will want to mitigate the risk of exploitation from someone on another beachhead.

*JFrog didn’t share a credit for the latter vulnerability and OpenAI didn’t cite it in its technical writeup; it is for now unclear how it was found.

The link has been copied!