JFrog Artifactory CVE-2026-82329 Exploited Days After Disclosure to Mint Admin Tokens

Attackers began exploiting a critical authentication bypass in JFrog Artifactory, CVE-2026-82329, within days of its August 28, 2026 disclosure, and the exposure-management firm watchTowr says they are minting themselves administrator tokens. The flaw carries a CVSS score of 9.8, needs no authentication and no user interaction, and on a default configuration of a self-hosted Artifactory server it hands an unauthenticated attacker administrative control of the system many engineering teams use to store and ship their software.

That is close to a worst case for a software supply chain. Artifactory is where builds, binaries, container images, and packages sit before they reach production and customers. JFrog says roughly 6,600 organizations use its platform, including 83% of the Fortune 100, figures it cited to Dark Reading. An attacker who holds admin on that system does not merely read secrets. They can change what an organization ships.

Updated September 14, 2026: Two things have changed since this was published. CISA added CVE-2026-82329 to its Known Exploited Vulnerabilities catalog on September 2, the day after this article went up, and the sentence further down that said otherwise now carries a dated correction. More seriously, this is no longer a one-CVE story. Wiz Research reported on September 10 that attackers are chaining two further Artifactory flaws, CVE-2026-42018 and CVE-2026-42016, to reach the same administrative access, and says it is aware of no prior public reporting of in-the-wild exploitation of either. What follows this update is the original September 1 reporting, unchanged.

Updated October 1, 2026: The first named victim of CVE-2026-82329 has surfaced. OpenInfra Europe posted a security notice saying its self-hosted Artifactory instance at artifactory.nordix.org was compromised through the flaw, and that anyone who “downloaded or installed artifacts” from it “from August 28 and September 15, 2026 should immediately stop using them, remove them from their pipelines, and treat these packages as potentially compromised,” per Help Net Security (September 30). Help Net's timeline puts the compromise on August 31, the same day watchTowr first saw exploitation, and says it was discovered on September 15 after a legitimate user was denied access. That is roughly 15 days of undetected administrator-level exposure on a package host. OpenInfra says the full scope is still undetermined, and it has not said which packages were altered or how, so treat any claim about payloads as unconfirmed. The dates above come from a single outlet; we have not independently confirmed the August 31 compromise date. My assessment: if you run self-hosted Artifactory and patched after August 31, patching did not close the question. Review admin and token creation logs back to August 28, check repository contents against known-good checksums, and rebuild anything that pulled from an instance you cannot vouch for. If your CI pulled from artifactory.nordix.org in that window, search the logs and quarantine those builds.

What CVE-2026-82329 Actually Is

CVE-2026-82329 is an improper-authentication bug, not remote code execution. JFrog disclosed it on August 28, 2026 and released fixes the same day. The company's advisory states the problem in a single sentence: “JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.” That is the whole risk model in one line: default config, no credentials, network reach, admin.

The weakness lives in JFrog Access, the component that issues and validates credentials. watchTowr traced it to how default-configured servers handle an internal join key, which is enough for an unauthenticated request to be treated as trusted and to forge administrator-level credentials. Two qualifiers matter for scoping. First, it affects self-hosted Artifactory only. Second, JFrog says its cloud (SaaS) platform is not affected, because those instances were patched centrally before the details were public.

JFrog chief technology officer and co-founder Yoav Landman was careful to separate this bug from the earlier episode in which OpenAI's models exploited an Artifactory zero-day on their way to breaching Hugging Face. “It is improper authentication rather than RCE, and it does not affect the JFrog SaaS platform, only self-hosted deployments,” Landman told Dark Reading, comparing it to a similar authentication-bypass flaw that hit self-hosted Next.js but not its hosted equivalent. In other words: same vendor, same product name in the headlines, but a different vulnerability and a different population of exposed servers.

Why a Repository Manager Is Such a High-Value Target

Artifactory is not a website or a mail server. It is the shelf every build pulls from and pushes to, the place where an organization's binaries, container images, libraries, and packages are stored, versioned, and distributed. Compromise a web app and you own that app. Compromise the artifact repository and you sit upstream of everything the app depends on.

That is what makes admin on Artifactory qualitatively worse than admin on most single systems. Ganchev's summary of the downside, given to both The Hacker News and Dark Reading, is worth reading as a threat model rather than a soundbite: “When attackers gain admin level access to a central software supply chain system, they can do what every engineering team does best: build, ship and distribute software fast. From there, they could tamper with build pipelines, move laterally into production systems and potentially push malicious changes downstream to customers.” The failure mode is not data theft. It is trusted distribution of untrusted code.

What watchTowr Is Seeing

