# REPRO-2026-00341: JFrog Artifactory critical unauthenticated authentication bypass leading to administrative takeover

## Summary
Status: published
Severity: critical
CVSS: Unknown
CWE: CWE-287 Improper Authentication (Improper Authentication)
Type: security
Confidence: high

## Identifiers
REPRO ID: REPRO-2026-00341

CVE: CVE-2026-82329

## Package
Name: Unknown
Ecosystem: Unknown
Affected: Unknown
Fixed: Unknown

## Root Cause
# Root Cause Analysis — CVE-2026-82329: JFrog Artifactory Unauthenticated Authentication Bypass (Blank Join Key → Cluster-Join Service Admin Token)

## Summary

JFrog Artifactory's Access service, in default configuration, registered a **blank (empty-string) join key** in its "additional join keys" verification cache. Join keys are the HMAC secrets used to authenticate cluster-join requests at the **unauthenticated** endpoint `POST /access/api/v1/registry/join`. Because `JoinKeyUtils.getSigningKey("")` pkcs7-pads the empty key to the constant `32 × 0x20`, every vulnerable instance accepts a join JWT signed with an attacker-known key. A successful join returns a **never-expiring service admin token** (`scope: "admin"`) for an attacker-chosen service id, which is then usable to dump users, reset the built-in administrator's password, and mint platform-wide admin user tokens — full administrative takeover starting from **zero valid credentials**. Fixed in 7.146.38 (and corresponding branches) by rejecting blank join keys.

## Impact

- **Component**: JFrog Access service bundled with self-hosted JFrog Artifactory (verified on `artifactory-jcr` 7.146.25; internal Access 7.176.x).
- **Affected versions** (vendor advisory): 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.36, 7.161.0–7.161.19. Fixed: 7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20.
- **Risk**: CVSS 9.8 Critical (AV:N/AC:L/PR:N/UI:N). Any unauthenticated network attacker can obtain administrative control of the platform (user management, admin credential reset, admin token issuance), leading to full compromise of hosted artifacts and CI/CD supply chain.

## Impact Parity

- **Disclosed/claimed maximum impact**: unauthenticated authentication bypass → administrative takeover (`authz_bypass`, CVSS C:H/I:H/A:H).
- **Reproduced impact in this run**: identical — zero-credential admin takeover demonstrated end-to-end against the real product:
  1. `POST /access/api/v1/registry/join` with a JWT signed with HMAC-SHA256 key `20*32` → **HTTP 201**, service admin token (`sub=jfrt@cve202682329poc…, scp=admin`).
  2. `GET /access/api/v1/users` with that token → **HTTP 200**, full user list (including admin record).
  3. `PUT /access/api/v1/users/admin` → **HTTP 200**, built-in admin password reset to an attacker-chosen value (account takeover).
  4. `POST /access/api/v1/tokens {"username":"admin","scope":"applied-permissions/admin"}` → **HTTP 200**, admin user token (`sub=jfac@…/users/admin, scp=applied-permissions/admin, aud=*@*`).
  5. `GET /artifactory/api/system/info` (admin-only) with that token → **HTTP 200** with full system internals.
- **Parity: full.** No step used any pre-existing credential, account, or token; the chain starts from a raw unauthenticated HTTP request.

## Root Cause

The fix was isolated by binary-diffing `artifactory-jcr:7.146.36` (last vulnerable) against `artifactory-jcr:7.146.38` (fixed). The **entire** payload difference is the Access service (7.176.27 → 7.176.28), and within it exactly two security-relevant classes changed (the rest are manifests/UI bundles):

1. `org/jfrog/access/server/startup/JoinKeyAccess.class` — `tryResolveJoinKeys()`:
   ```diff
   - Arrays.stream(joinKey.get().split(",")).map(String::trim).forEach(jKey -> {
   + Arrays.stream(joinKey.get().split(",")).map(String::trim).filter(Strings::isNotBlank).forEach(jKey -> {
   ```
2. `org/jfrog/access/token/JoinKeyHashPair.class` — constructor:
   ```diff
   + if (joinKey == null || joinKey.isBlank()) {
   +     throw new IllegalArgumentException("Join key must not be null or blank");
   + }
   ```

Why the bug fires in **default configuration**:

- `JoinKeyAccess.tryResolveJoinKeys()` resolves `shared.security.additionalJoinKeys`. When unset (default), `resolveJoinKeys()` returns `""` wrapped in a vavr `Try`. The guard `if (!joinKey.isEmpty())` calls **`Try.isEmpty()`**, which tests for failure/null — **not** string emptiness — so the empty default proceeds to `"".split(",")` → `[""]`, and a `JoinKeyHashPair("")` (blank join key) is registered in the additional-join-keys map under `kid = sha256("") = e3b0c442…b855`.
- `JoinKeyUtils.getSigningKey("")` → `hexDecodeAndPad("", 32)` → pkcs7-pads to the constant 32-byte key `0x20 0x20 … 0x20` — **publicly derivable, identical on every default installation**.
- The unauthenticated `RegistryNoAuthResource.join` (`POST /access/api/v1/registry/join`) → `JoinServiceImpl.getValidatedJwtToken()` → `getJoinKey(jwt)` → `joinKeyAccess.getTokenSignatureVerifiers(kid)`: with no `kid` claim it tries the main join key **plus every additional join key** (including the blank one); with `kid=e3b0c442…` it selects the blank key directly. An HS256 JWT signed with `32 × 0x20` therefore verifies.
- On verification, `ServiceTokenProviderImpl.getToken(serviceId)` issues `TokenSpec … .scope("admin") .expiresIn(0)` via `createInternalTokenWithoutAuthAndNotify` — a platform-trusted, never-expiring **service admin token** for the attacker-chosen `service_id` claim.

So one unauthenticated POST yields admin-level identity; trivial follow-ups (`PUT /access/api/v1/users/admin`, `POST /access/api/v1/tokens`) convert it into full administrative takeover of Artifactory.

- Fix: JFrog advisory <https://docs.jfrog.com/releases/docs/jfrog-security-advisories> (CVE-2026-82329, published 2026-08-28). Patch is the two-class change above (blank-key rejection), present in Access 7.176.28 / Artifactory 7.146.38.

## Reproduction Steps

