← Back to Feed CACHED · 2026-09-03 01:57:17 · CACHE_KEY CVE-2026-82329
CVE-2026-82329 · CWE-287 · Disclosed 2026-08-28

JFrog Artifactory contains an authentication weakness that

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone left the master key under the doormat of the warehouse that ships every package your company builds

CVE-2026-82329 is an authentication bypass in JFrog Artifactory's Access component — the subsystem responsible for issuing and validating credentials. In default, out-of-the-box configurations of self-hosted Artifactory, the join key used to bootstrap trust between platform services is either absent or predictable (a so-called "phantom" join key). An unauthenticated attacker with network access can abuse this to forge administrator-level access tokens. Affected versions span multiple release branches prior to patched versions 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20. JFrog SaaS (cloud-hosted) instances are not affected — only self-managed deployments.

The vendor rated this CVSS 9.8 CRITICAL, and for once the vendor score is exactly right. The attack is unauthenticated, remote, low-complexity, requires no user interaction, and targets the default configuration. The blast radius isn't just the Artifactory host — it's every downstream build pipeline, container image, AI model artifact, and release binary that trusts that repository. Active exploitation was observed by watchTowr within 72 hours of disclosure. CISA added it to the KEV catalog. There is nothing to downgrade here.

"Unauthenticated admin token forgery in your artifact repo — supply chain is wide open."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify internet-facing or network-reachable Artifactory

The attacker locates a self-hosted Artifactory instance via Shodan, Censys, or internal network scanning. Artifactory commonly exposes its web UI and REST API on ports 8081/8082. Many organizations expose Artifactory externally for developer and CI/CD pull access.
Conditions required:
  • Target runs self-hosted JFrog Artifactory on a vulnerable version
  • Instance is network-reachable (internet or internal network)
Where this breaks in practice:
  • Instances behind VPN or zero-trust overlay are not directly reachable from the internet
Detection/coverage: Shodan/Censys queries for X-Artifactory-Id header or /artifactory/ path. GreyNoise tags may track scanning for Artifactory endpoints.
STEP 02

Exploit phantom join key to forge admin token

The attacker sends unauthenticated HTTP requests to the JFrog Access API, exploiting the default/absent join key to request an administrator-level access token. No credentials, cookies, or prior session are needed. Public PoC scripts (e.g., fankh/vulnerability-poc on GitHub) automate this in a single command.
Conditions required:
  • Artifactory uses default configuration (join key not manually rotated or hardened)
Where this breaks in practice:
  • Organizations that followed JFrog hardening guides and set a custom join key are not vulnerable — but this is a minority of deployments
Detection/coverage: WAF rules inspecting POST requests to /access/api/v1/ endpoints for token-creation payloads. Audit logs showing token creation events without a preceding valid authentication session.
STEP 03

Enumerate environment via admin API

With a forged admin token, the attacker calls management APIs to enumerate users, groups, permission targets, credential stores, federated access relationships, and repository metadata. This reveals the full topology of the software supply chain, including which CI/CD systems push and pull artifacts.
Conditions required:
  • Valid admin token from Step 2
Where this breaks in practice:
  • None — this is normal admin API usage, difficult to distinguish from legitimate activity without behavioral baselining
Detection/coverage: SIEM alerting on admin-level API calls from unexpected source IPs or outside business-hours windows. JFrog Access audit log correlation.
STEP 04

Poison artifacts or exfiltrate secrets

The attacker can now replace trusted artifacts (Maven JARs, npm packages, Docker images, Helm charts, ML models) with backdoored versions, inject malicious layers into container images, or exfiltrate stored credentials and API keys. Every downstream build or deployment that pulls from this repository automatically trusts the poisoned content. This is a textbook supply-chain pivot.
Conditions required:
  • Admin access to Artifactory (achieved in Step 2)
  • Downstream CI/CD pipelines pull from this Artifactory instance
Where this breaks in practice:
  • Artifact integrity verification (e.g., Sigstore/cosign, GPG-signed packages) would detect tampering — but adoption remains low
  • Immutable repository policies, if enabled, prevent overwrites of existing artifacts
Detection/coverage: File-integrity monitoring on critical repositories. Checksum drift alerts. Binary composition analysis (SCA) on downstream builds detecting unexpected changes.
STEP 05

Persist via additional tokens and backdoor accounts

The attacker creates additional admin tokens or service accounts to maintain persistent access even after the vulnerability is patched. JFrog has confirmed that patching alone does not revoke previously minted tokens — manual token audit and revocation is required.
Conditions required:
  • Admin access (from Step 2)
Where this breaks in practice:
  • Defenders who rotate all tokens and audit accounts post-patch will catch this — but many will miss it
