← Back to blog
Blog Detail

CVE-2026-82329: JFrog Artifactory Improper Authentication Grants Admin Access (CISA KEV)

CVE-2026-82329 is a critical improper authentication flaw in JFrog Artifactory that, under default configuration, lets an unauthenticated network attacker obtain administrative privileges. It is in CISA KEV with a 2026-09-05 remediation deadline.

Trusteed Team
Trusteed Editorial
Written On
Sep 18, 2026
Category
CTEM
Read Time
9 min read
  • CVE-2026-82329
  • KEV
  • CISA
  • JFrog
  • Artifactory
  • CTEM

CVE-2026-82329: JFrog Artifactory Improper Authentication Grants Admin Access (CISA KEV)

TL;DR

CVE-2026-82329 is a critical improper authentication vulnerability in JFrog Artifactory that, under default configuration, allows an unauthenticated attacker with network access to obtain administrative privileges. It affects multiple self-hosted Artifactory release branches, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 2026-09-02 with a remediation due date of 2026-09-05. If you run Artifactory self-managed, treat this as an emergency patch: upgrade to a fixed version or apply the vendor workaround immediately, and hunt for signs of unauthorized admin access.

What is this vulnerability?

Field Value
CVE CVE-2026-82329
Vendor / Product JFrog / Artifactory (Self-Hosted)
Vulnerability name JFrog Artifactory Improper Authentication Vulnerability
Weakness CWE-287 (Improper Authentication)
CVSS v3.1 9.8 (Critical) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CISA KEV added 2026-09-02
CISA KEV due date 2026-09-05
Known ransomware use Unknown
Affected versions 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 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20

Overview

CVE-2026-82329 is an improper authentication vulnerability in JFrog Artifactory, tracked under CWE-287. The vendor-assigned CVSS v3.1 base score is 9.8 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which describes a remotely reachable, low-complexity attack that requires no credentials and no user interaction. The core issue is that, under default configuration, an unauthenticated attacker with network access to the affected service can obtain administrative privileges. CISA added the CVE to the Known Exploited Vulnerabilities catalog on 2026-09-02 with a remediation due date of 2026-09-05, which is an unusually short window and signals that exploitation is expected or already observed. JFrog published vendor guidance through its security advisories and self-managed release documentation. EPSS currently sits around 0.07666 (roughly the 94th percentile), so while mass scanning may not yet be universal, the KEV listing and public proof-of-concept repositories make this a high-priority item for any team running Artifactory. Defenders who operate Artifactory self-managed instances, especially those reachable from the internet or from broad internal networks, should treat this as an emergency patch item rather than a routine maintenance task.

Technical details

At a technical level, CVE-2026-82329 is classified as CWE-287, Improper Authentication. That category covers cases where a product does not correctly verify, or fails to verify at all, the identity of a user or service before granting access to protected functionality. In this case, the vendor and CISA both describe the outcome as an unauthenticated attacker obtaining administrative privileges when the product is left in its default configuration. The CVSS vector confirms the attack is network-based (AV:N), requires low complexity (AC:L), needs no privileges (PR:N) and no user interaction (UI:N), and has high impact across confidentiality, integrity, and availability. The trust boundary that is crossed is the authentication layer that is supposed to separate anonymous network clients from Artifactory's administrative control plane. Because the issue is tied to default configuration, environments that have been hardened with custom authentication, network segmentation, or additional access controls may have a reduced exposure surface, but the safe assumption is that any unpatched instance is vulnerable until the vendor fix is applied. The exact vulnerable version range is defined in JFrog's advisory and release notes; defenders should map their deployed Artifactory version against the vendor's fixed release before assuming they are safe. No public weaponized payload details are reproduced here, but multiple public proof-of-concept repositories exist, which lowers the barrier for less sophisticated actors.

Impact

Successful exploitation gives an attacker administrative control over the Artifactory instance. In practical terms that means the attacker can read, modify, or delete repositories and artifacts, which directly threatens the integrity of the software supply chain that Artifactory is meant to protect. Because Artifactory commonly stores build artifacts, container images, and dependency packages, an attacker with admin rights could poison artifacts that downstream build and deployment pipelines trust, leading to broader compromise of production systems. Confidentiality is also at risk: private packages, internal source artifacts, credentials embedded in build metadata, and repository configurations may be exposed. On the availability side, an attacker could delete repositories or disrupt service, and could also alter authentication and permission settings to maintain persistence. For defenders, the business exposure extends beyond the Artifactory host itself: any CI/CD pipeline, artifact consumer, or deployment process that pulls from the compromised instance should be considered potentially tainted. The KEV listing and the short remediation deadline reinforce that this is not a theoretical risk.

Exploitability

CVE-2026-82329 is listed in CISA KEV, confirming that exploitation has been observed or is expected. The EPSS score is approximately 0.07666 (94th percentile), indicating a moderate probability of exploitation activity in the next 30 days relative to other vulnerabilities. Multiple public proof-of-concept repositories exist on GitHub, which lowers the barrier for attackers. The vulnerability is remotely exploitable without authentication and requires no user interaction, making it attractive for automated scanning and exploitation. While no ransomware usage has been reported, the potential for supply chain disruption and data exfiltration makes it a high-priority threat.