1. `bundle/repro/reproduction_steps.sh` (self-contained; requires Docker, curl, python3).
2. The script:
   - Pulls `releases-docker.jfrog.io/jfrog/artifactory-jcr:7.146.25` (vulnerable), `:7.146.38` (fixed), and `postgres:16-alpine` (7.146.x refuses to start on the legacy embedded Derby DB).
   - Boots each Artifactory with a default-config `system.yaml` (external PostgreSQL only; **no** join key / additional join keys configured) plus a generated `master.key`, using `docker create` + `docker cp` + `docker start` (single-file bind mounts break JFrog's atomic `system.yaml` rewrite).
   - Runs `bundle/repro/exploit_join_bypass.py` against each instance: blank-key JWT join, Access admin operations, admin password reset, admin token mint, admin-only Artifactory API call, plus built-in controls (anonymous token mint must 401; wrong-signature join must 400).
   - Writes per-run evidence JSON, image IDs, version files, and `runtime_manifest.json`.
3. Expected evidence: vulnerable instance → join HTTP 201 with `scp=admin` token, admin takeover steps all 200, exploit JSON `"exploited": true`, script exit 0; fixed instance → join HTTP 400 (`JWT's signature does not match the server's join key`), `"exploited": false`.

## Evidence

- `bundle/artifacts/http/vuln_exploit.json` — full request/response transcript of the successful exploit against 7.146.25 (join 201 + `scp=admin` token claims; users dump 200; admin password reset 200; admin user token claims `sub=jfac@…/users/admin, scp=applied-permissions/admin`; `/artifactory/api/system/info` 200; anonymous controls 401; wrong-signature join 400).
- `bundle/artifacts/http/fixed_exploit.json` — identical attack against 7.146.38 rejected at the join step (HTTP 400, `"exploited": false`).
- `bundle/artifacts/diff/JoinKeyAccess.diff`, `bundle/artifacts/diff/JoinKeyHashPair.diff` (+ full decompiled classes) — the two-class security patch between 7.146.36 and 7.146.38.
- `bundle/logs/reproduction_steps.log` — orchestration log; `bundle/logs/art-{vuln,fixed}-docker.log`, `art-{vuln,fixed}-access-join.log` — service-side logs.
- `bundle/artifacts/vuln_image_id.txt` / `fixed_image_id.txt`, `vuln_version.txt` / `fixed_version.txt` — tested target identity.
- Environment: Docker (rootless), postgres:16-alpine sidecar, `artifactory-jcr:7.146.25` (Access 7.176.15) vs `artifactory-jcr:7.146.38` (Access 7.176.28), linux x86_64.

## Recommendations / Next Steps

- **Upgrade** self-hosted Artifactory to 7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20 or later (per branch).
- Interim mitigation: restrict network access to the Access/router endpoints (`/access/api/v1/registry/*`) to trusted networks; audit `access_nodes`/`access_audit` for unexpected service registrations and tokens (`scp=admin` with unknown `jfrt@…` subjects), and rotate the join key, master key, and the admin password after upgrading.
- Fix approach (already shipped): reject null/blank join keys in `JoinKeyHashPair` and filter blank entries when parsing `additionalJoinKeys`. Additionally consider requiring a `kid` and binding join tokens to `node_id`/topology registration, and rate-limiting/auditing the no-auth join endpoint.
- Testing: regression test that a default install has **no** additional join keys (`/access/api/v1/system/security/join_key` children) and that `registry/join` rejects empty-key HMAC JWTs.

## Additional Notes

- Idempotency: the script tears down and recreates all containers/network each run and was executed twice consecutively with identical results (vulnerable exploited, fixed blocked). Each run generates fresh master keys, databases, node ids, and attacker service ids.
- Limitations: verification used the JCR (Container Registry) image; repository-management REST (`/api/repositories`) is Pro-gated in JCR, so admin takeover was demonstrated via Access admin APIs + admin token mint + the admin-only `/artifactory/api/system/info` endpoint instead of repository creation. The vulnerable code lives in the shared Access service, so Pro/ProX distributions are equally affected.
- The 30-second `iat` freshness check on join tokens (`MAX_REQUEST_AGE_IN_SECONDS`) is honored by minting the JWT at exploit time.


## Reproduction Details
Reproduced: 2026-09-01T13:05:52.523Z
Duration: 8715 seconds
Tool calls: 255
Turns: Unknown
Handoffs: 2


## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00341

    pruva-verify CVE-2026-82329

Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00341&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00341/artifacts/bundle/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-82329
- Source: https://jfrog.com/help/r/jfrog-release-information/artifactory-security-fixes

## Artifacts
- bundle/repro/rca_report.md (analysis, 9837 bytes)
- bundle/repro/reproduction_steps.sh (reproduction_script, 10186 bytes)
- bundle/vuln_variant/rca_report.md (analysis, 11976 bytes)
- bundle/vuln_variant/reproduction_steps.sh (reproduction_script, 7449 bytes)
- bundle/artifacts/diff/JoinKeyAccess.diff (other, 792 bytes)
- bundle/artifacts/diff/JoinKeyHashPair.diff (other, 482 bytes)
- bundle/artifacts/fixed_image_id.txt (other, 130 bytes)
- bundle/artifacts/fixed_version.txt (other, 178 bytes)
- bundle/artifacts/http/fixed_exploit.json (other, 1043 bytes)
- bundle/artifacts/http/vuln_exploit.json (other, 5592 bytes)
- bundle/artifacts/vuln_image_id.txt (other, 130 bytes)
- bundle/artifacts/vuln_version.txt (other, 178 bytes)
- bundle/logs/reproduction_steps.log (log, 3450 bytes)
- bundle/repro/exploit_join_bypass.py (script, 7144 bytes)
- bundle/repro/runtime_manifest.json (other, 1951 bytes)
- bundle/repro/validation_verdict.json (other, 1554 bytes)
- bundle/artifacts/variant_http/fixed_join-kid.json (other, 1194 bytes)
- bundle/artifacts/variant_http/fixed_router-override.json (other, 1123 bytes)
- bundle/artifacts/variant_http/fixed_router.json (other, 1114 bytes)
- bundle/artifacts/variant_http/vuln_join-kid.json (other, 4890 bytes)
- bundle/artifacts/variant_http/vuln_router-override.json (other, 6246 bytes)
- bundle/artifacts/variant_http/vuln_router.json (other, 6237 bytes)
- bundle/logs/vuln_variant/fixed_version.txt (other, 178 bytes)
- bundle/logs/vuln_variant/reproduction_steps.log (log, 10117 bytes)
- bundle/logs/vuln_variant/vuln_version.txt (other, 178 bytes)
- bundle/vuln_variant/decomp/src-vuln/org/jfrog/access/server/rest/resource/registry/RegistryNoAuthResource.java (other, 2558 bytes)
- bundle/vuln_variant/exploit_join_router_variant.py (script, 7871 bytes)
- bundle/vuln_variant/patch_analysis.md (documentation, 4562 bytes)
- bundle/vuln_variant/root_cause_equivalence.json (other, 3149 bytes)
- bundle/vuln_variant/runtime_manifest.json (other, 2660 bytes)
- bundle/vuln_variant/source_identity.json (other, 1596 bytes)
- bundle/vuln_variant/validation_verdict.json (other, 3761 bytes)
- bundle/vuln_variant/variant_manifest.json (other, 5294 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00341
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00341/artifacts/bundle/repro/reproduction_steps.sh
- Web: https://www.pruva.dev/reproductions/REPRO-2026-00341

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://www.pruva.dev