Detection/coverage: Post-incident token inventory: compare all active tokens against known legitimate issuances. Alert on tokens created between disclosure date (Aug 28) and patch application.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationYES — confirmed active. watchTowr reported exploitation by Sep 1, 2026, just 3 days after disclosure. Attackers observed minting admin tokens and enumerating federated access topologies. Covered by BleepingComputer, The Hacker News, Dark Reading.
KEV statusListed. Added to CISA Known Exploited Vulnerabilities catalog.
Proof-of-conceptPublic. PoC available at fankh/vulnerability-poc on GitHub. Trivially reproducible per multiple researchers. Single HTTP request to forge token.
EPSS0.01242 (top ~5% activity probability). Expect this to climb rapidly given active exploitation and public PoC.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — Network-attackable, low complexity, no privileges, no interaction. Full CIA impact. This vector is accurate.
Affected versionsAll self-hosted JFrog Artifactory versions across branches prior to 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20. JFrog SaaS/Cloud is not affected.
Fixed versions7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 (select the patch matching your release branch).
Exposure dataJFrog Artifactory is used by 5,000+ organizations globally, 58% large enterprise (10,000+ employees). Many expose Artifactory externally for developer artifact pulls. Exact Shodan/Censys counts not yet published but scanning activity is confirmed.
Disclosure date2026-08-28 (JFrog advisory + patch release simultaneous).
Reporting researcherCredited to watchTowr for in-the-wild discovery; JFrog internal security team for advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

The single most decisive factor is supply-chain pivot via artifact repository — Artifactory is, by definition, the trusted source for every binary artifact downstream CI/CD pipelines consume, and unauthenticated admin access means an attacker can silently poison builds at fleet scale. Active exploitation within 72 hours of disclosure with a public PoC and KEV listing eliminates any theoretical friction discount.

HIGH Vulnerability severity and exploitability assessment
HIGH Active exploitation status (KEV + watchTowr telemetry)
MEDIUM Exact fraction of self-hosted instances exposed to the internet vs. internal-only

Why this verdict

  • Unauthenticated remote, default config: The attack requires zero credentials, zero user interaction, and targets the out-of-the-box configuration. There is no friction from authentication requirements — PR:N is as bad as it gets.
  • Role multiplier: JFrog Artifactory is a canonical supply-chain artifact store — it sits in the CI/CD + artifact stores high-value role category. ≥90% of Artifactory installations serve exactly this role (that's the product's entire purpose). A compromised Artifactory instance yields supply-chain-scale blast radius: poisoned artifacts propagate to every downstream build, container deployment, and release pipeline that pulls from it. The chain succeeds in the high-value role by definition — verdict floor is CRITICAL.
  • Active exploitation + KEV: CISA KEV-listed with observed in-the-wild exploitation within 72 hours of disclosure. watchTowr confirmed attackers forging admin tokens and enumerating environments. Public PoC available. This is not theoretical.
  • Patch does not revoke tokens: Even after upgrading, previously minted attacker tokens remain valid. This extends the exploitation window and increases the blast radius for organizations that patch without auditing tokens.
  • No meaningful friction: The only friction point — network reachability — is weak. Many Artifactory instances are intentionally internet-facing for developer and CI/CD access. Even internal-only instances are reachable post-initial-access, and the supply-chain poisoning impact magnifies any internal compromise.

Why not higher?

The score is already at 9.8 CRITICAL, the maximum practical severity. There is no higher bucket. The only nuance preventing a theoretical 10.0 is Scope:Unchanged in the CVSS vector — the vulnerability itself doesn't change authorization scope, though the real-world supply-chain impact clearly crosses trust boundaries.

Why not lower?

Downgrading would require evidence that the attack needs authentication, unusual configuration, or that the affected component occupies a low-value role. None of these apply. Artifactory IS the artifact store — it's not occasionally deployed in a high-value role, it IS the high-value role. The default config is vulnerable. Active exploitation is confirmed. Lowering this below CRITICAL would be indefensible.

05 · Compensating Control

What to do — in priority order.

  1. Block unauthenticated access to JFrog Access API endpoints immediately — Apply WAF or reverse-proxy rules to deny unauthenticated requests to /access/api/v1/ token-creation endpoints. This is a same-day action — deploy within the noisgate CRITICAL mitigation SLA of 3 days, but ideally within hours given active exploitation.
  2. Restrict network exposure of Artifactory to trusted CIDR ranges — If Artifactory is internet-facing, place it behind VPN, ZTNA, or IP allowlist immediately. Only CI/CD runners and authenticated developers should reach it. Deploy within 3 days.
  3. Rotate the join key to a strong, manually-set value — Even before patching, setting a custom join key in $JFROG_HOME/artifactory/var/etc/access/access.config.latest.yml eliminates the phantom join key attack vector. This is the most targeted compensating control.
  4. Audit and revoke all access tokens created after Aug 28, 2026 — Patching does NOT invalidate attacker-minted tokens. Use the Artifactory admin API to list all tokens, identify any created between Aug 28 and your patch date from unexpected sources, and revoke them. This is mandatory post-patch hygiene.
  5. Enable immutable repository policies on critical release repos — Prevents overwrites of existing artifacts, limiting the supply-chain poisoning vector even if admin access is obtained. Deploy within 3 days for production release repositories.
