The Default Join Key That Let Attackers Mint Admin Tokens on JFrog Artifactory

A package repository that hands out administrator credentials to an unauthenticated caller is a supply-chain problem, not a web-application problem. That is the situation JFrog disclosed on 28 August 2026 for self-hosted Artifactory instances, and by 1 September attackers were already using it in the wild.

What the vulnerability is

The flaw is tracked as CVE-2026-82329 and carries a CVSS v3.1 score of 9.8. JFrog describes it as an authentication bypass in the JFrog Access component, the subsystem that issues and validates identity and permission material. In a default configuration, an unauthenticated attacker with network access can obtain administrator privileges.
The mechanism reported by watchTowr involves the join key that Artifactory's access layer uses to trust cluster members. A default installation ships with an empty string in the set of trusted join keys. When the signing-key lookup is called with that empty value, it returns a predictable 32-byte result. An attacker who knows that value can sign a legitimate-looking join JWT and use it to mint a platform administrator token.

Why the default configuration matters

The severity does not come from a clever exploit chain. It comes from the fact that the vulnerable state is the state a fresh installation starts in. Administrators who never customized jfrog-access.bootstrap.json to set a non-empty join key were exposed without any additional misconfiguration.
watchTowr's Attacker Eye honeypot network observed the activity on 1 September, three days after disclosure. The observed behavior included forging administrator tokens and enumerating users, groups, credential sets and federated access topology. That enumeration pattern is consistent with reconnaissance before lateral movement, not opportunistic scanning.

Impact on the software supply chain

Artifactory sits between developers, build systems and production deployment. It stores and distributes the packages, binaries and build artifacts that downstream systems already trust and pull automatically. Collin Hogue-Spears of Black Duck framed this as a zero-trust problem: administrative access to Artifactory reaches the published artifacts that downstream systems consume without further review.
Once an attacker holds administrator rights, several outcomes become possible. Cached packages can be replaced, which means a build that pulls from the repository may compile tampered dependencies. Publishing credentials stored or used by the repository can be abused. Build pipelines can be modified to push changes to downstream customers. The compromise is not limited to the single Artifactory host.
James Edwards of Keeper Security put the same point directly: bypassing authentication at the artifact layer is a first-tier vulnerability in the supply chain, and any vulnerable instance reachable over the network should be treated as compromised.

A related chain worth knowing

JFrog also addressed two further issues that attackers have chained with the authentication bypass. CVE-2026-42018 is an improper authentication problem in which an unauthenticated caller can obtain an anonymous user token that reaches sensitive artifacts and repository data, even when anonymous access is disabled on the instance. CVE-2026-42016 is insufficient token validation: the signature and issuer are checked, but the token scope is not properly constrained, so a low-privilege token can be used to escalate.
Reported observations describe a sequence: obtain a low-privilege token through the authentication defect, escalate through the scope-validation defect, then install a plugin to execute arbitrary code, create persistent accounts, and exfiltrate configuration and cluster keys. CISA added two of the related vulnerabilities to its Known Exploited Vulnerabilities catalog on 12 September, with a federal remediation deadline of 25 September.

Affected versions and fixes

JFrog published fixed versions for the affected maintenance branches:

7.161.0 to 7.161.19: upgrade to 7.161.20
7.146.0 to 7.146.36: upgrade to 7.146.38
7.133.0 to 7.133.28: upgrade to 7.133.29
7.125.0 to 7.125.19: upgrade to 7.125.20
7.117.0 to 7.117.27: upgrade to 7.117.28
Below 7.111.21: upgrade to 7.111.21 JFrog states that affected cloud environments were already updated and require no customer action. Self-hosted instances do.

Defensive implications

Patching closes the entry point, but it does not remove tokens an attacker may already have created. JFrog supports both expiring and non-expiring access tokens, so an upgrade alone can leave a forged administrator token valid. Administrators should review issued tokens and revoke anything unknown or suspicious, rotate credentials, and audit for administrator accounts they did not create.
A practical verification order:

Confirm the running version against the fixed-version list.
List users and look for unfamiliar, recently created administrator accounts.
Inspect the plugin directory, since malicious plugins are the primary mechanism for code execution in this attack.
Review access logs for token endpoint calls and administrative actions, focusing on unusual hours and unfamiliar source addresses. Two details cause mistakes during this check. Container deployments must be inspected from inside the container, and log paths differ by installation method. If an unfamiliar administrator account or suspicious plugin file is found, disabling and preserving evidence is more useful than deleting it, because the artifact supports later investigation.

Limits of the current picture

The reported observations establish that exploitation occurred and describe the general behavior. They do not establish how many organizations were affected, whether every observed instance reached full administrator takeover, or who the operators were. watchTowr noted that large-scale scanning and bulk exploitation had not yet appeared at the time of its report, while cautioning that this could change. Those are open questions, not settled facts.