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 this is

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.

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

Why it matters

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.

How it works

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.

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.

Detection and response

The hypothesis to test is whether an unauthenticated network client can reach Artifactory's administrative control plane and obtain admin privileges on a default-configured instance. Confirm or reject it with the evidence below.

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.

What to do

1. Map your deployed Artifactory version against the affected list: 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. If you are on a vulnerable version, assume compromise and hunt for indicators of compromise.
2. Apply the vendor-provided fix as soon as possible. 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. JFrog's security advisories and self-managed release notes define the fixed versions and upgrade path.
3. If immediate upgrade is not possible, 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.
4. Restrict network access to Artifactory administrative interfaces, place the service behind authenticated reverse proxies, and enforce strict firewall rules so that only known CI/CD runners and admin hosts can reach it.
5. Review and harden authentication configuration away from defaults, rotate administrative credentials and API tokens, and audit existing admin accounts for anything unexpected.
6. 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.
7. After patching, re-verify that no unauthorized admin accounts or artifacts remain.

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.

Sources

• JFrog Security Advisories
• JFrog Artifactory Self-Managed Releases
• CISA BOD 26-04 Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance / Forensics Triage Requirements
• NVD entry for CVE-2026-82329
• CISA KEV Catalog