What doesn't work
  • Standard network IDS/IPS signatures alone — the exploit uses legitimate HTTP POST requests to standard API endpoints; without Artifactory-specific payload inspection, generic IDS will not flag it.
  • Patching without token revocation — the patch closes the door but does not kick out intruders already inside. Previously minted admin tokens remain valid indefinitely until manually revoked.
  • JFrog SaaS migration as an emergency response — while SaaS is not affected, migrating a production artifact repository is a multi-week project, not a viable compensating control for an actively exploited CVE.
06 · Verification

Crowdsourced verification payload.

Run this script on the Artifactory host or any machine with curl and network access to the Artifactory instance. Invoke as: bash check_cve_2026_82329.sh https://artifactory.example.com:8082. No authentication required (it checks the version endpoint which is typically unauthenticated).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_82329.sh — Detect CVE-2026-82329 vulnerable JFrog Artifactory
# Usage: bash check_cve_2026_82329.sh <ARTIFACTORY_BASE_URL>
# Example: bash check_cve_2026_82329.sh https://artifactory.example.com:8082
# Requires: curl, grep, sort (standard coreutils)
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <ARTIFACTORY_BASE_URL>"
  exit 2
fi

BASE_URL="${1%/}"

# Patched versions per branch
PATCHED_VERSIONS="7.111.21 7.117.28 7.125.20 7.133.29 7.146.38 7.161.20"

# Fetch version from system info endpoint
VERSION=$(curl -sk --max-time 10 "${BASE_URL}/artifactory/api/system/version" 2>/dev/null | grep -oP '"version"\s*:\s*"\K[0-9.]+' || true)

if [ -z "$VERSION" ]; then
  # Try alternative endpoint
  VERSION=$(curl -sk --max-time 10 "${BASE_URL}/router/api/v1/system/health" 2>/dev/null | grep -oP '"version"\s*:\s*"\K[0-9.]+' || true)
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not retrieve Artifactory version from ${BASE_URL}"
  echo "Verify the URL and ensure the system info endpoint is accessible."
  exit 2
fi

echo "Detected Artifactory version: ${VERSION}"

# Extract major.minor branch (first two octets of 3-part version)
IFS='.' read -r V_MAJ V_MIN V_PATCH <<< "$VERSION"
BRANCH="${V_MAJ}.${V_MIN}"

# Find the patched version for this branch
PATCHED=""
for PV in $PATCHED_VERSIONS; do
  IFS='.' read -r P_MAJ P_MIN P_PATCH <<< "$PV"
  if [ "$V_MAJ" = "$P_MAJ" ] && [ "$V_MIN" = "$P_MIN" ]; then
    PATCHED="$PV"
    break
  fi
done

if [ -z "$PATCHED" ]; then
  # Version branch not in known patched list — could be older unsupported or newer
  if [ "$V_MAJ" -lt 7 ]; then
    echo "VULNERABLE — Version ${VERSION} is on an unsupported major branch (pre-7.x), likely affected."
    exit 0
  fi
  if [ "$V_MAJ" -eq 7 ] && [ "$V_MIN" -gt 161 ]; then
    echo "PATCHED — Version ${VERSION} is on a branch newer than all known affected branches."
    exit 1
  fi
  echo "UNKNOWN — Version ${VERSION} (branch ${BRANCH}) not in known affected/patched matrix."
  echo "Manually verify against JFrog advisory."
  exit 2
fi

# Compare patch level
if [ "$V_PATCH" -ge "$P_PATCH" ]; then
  echo "PATCHED — Version ${VERSION} meets or exceeds patched version ${PATCHED}."
  exit 1
else
  echo "VULNERABLE — Version ${VERSION} is below patched version ${PATCHED} for branch ${BRANCH}."
  echo "Upgrade immediately. CVE-2026-82329 is actively exploited (KEV-listed)."
  exit 0
fi
07 · Bottom Line

If you remember one thing.

TL;DR
This is an active-fire emergency. CVE-2026-82329 is being exploited in the wild *right now* against internet-facing Artifactory instances, with attackers minting admin tokens and surveying your supply chain. Under the noisgate mitigation SLA for CRITICAL, you have ≤ 3 days to apply compensating controls — but given KEV listing and active exploitation, treat this as patch/mitigate immediately, within hours. Monday morning action: (1) Identify every self-hosted Artifactory instance across your estate, (2) block unauthenticated access to Access API endpoints via WAF/reverse proxy *today*, (3) rotate join keys on all instances, (4) apply the vendor patch for your branch (7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20), and (5) audit and revoke all access tokens created after Aug 28 — patching alone does NOT invalidate attacker-minted tokens. Under the noisgate remediation SLA, full patching must be complete within 90 days, but do not wait — every hour an unpatched internet-facing Artifactory instance stays up is an hour an attacker can poison your entire software supply chain.

Sources

  1. BleepingComputer — Hackers exploit critical JFrog Artifactory flaw
  2. The Hacker News — Attackers exploit critical JFrog Artifactory flaw
  3. Dark Reading — Attackers jump on critical Artifactory flaw
  4. SecurityWeek — Critical JFrog Artifactory vulnerability exploited in the wild
  5. SOC Prime — CVE-2026-82329 analysis
  6. dev.to — Exploitation of JFrog Artifactory CVE-2026-82329
  7. JFrog Security Advisories
  8. CISA KEV Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.