CVE-2026-82329 | JFrog Artifactory Blank-Join-Key Authentication Bypass (Unauthenticated Admin Takeover)

1. Introduction

This document illustrates an unauthenticated authentication bypass vulnerability in JFrog Artifactory – a widely deployed universal artifact repository manager used by thousands of enterprises across the financial, government, and technology sectors. Under the product’s default configuration, a remote attacker with no credentials can obtain a never-expiring platform-wide administrative token and gain full control of the instance in a single network request. The vulnerability carries a CVSS score of 9.8 (Critical) and has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, indicating confirmed active exploitation in the wild.

2. JFrog Artifactory Description

JFrog Artifactory is a universal binary repository manager that stores, manages, and distributes software artifacts across all major package formats including Maven, npm, PyPI, Docker, Helm, and more. It is available in open-source (JFrog Container Registry), Pro, and Enterprise tiers, and is commonly deployed on-premises or in private cloud environments as a central hub in DevOps pipelines. Artifactory serves as the authoritative artifact store for build pipelines, release trains, and container image distribution in large-scale software engineering organizations.

3. Vulnerability Severity

4. Scope of Impact

Affected version ranges (default configuration — shared.security.additionalJoinKeys not explicitly set):

• 7.111.4 – 7.111.20
• 7.117.0 – 7.117.27
• 7.125.0 – 7.125.19
• 7.133.0 – 7.133.28
• 7.146.0 – 7.146.37
• 7.161.0 – 7.161.19

Fixed versions (first fixed on each branch):

• 7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20

5. Where is the vulnerability present?

The vulnerability originates in the JFrog Access service that is bundled with every Artifactory self-hosted installation. Access exposes an internal cluster-management endpoint — POST /access/api/v1/registry/join — that allows Artifactory nodes to register themselves into a cluster by presenting a HS256-signed JSON Web Token (JWT). This endpoint is a no-authentication route by design, as it is intended to be reached only by trusted internal cluster peers.

The flaw arises in how Access resolves its join key when none is explicitly configured. When shared.security.additionalJoinKeys is left unset (the default for every stock installation), a vavr Try.isEmpty() guard in JoinKeyAccess.tryResolveJoinKeys() tests for a resolution failure rather than for string emptiness. As a result, the blank string “” is passed through and registered as a valid join key. The internal function JoinKeyUtils.getSigningKey(“”) then pads this empty value using PKCS#7 into the constant 32-byte HMAC secret 0x20 × 32 — thirty-two space characters — which is a publicly derivable value that is identical on every default Artifactory install worldwide.

Because the /access/api/v1/registry/join endpoint verifies incoming cluster-join JWTs against this well-known constant key, any unauthenticated network attacker can forge a valid join JWT by signing it with 32 space characters. The Access service verifies the signature successfully and responds with a never-expiring service token carrying scope=admin — granting the attacker the same privileges as a legitimate Artifactory cluster node, which translates to full platform-wide administrative access.

The vulnerable endpoint accepts a raw JWT as the request body with Content-Type: text/plain and enforces only a 30-second freshness window on the iat (issued-at) claim. No credentials, network secrets, or prior reconnaissance are required beyond basic network reachability to the Artifactory host.

6. Risk

An attacker who successfully exploits CVE-2026-82329 receives a never-expiring scope=admin service token in a single unauthenticated HTTP request. This token grants full access to every JFrog Access administrative Application Programming Interface (API), including the ability to enumerate all user accounts, reset any user’s password, mint additional admin-scoped tokens, and read admin-only Artifactory system internals such as version strings, Java Virtual Machine (JVM) uptime, CPU core count, and file descriptor state.

The most severe immediate impact is full administrative takeover of the Artifactory instance. By resetting the built-in admin account’s password to an attacker-chosen value and then authenticating with those credentials, the adversary obtains a persistent and authenticated administrative session that survives any restart of the compromised service. From this position the attacker can trojanize build artifacts, inject malicious packages into every repository hosted on the instance, and poison downstream CI/CD pipelines that consume those artifacts — turning a single unauthenticated request into a supply chain compromise affecting every consumer of the organization’s artifacts.