watchTowr reported the first in-the-wild activity on August 31, three days after disclosure, and by September 1 said attackers were using the flaw to generate admin tokens and to enumerate users, groups, credential sets, and federated access topologies. Yordan Ganchev, the firm's principal threat intelligence specialist, put the speed bluntly: “This moved from disclosure to real-world exploitation with uncomfortable efficiency.”

The scale, for now, is limited. Ganchev told Dark Reading the attacks appear to originate from a small number of IP addresses across varying geographies and involve more than one threat actor. Some activity is opportunistic, probing and then stopping. Other attempts succeeded and then enumerated the instance to judge whether it was worth pursuing further, which is the reconnaissance step that usually precedes a hands-on-keyboard intrusion. “Broad-scale scanning and mass exploitation has not been observed, but that is unlikely to stay the case for long,” Ganchev said. Independent researchers have reported reproducing the bug, and at least one public proof-of-concept exists, which historically widens the pool of attackers within days.

My Read: Admin-Token Minting Is the Line You Do Not Want Crossed

My read: artifact repositories are the crown jewels of a software supply chain, and admin-token minting is the specific capability that turns a bad vulnerability into a downstream one. This is assessment, not reporting. Once an attacker can issue their own administrator token, patching afterward does not evict them, because the token is a valid credential they created. That single fact reorders the response. A 9.8 on an internet-facing box is routine in 2026. A 9.8 that lets an anonymous request forge admin on the system that signs and distributes your builds is the kind that shows up in an incident report six months later, traced back to a window that was open for a weekend. watchTowr's framing, that exploitation arrived with “uncomfortable efficiency,” matters more than the score, because it tells you the patch-versus-exploit race was already lost for anyone who waited.

Response checklist for self-hosted JFrog Artifactory operators exposed to CVE-2026-82329, in priority order: patch, audit admin tokens, review access and audit logs, and restrict management-plane exposure.

It Is Three Flaws, Not One, and the Severity Label Is Why

Added September 14, 2026. Wiz Research published on September 10 that multiple actors have been chaining two Artifactory vulnerabilities that nobody had publicly reported as exploited before. Wiz's write-up describes CVE-2026-42018 as an improper-authentication issue in which Artifactory can return an internal anonymous-user token to an unauthenticated requester even when anonymous access is disabled, and CVE-2026-42016 as a privilege-escalation issue in which Artifactory validates a token's signature and issuer but does not enforce its intended scope, so a low-privileged token can be exchanged for an admin-scoped one.

Neither grants administrative access on its own. Chained, they turn an unauthenticated request into an admin-scoped token in two steps. Wiz observed this against self-hosted instances between August 15 and September 8, 2026, and says that in some cases actors went from first request to a created administrator account in under five minutes.

The part worth sitting with is Wiz's patching data, and it is an argument against the way most organisations triage. Wiz reports that when each flaw was published, roughly two thirds of organisations running Artifactory in its visibility had at least one vulnerable instance: 67 percent for CVE-2026-42016 on July 27, 69 percent for CVE-2026-42018 on August 12, 67 percent for CVE-2026-82329 on August 28. What happened next diverged sharply. Six weeks on, 59 percent were still vulnerable to 42016. In four weeks 42018 moved only from 69 to 62 percent. But 82329 fell from 67 to 49 percent inside two weeks, and Wiz attributes that to its critical rating driving urgency.

Patching velocity across the three exploited Artifactory flaws, as measured by Wiz Research within its own customer visibility. The critical-rated bug was patched roughly twice as fast as the two lower-rated ones that attackers ultimately chained.

My read, stated as assessment: this is about as clean a natural experiment in severity-ranked patching as you will find. Same product, same customer base, same vendor, same release channel. The only variable that differed was the label on the advisory. Organisations patched the one with the frightening score and left the two lower-rated bugs in place, and attackers then chained precisely those two to reach the access the critical one would have given them. The lesson is not that severity scores are useless. It is that a chain does not care what the individual links were rated, and a triage process that only escalates on “critical” is structurally blind to that.

One caveat on the numbers, which Wiz itself is clear about: these percentages describe organisations in Wiz's own customer visibility, not an internet-wide census. Treat them as a direction and a ratio, not a population count.

Post-exploitation is where this gets expensive, and none of it is undone by an upgrade. Across the cases it observed, Wiz reports persistent administrator accounts left in place, malicious Groovy plugins installed through Artifactory's native plugin framework to get code execution on the server, a dropper that fetched a binary over HTTP into a world-writable path and established command and control (a custom Rust backdoor in multiple cases), occasional webshell uploads into repository paths, and attackers attaching their own SSH keys to accounts they had created. No single actor ran every step.

What Artifactory Operators Should Do Now

Patching is the first move, but watchTowr is explicit that it is not the last. Any self-hosted Artifactory that was internet-exposed while vulnerable should be treated as potentially compromised already, because a minted token is a legitimate credential the attacker holds after the fix lands.