KEV vs CVSS vs EPSS

Signal What it measures Action for this CVE
CISA KEV Confirmed in-the-wild exploitation Mandatory remediation by 2026-09-05 for U.S. federal agencies; all organizations should prioritize patching immediately.
CVSS v3.1 Technical severity (9.8 Critical) Indicates maximum severity; patch without delay.
EPSS Probability of exploitation (0.07666, 94th percentile) Elevated likelihood; reinforces need for urgent action.

Exploitation steps (defensive triage)

From a defensive triage perspective, the exploitation chain generally looks like this:

  1. The attacker identifies an exposed Artifactory instance, often through internet-wide scanning or by locating it on an internal network segment.
  2. The attacker confirms the service is reachable and running an affected version, typically by inspecting version banners, API responses, or product-specific endpoints.
  3. The attacker sends crafted requests that abuse the improper authentication logic, without supplying valid credentials.
  4. Because the flaw is tied to default configuration, the attacker does not need to guess passwords or steal tokens; the authentication check itself is bypassed.
  5. The attacker obtains administrative privileges and gains access to the administrative API and UI.
  6. With admin access, the attacker enumerates repositories, users, permissions, and stored artifacts to understand what is valuable.
  7. The attacker may create or modify artifacts, add persistence such as new admin accounts or tokens, or exfiltrate sensitive packages and configuration data.
  8. The attacker may pivot into CI/CD systems that consume artifacts from the compromised instance.

Defenders should focus on detecting steps 1 through 5, since those are the earliest and most detectable stages.

Indicators of compromise

Hunt for the following in Artifactory logs, reverse proxy logs, EDR telemetry, and network flow data:

  • Authentication or authorization events that succeed without a corresponding valid login, especially admin-level actions from unexpected source IPs.
  • New or modified administrative accounts, API keys, access tokens, or permission targets that were not created through a known change process.
  • Unusual repository operations: bulk downloads, unexpected uploads, artifact overwrites, or deletions outside normal deployment windows.
  • Requests to administrative API endpoints from IP addresses that do not belong to known CI/CD runners or admin workstations.
  • Spikes in 200 responses to requests that lack session cookies or bearer tokens, visible in reverse proxy or web server logs.
  • Changes to authentication configuration, such as modified SAML, LDAP, or token settings, that could be used for persistence.
  • Outbound connections from the Artifactory host to unfamiliar destinations, which may indicate exfiltration.
  • Correlated alerts from downstream build systems that report unexpected artifact hashes or failed signature verification.

Mitigation and workarounds

Apply the vendor-provided fix as soon as possible; JFrog's security advisories and self-managed release notes define the fixed versions and upgrade path. Given the CISA KEV due date of 2026-09-05, teams should prioritize this over routine patching. Where immediate upgrade is not possible, compensating controls include restricting network access to Artifactory administrative interfaces, placing the service behind authenticated reverse proxies, and enforcing strict firewall rules so that only known CI/CD runners and admin hosts can reach it. Review and harden authentication configuration away from defaults, rotate administrative credentials and API tokens, and audit existing admin accounts for anything unexpected. For cloud or hosted deployments, follow the applicable BOD 26-04 guidance, and if mitigations are unavailable, consider discontinuing use of the affected service until a fix can be applied. After patching, re-verify that no unauthorized admin accounts or artifacts remain.

Community reactions

CISA's addition of CVE-2026-82329 to the KEV catalog on 2026-09-02, with a due date only three days later, drew immediate attention from defenders who manage Artifactory instances. The combination of a Critical CVSS score, a default-configuration trigger, and multiple public proof-of-concept repositories on GitHub made the issue a frequent topic in vulnerability management and DevSecOps discussions. Security media and community analysts emphasized the supply-chain implications, since Artifactory sits at a trust-critical point in many build pipelines. The vendor, JFrog, published advisories and release guidance, and the general community tone has been that this should be treated as an emergency patch rather than a scheduled one.

FAQ

Q: Is CVE-2026-82329 in CISA KEV?
A: Yes, it was added on 2026-09-02.

Q: What is the CISA KEV due date?
A: The remediation due date is 2026-09-05.

Q: Is this vulnerability exploitable over the internet?
A: Yes, an unauthenticated attacker with network access can exploit it. Internet-facing instances are at highest risk.

Q: Which Artifactory versions are affected?
A: Self-hosted versions 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, and 7.161.0–7.161.19. JFrog Cloud instances were automatically patched.

Q: How can I verify if my instance is vulnerable?
A: Check your Artifactory version against the affected list. If you are on a vulnerable version, assume compromise and hunt for indicators of compromise.

Q: What is the fixed version?
A: Upgrade to 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20, depending on your release branch.

Q: Is there a workaround if I cannot patch immediately?
A: Yes, configure additionalJoinKeys in system.yaml under shared.security with a random hex key, and restart the Access service. For containerized deployments, set the JF_SHARED_SECURITY_ADDITIONALJOINKEYS environment variable.

Related resources

Join Our Newsletter

Trusteed keeps you informed: emerging risks, platform updates, and practical guides for faster defense.