The Blank Join Key: How CVE-2026-82329 Lets Anyone Sign a JWT and Walk Out of JFrog Artifactory With Admin Tokens

Artifactory is one of those boxes we do not usually think about in the same breath as VPN concentrators or perimeter firewalls, which is precisely why the CVE-2026-82329 story stopped us this week. It sits behind the login page most engineers touch every morning, holding the binaries that go into every deployable image in a shop that ships software.

The specific twist we could not stop turning over: JFrog Access, the component that mints service tokens across an Artifactory cluster, was accepting join JSON Web Tokens signed with a "phantom" join key derived from the empty string on default installs. Not a leaked or weak key, but a key everyone in the world already has, sitting inside the trust store that decides which peers can ask for administrative credentials.

The chain, from a POST to a platform admin token

Here is what actually happens on a vulnerable Artifactory install. Affected self-hosted versions are anything before 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20 depending on which release branch the environment sits on, per SecurityWeek's coverage of the JFrog advisory.

When Artifactory first boots, JFrog Access initializes its verifier set of trusted join keys, the shared-secret table that decides whose HMAC signatures count as a legitimate cluster peer. On a default install with no explicit external join key configured, one of the entries ends up derived from an empty string. The signing key ID this produces is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which any engineer who has ever compared checksums will recognize on sight as the SHA-256 hash of the empty input. The proof is visible in the startup log line Adding join key with kid: e3b0c44...b855, documented in the reproducing Docker lab and evidence writeup on GitHub.

Once that KID is public knowledge, an unauthenticated attacker crafts a join JWT with alg=HS256, kid=SHA256(""), an iss and sub pointing at the target service identity, and a scope claim of admin. They POST it to /access/api/v1/registry/join. Artifactory looks up the KID, finds the entry backed by the empty-seeded signing key, validates the HMAC, and returns HTTP 201 with a SERVICE token scoped admin. That is the first request in the chain, and it needs no prior credentials at all.

The second request is a formality once the first one lands. The attacker POSTs the SERVICE token to /access/api/v1/tokens with scope=applied-permissions/admin and audience=*, and Artifactory returns a full platform access token good for any admin operation. From there, GET /artifactory/api/system/configuration hands back the server configuration and GET /access/api/v1/tokens enumerates every platform token ever issued along with users, groups, credential sets, and federated-access topology, which matches the watchTowr telemetry reported by BleepingComputer.

Why the class of bug matters more than the specific mistake

JFrog rates this at CVSS 9.8 and calls it improper authentication (CWE-287), which is correct and also a little abstract. A more operationally useful label is "a trust store that trusts something no one intended to trust." The whole point of a KID plus HMAC join is that the recipient supports many valid signers by looking up the right shared secret and failing closed if the KID is unknown. What went wrong here is that during default initialization, the empty string ended up as one of the entries in that table, so every well-formed JWT signed against the empty string now looks to the verifier like a legitimate cluster peer asking for admin credentials.

The patch, released as 7.161.20 and its equivalents on the other release branches, filters that entry out during initialization. On a patched build, the same forged JWT now returns HTTP 400: kid doesn't match any join keys, and the phantom line no longer appears in the startup log.

Why this slips past a normal blue team

Two properties of the exploit make it invisible to defenses that would flag a more familiar attack. First, no login attempt happens anywhere in the chain, which means there is no username to spray, no failed 401 to alert on, and no MFA prompt to notice. From the SIEM's point of view an unknown IP walks in, POSTs to two Artifactory API endpoints, and walks out with a valid platform token that then behaves like any other admin session for the rest of the intrusion.

Second, the traffic looks exactly like Artifactory doing its own job. Cluster peers legitimately POST to /access/api/v1/registry/join when they come online, and automation legitimately POSTs to /access/api/v1/tokens to rotate service tokens on a schedule. Volume detections that live on 4XX response rates or spikes see nothing, because both requests succeed with clean 2XX responses. The tell is not the request; it is who is making it, from where, and what KID it carries.

What to hunt for tonight

The strongest indicator is the phantom KID itself. Search the JFrog Access startup logs for the string Adding join key with kid: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If it is present, the instance was booted with the vulnerable trust-store state and every JWT signed against SHA-256 of the empty string was accepted while that state held; assume every admin token issued during that window is compromised until you can prove otherwise. On patched builds the log line does not appear, because the initialization path filters the entry before it ever reaches the verifier set.

On the network side, alert on any POST to /access/api/v1/registry/join sourced from outside the cluster's known peer IP range, especially any that returns HTTP 201 to a client with no prior authenticated session. Correlate against an immediate POST to /access/api/v1/tokens from the same source that requests applied-permissions/admin. That two-request pattern from a single external IP inside a short time window is not a shape legitimate Artifactory automation produces, and it is the same pattern watchTowr honeypots captured in the wild, per The Hacker News summary of the observed exploitation.

On the platform, list every entry under /access/api/v1/tokens and audit issuance timestamps against your change record. Any admin-scope token whose issued_at falls inside the window between Artifactory going live and the patch landing, and which does not match a change your automation or your admins actually made, is a rotation candidate. The techniques map cleanly to MITRE ATT&CK: initial access through a public-facing application at T1190, credential access via forged authentication material at T1606, and account discovery through the tokens and users APIs at T1087.

Patch, rotate, and prove the fix

Upgrade every self-hosted Artifactory instance to the fixed build on its release branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. JFrog Cloud instances were patched by the vendor already. If patching cannot happen inside the change window your SLA allows, put an authenticating reverse proxy or firewall rule in front of /access/api/v1/registry/join so unknown sources cannot reach the join endpoint at all, and treat that as a stopgap rather than a control. CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities catalog on September 2, 2026, so federal agencies are already on a remediation clock and everyone else should be treating this the same way.

After patching, do the parts nobody wants to do. Rotate every admin token issued before the fix, along with any repository credential, cloud secret, or integration token that a compromised admin could have read out of the Artifactory configuration. Regenerate any artifact an admin token could have replaced with a poisoned build, and diff a sample of high-value binaries against your last known-good checksum. Verify the fix held by replaying the forged JWT against the patched instance; the expected response is HTTP 400: kid doesn't match any join keys, and anything else means the trust-store rebuild did not run and the box is still shipping admin tokens to anyone who asks.

None of this is a one-off. The "trust store seeded with a value nobody meant to seed" pattern shows up wherever a service initializes with a defaulted secret. This is exactly the loop BlueTeamAutomation automates end to end with BASzy: continuous replay of the phantom-KID chain against your patched fleet, correlated against your EDR and SIEM so the question of whether your Artifactory has an unrecognized admin token has a live answer rather than a Slack thread.