The JFrog Artifactory vulnerability requires more than a software update. Upgrade every self-hosted instance to a fixed release, then assume attackers may already have minted administrator tokens. Revoke suspicious credentials, inspect administrators, SSH keys and Groovy plugins, rotate exposed cluster keys, and verify stored artifacts against trusted records. Active exploitation was documented in August and September 2026, with some reported compromises establishing persistence in under five minutes.
Which JFrog Artifactory vulnerability is being exploited?
Three flaws are involved. JFrog disclosed CVE-2026-42016 on July 27, CVE-2026-42018 on August 12 and critical CVE-2026-82329 on August 28. All affect self-hosted Artifactory 7.x installations within specified version ranges, but they don’t provide attackers with identical routes to administrator access.
JFrog’s security advisories describe CVE-2026-42016 as a scope-validation flaw: a low-privilege token can be exchanged for one carrying administrator scope. Versions before 7.133.11 are affected. CVE-2026-42018 can disclose an internal anonymous-user token to an unauthenticated caller, including when anonymous access has been disabled.
Chaining those two bugs removes the apparent low-privilege prerequisite. An attacker first retrieves the anonymous JWT through CVE-2026-42018, then uses CVE-2026-42016 to mint an administrator-scoped token. Wiz reported observing multiple actors use this chain against self-hosted installations from August 15 through September 8, 2026.
CVE-2026-82329 offers a more direct path. Under the default configuration, an unauthenticated request to /access/api/v1/registry/join can produce an administrative token. If your server was internet-accessible while vulnerable, honestly, treating the upgrade as the whole response is an unsafe bet.
Exposure, fixes and observed attack activity
| Issue or event | 2026 date | Affected or observed data | Required fix |
|---|---|---|---|
| CVE-2026-42016 | July 27 | Versions before 7.133.11; 67% prevalence at disclosure in Wiz’s dataset | Upgrade to 7.133.11 or a later applicable release |
| CVE-2026-42018 | August 12 | 69% prevalence at disclosure in Wiz’s dataset | Use a fixed release listed by JFrog for your branch |
| CVE-2026-82329 | August 28 | 67% prevalence at disclosure in Wiz’s dataset | 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 or later |
| CVE-2026-82329 traffic | September 1–2 | About 171,000 attempts, rising to about 406,000 | Patch, restrict exposure and investigate compromise |
The fixed version for CVE-2026-82329 depends on the maintained branch you’re running. Moving to 7.133.11 fixes CVE-2026-42016, for example, but it isn’t the listed CVE-2026-82329 fix for that branch; 7.133.29 is. Check all three advisories rather than assuming one earlier security release closes every route.
Attack volume rose sharply after public exploit availability. Fastly recorded approximately 75,000 attempts on August 31, around 171,000 on September 1 and about 406,000 on September 2, when traffic came from nearly 1,400 source IP addresses and targeted thousands of systems.
Here is the useful calculation: 406,000 is roughly 2.37 times 171,000, a one-day increase of about 137%. Some early traffic was attributed to security-testing services, so request volume isn’t the same as successful intrusion count. Still, Wiz reported confirmed exploitation beginning around September 1 and documented the campaign publicly on September 10.
The speed resembles other cases where an authentication flaw hands over privileged control, such as the SAP OVERPASS administrator-access issue. Patch prioritization guidance from September 2026’s record Patch Tuesday also applies here: external exposure and active exploitation should move a system ahead of ordinary severity-based queues.
Why an artifact repository compromise spreads further
An ordinary server compromise may expose one application and its data. An Artifactory administrator can control repositories, users, tokens, plugins, configuration and artifacts consumed by downstream build or deployment systems. The server occupies a trust position between developers, CI/CD jobs, container workflows, AI models and production environments.
A persistent administrator could replace a package, container image or other build input today and wait for a trusted pipeline to distribute it later. One poisoned component may reach many developers and deployments without requiring the attacker to breach each target separately. That supply-chain path is why the JFrog Artifactory vulnerability can have a wider blast radius than control of a conventional web host.
Repository trust deserves the same scrutiny as the transport used to fetch software. A BGP hijack can redirect software updates, while this attack changes or controls material at the trusted repository itself. The latter may be harder to notice because build systems receive content from the location they were configured to trust.
Artifactory may also contain credentials or connections to other services. Wiz reported persistent administrator accounts, malicious Groovy plugins, webshells, second-stage payloads and a custom Rust backdoor with command-and-control capability during the August 15 to September 8 campaign. In some cases it observed account creation less than five minutes after exploitation.
Patch first, then perform this compromise check
Start by removing unnecessary public access and upgrading every node to a release fixed for all applicable flaws. Don’t stop there. Patching blocks the vulnerable request path, but it doesn’t invalidate tokens that an attacker already created through the JFrog Artifactory vulnerability.
- Unknown administrators: Enumerate every account with administrative status. Confirm its owner and creation time, and investigate names resembling
jfrog-distribution,jfrog-insight,repo-service,labadmin_*,svc_*orNxploited_*. A plausible service name isn’t proof of legitimacy. - SSH keys: Inspect every user’s attached public keys for recent or unapproved additions. Check established accounts as carefully as newly created ones because an attacker can add persistence to a legitimate-looking identity.
- Plugins: Review installed and recently changed Groovy plugins, then investigate requests to
/api/plugins/execute/*. A malicious plugin can provide server-side command execution that survives the initial access route. - Tokens: Enumerate and revoke unexpected, administrator-scoped, long-lived or non-expiring tokens. Investigate tokens created by
anonymousand other low-privilege identities, then rotate credentials exposed to the repository. - Cluster keys: Rotate the Artifactory join key after suspected exposure because it establishes trust among JFrog services and signs inter-service tokens. Protect and assess the master key, which encrypts shared database data.
- Artifact integrity: Compare package, image and model hashes or signatures with trusted pre-compromise records. Review recently uploaded, replaced and cached content, then rebuild critical releases from reviewed source in a clean environment before redeployment.
Wiz observed successful CVE-2026-82329 exploitation between September 1 and September 8 followed by configuration theft, token minting, join-key theft, account creation and attacker-controlled SSH keys. Those actions explain why each checklist item covers a distinct persistence or downstream-abuse path.
Don’t overlook developer workstations and automated tools that consumed repository content during the exposure window. The risk is conceptually related to malicious repositories influencing AI coding agents: trusted automation can carry hostile content beyond the initially compromised service.
How to decide whether artifacts can still be trusted
Clean audit logs aren’t sufficient on their own. Attackers with administrator access may alter configuration, create legitimate-looking identities or use plugins to execute commands on the server. Your stronger evidence comes from records stored outside the compromised environment: signed release manifests, transparency records, CI attestations, source-control commits and immutable hash inventories.
Define the suspect period from the earliest possible exposure, not merely from the first alert. If you can’t establish when the vulnerable instance became reachable or whether logs are complete, widen the period. More rebuilding work is inconvenient; silently promoting a poisoned package into production is worse.
For high-impact releases, compare every dependency and output with a trusted pre-compromise baseline. Then rebuild from reviewed source using clean runners, fresh credentials and verified dependencies. At this risk level, a clean rebuild is usually cheaper than trying to prove that every cached layer remained untouched.
An edge case deserves attention: a repository can be patched and show no unfamiliar administrator while still carrying a malicious artifact uploaded earlier with a stolen token. Identity cleanup doesn’t establish package integrity. Conversely, an altered artifact doesn’t prove the host still has active persistence, so you need both repository forensics and host-level investigation.
JFrog Artifactory vulnerability FAQ
Does patching Artifactory remove an attacker?
No. A patch closes the vulnerable code path but doesn’t revoke previously minted tokens, remove accounts, delete SSH keys or restore modified artifacts. Treat patching and compromise eradication as separate tasks.
Which versions fix CVE-2026-82329?
JFrog’s August 28, 2026 fixes include 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20 or later. Select the fixed release matching your maintained branch and verify coverage for the other two CVEs.
Can CVE-2026-42016 be exploited without credentials?
On its own, CVE-2026-42016 requires a low-privilege token. Chained with CVE-2026-42018, an unauthenticated attacker can obtain an anonymous JWT and exchange it for administrator scope.
Should you rotate the Artifactory join key?
Yes, after suspected exposure. Also assess the master key, revoke suspect tokens and rotate credentials available through Artifactory or its connected integrations.
EN 
FR 
ES