Because Artifactory commonly stores private keys, API tokens, signing certificates, and deployment secrets alongside build artifacts, a successful takeover also represents a broad secrets exfiltration event. Lateral movement to cloud environments, container registries, and production deployment targets is a realistic follow-on consequence wherever those credentials are consumed by automated pipelines. In multi-tenant or enterprise configurations, a single compromised Artifactory instance may serve dozens of internal teams and products, significantly widening the blast radius.

Persistence is straightforward to establish: the attacker can create additional administrator accounts, revoke legitimate users’ tokens, and modify repository permissions — all through the Access API — before any defensive action is taken. Given that the vulnerability requires no authentication, no prior user interaction, and no special network position beyond basic reachability, the practical exploitability on any exposed internet-facing or intranet-facing Artifactory instance is extremely high.

7. Mitigation

• Upgrade immediately to a fixed version on your branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. The fix in JFrog Access 7.176.28 causes JoinKeyHashPair to throw on a blank key and tryResolveJoinKeys to filter blank entries — the join endpoint returns HTTP 400 on any blank-key-signed JWT.
• Workaround (if immediate upgrade is not possible): Set shared.security.additionalJoinKeys to a strong, randomly generated hex value (e.g., via container environment variable JF_SHARED_SECURITY_ADDITIONALJOINKEYS) and restart the Access service. This replaces the derivable blank key with an unknown secret, blocking the exploit.
• Post-upgrade hardening: Rotate the join key, master key, and admin account password after applying the patch. Audit the access_nodes table and the Access audit log for unexpected jfrt@… service registrations and any scp=admin service tokens issued before the patch was applied.
• Network exposure: Restrict network access to /access/api/v1/registry/* at the firewall or load-balancer level so the join endpoint is not reachable from untrusted network segments.
• CISA KEV deadline: Federal agencies and organizations following CISA guidance were required to remediate this vulnerability by 2026-09-05.

8. Exploit Implementation

Attack Scenario

The following demonstration is performed against a Docker-based Linux lab environment that runs the official JFrog Container Registry image at the vulnerable version (7.146.25) on port 8100, alongside a patched instance (7.146.38) on port 8101 for comparison. The lab uses real product images in stock default configuration — no credentials, seeds, or special application settings are needed; the default install is the vulnerable state.

Prerequisites:

• Docker and docker compose (lab already running)
• nuclei v3.x
• python3 with requests (auto-installed by the exploit script)
• curl

Exploitation

1. Confirm the vulnerable Artifactory instance is reachable.

This confirms the target is online and the Artifactory service has completed its initialization. The ping endpoint returns OK for any reachable instance without requiring credentials.

2. Run the Nuclei template to detect CVE-2026-82329.

The Nuclei template sends a blank-key-signed join JWT to the target and checks for an HTTP 201 response containing a service token. A match confirms the instance accepts the blank key. The same template against the patched instance (port 8101) produces no findings and an HTTP 400 response.

3. Execute the full exploitation chain with the Python exploit script.

The script forges an HS256 JWT signed with the 32-byte blank key (0x20 × 32), sends it to POST /access/api/v1/registry/join, and receives a never-expiring scope=admin service token. It then uses this token to enumerate all user accounts via GET /access/api/v1/users, confirming the built-in admin account is present.

4. Observe the admin password reset and session verification.

The exploit updates the admin record via PUT /access/api/v1/users/admin using the service token, sets the password to an attacker-chosen value, and immediately verifies the takeover by authenticating as admin with that password. A successful HTTP 200 on GET /artifactory/api/system confirms the session is valid.

5. Mint a platform-wide admin access token and read admin-only system internals.

The exploit script prints the minted admin access and refresh tokens, reads artifactory.version from the admin-only /artifactory/api/system/version endpoint, and reads JVM and process internals from /artifactory/api/system/info. The script exits 0. 

For authorized security research and education only. Run this lab exclusively against your own local instances.