CVE-2026-82329: JFrog Artifactory authentication bypass to admin

01

What the vulnerability does

JFrog's advisory describes it in one line: an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges. No account and no token are needed, only a network path to the instance.

CISA added CVE-2026-82329 to its Known Exploited Vulnerabilities catalog on 2 September 2026. Wiz and Kodem both report exploitation through an unauthenticated POST to /access/api/v1/registry/join that returns an admin-scoped token. After that, they report attackers reading the system configuration and the join key, creating admin users and long-lived tokens, and, in Kodem's report, uploading Groovy plugins and dropping a backdoor binary into /tmp.

02

Affected and fixed versions

From JFrog's security advisories page, as written there. JFrog says cloud customers are already protected; self-hosted instances need the upgrade.

• 7.161.0 > 7.161.19: fixed in 7.161.20.
• 7.146.0 > 7.146.36: fixed in 7.146.38.
• 7.133.0 > 7.133.28: fixed in 7.133.29.
• 7.125.0 > 7.125.19: fixed in 7.125.20.
• 7.117.0 > 7.117.27: fixed in 7.117.28.
• 7.111.4 up to 7.111.20: fixed in 7.111.21. JFrog's advisory table writes this range as 7.111.4 > 7.111.21; its release notes list the fix in 7.111.21, released 28 August 2026.
• The advisory lists no other release lines. If you run a line that is not listed, upgrade to one that is.

03

Find Artifactory in your clusters

If you run self-hosted Artifactory in Kubernetes, find the pods, read the version from the image tag, and check whether a Service or Ingress puts it in front of a network you do not control.

kubectl get pods -A -o custom-columns=\
NS:.metadata.namespace,POD:.metadata.name,\
'IMAGE:.spec.containers[*].image' | grep -i artifactory

kubectl get svc,ingress -A | grep -i artifactory

04

What configuration can show, and what it cannot

The Kubernetes API tells you which version runs and whether it is reachable. It cannot tell you whether someone already used the flaw, because the bypass itself is an HTTP request to Artifactory, not a process or a change to any Kubernetes object.

The reliable checks after the version are in Artifactory: requests to /access/api/v1/registry/join in its logs, admin users and tokens nobody created, and plugins nobody installed. Wiz and Kodem publish account-name patterns and addresses to search for.

Process activity matters for what comes next. Kodem describes attackers moving from admin access to code execution with Groovy plugins and a binary dropped in /tmp. A shell, a download tool or a binary started from /tmp inside the Artifactory pod shows up only in process activity on the node, not in the API.

05

Fixing it

Upgrade to the fixed version for your release line: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 or 7.161.20.

JFrog's workaround if you cannot upgrade yet: generate an additional join key from a random, hex-encoded value, add it to system.yaml under shared, security, additionalJoinKeys, and restart the Access service. CISA's KEV entry also points to its forensics triage requirements, so check the instance for the signs above as well as patching it.

06

Where Primod fits

Primod's per-node eBPF sensor records process executions and lineage per workload, so a shell or binary started under the Artifactory pod after a takeover shows up against that pod. It does not see the HTTP request that grants admin access; the logs and the upgrade cover that.