The concrete sequence: upgrade to your branch's fixed release and prioritize internet-facing instances; inspect audit logs for unexpected admin-token creation and for user, group, or credential enumeration; revoke and rotate tokens and credentials that were exposed during the window; and restrict management-plane access so the admin surface is not reachable from the open internet. Then investigate connected systems, meaning build pipelines, CI/CD runners, and downstream repositories, for malicious changes or backdoor access. This is standard vulnerability management discipline applied to a system whose blast radius reaches your customers, which is why the assume-breach posture is warranted rather than paranoid.

Three further steps were added on September 14, 2026, after Wiz Research published its findings on the two chained flaws.

• Patching for 82329 alone is not enough. CVE-2026-42016 and CVE-2026-42018 have their own affected ranges. Wiz's fixed-version list is 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 or 7.161.20 and later, which are the same builds already named above. The practical point is that anyone who responded to 82329 by restricting network access rather than upgrading is still exposed to the other two.
• Hunt the three artefacts a patch does not remove. Enumerate every Artifactory administrator account and check creation dates against the August 15 to September 8 window. Audit the plugin directory and the plugin-execution endpoint for any Groovy plugin your own team did not deploy, which is the code-execution foothold. Check for SSH keys attached to accounts you did not create. Wiz also published the account-name patterns it saw, including boilerplate forms such as Nxploited_ and labadmin_ prefixes and plausible-looking service names like jfrog-distribution, repo-service, backup-service and ldap_admin. Those are worth grepping your own user list for.
• Three log-hunting signatures. A low-privilege or internal-anonymous identity minting tokens, enumerating users, or touching the plugins API. Wiz's framing of the anomaly is worth keeping: it is “a mismatch between who the identity is and what it is doing.” Second, requests where the actor field reads token:anonymous while an admin-authority action is performed, because the escalated token keeps the anonymous username. Third, a 401 on a bare endpoint followed immediately by a 200 on a variant of it from the same client, which is an operator confirming a vulnerable variant rather than anything a normal client produces.

The pattern is familiar from recent weeks. GitLab shipped a fix for an unauthenticated flaw that attackers exploited days after disclosure, and Check Point patched a SmartConsole authentication bypass that was already under active exploitation. Short windows between disclosure and exploitation are now the norm for internet-facing developer infrastructure, not the exception, and the defensive answer is the same each time: patch fast, then verify you were not already hit. The sharpest September illustration is the PaperCut campaign, where an AI-orchestrated operator reached hundreds of instances while defenders were still patching, and where the foothold outlived the fix.

Fixed Versions and KEV Status

JFrog patched CVE-2026-82329 in Artifactory 7.161.20, released August 28, 2026, with fixed builds across each supported branch. Self-hosted operators should move to whichever of these matches their line:

• 7.161.x branch: upgrade to 7.161.20
• 7.146.x branch: upgrade to 7.146.38
• 7.133.x branch: upgrade to 7.133.29
• 7.125.x branch: upgrade to 7.125.20
• 7.117.x branch: upgrade to 7.117.28
• 7.111.x branch: upgrade to 7.111.21

Cloud customers do not need to act; JFrog says those instances were patched centrally. When this article was published on September 1, 2026, CISA had not added CVE-2026-82329 to its Known Exploited Vulnerabilities (KEV) catalog, per SecurityWeek, though the agency had previously added the unrelated Artifactory flaw CVE-2026-66384 tied to the OpenAI incident. Correction, September 14, 2026: that statement was accurate for exactly one day. CISA added CVE-2026-82329 to the KEV catalog on September 2, in a batch of seven additions that also included the SonicWall SMA1000 pair, CVE-2026-83548 and CVE-2026-83549. We flag two things as unconfirmed: no named victim organizations have been reported, and no count of compromised or exploited instances has been published. watchTowr has described the activity qualitatively (a small number of source IPs, multiple actors, opportunistic and targeted attempts) rather than by number, and JFrog had not confirmed in-the-wild exploitation on the record at the time of writing. Correction, October 1, 2026: the claim that no victim organizations have been reported is no longer accurate. OpenInfra Europe has disclosed that its own self-hosted Artifactory instance was compromised through this flaw (see the update at the top of this article). No count of compromised instances has been published.

Primary Documents

• CVE-2026-82329 record (CVE.org)
• JFrog security advisories (CVE-2026-82329 entry and patched releases)
• Wiz Research, “Artifactory Under Attack”, September 10, 2026 (CVE-2026-42016, CVE-2026-42018 and CVE-2026-82329)
• watchTowr advisory post confirming in-the-wild exploitation
• The Hacker News reporting, with watchTowr statement
• Dark Reading reporting, with JFrog CTO comment
• SecurityWeek reporting, including KEV status
• Help Net Security reporting on the OpenInfra Europe compromise and its security notice, September 30, 2026