Artifactory Flaws Chained Into Admin Backdoors

A software repository that build pipelines trust by default became a foothold for attackers who wanted administrator control of it. Cloud security company Wiz says it observed attacks that chained two flaws in self-hosted JFrog Artifactory to mint admin-scope tokens and install backdoors, and that a third, separate flaw in the same product was exploited on its own during a different window.

The distinction matters: Wiz's account covers an attack chain that requires two specific coding mistakes to line up, plus a standalone authentication bypass that needs only one. Both paths end in the same place — an attacker holding credentials the software is supposed to reserve for administrators.

Two flaws, one admin token

Neither of the two chained flaws grants administrator control by itself. CVE-2026-42018 causes Artifactory to hand an internal anonymous-user token to a caller who has not logged in, even when anonymous access is disabled on the server. CVE-2026-42016 then lets that low-privilege token be exchanged for one carrying administrator scope. The second flaw works because Artifactory validates a token's signature and its issuer but does not check what the token is permitted to do.

Wiz described a consistent pattern across the cases it reviewed. The attacker sends an unauthenticated request to a token endpoint and receives a token for the internal anonymous user, then submits that token to Artifactory's token-creation endpoint and receives one with administrator scope in return. The resulting admin token retains the anonymous username, so actions taken with it appear in logs under token:anonymous rather than a named account. In some of the cases Wiz observed, the attacker moved from the initial request to a new administrator account in under five minutes.

The chain only works on servers affected by both flaws, which means closing either one breaks it. JFrog's published ranges put the fix for CVE-2026-42016 at 7.133.11, leaving the 7.146 and 7.161 branches outside that range. JFrog shipped the CVE-2026-42018 fix on the 7.146 branch on April 28 and on the 7.133 branch on August 12 — three days before the attacks Wiz said it saw began.

What attackers did once inside

Wiz said no single actor carried out every step it observed, and that what attackers did with administrator authority varied. Across the compromised servers, they created administrator accounts and left them in place. They also installed malicious Groovy plugins through Artifactory's plugin framework, which gave them code execution on the host. Some ran shell commands through the plugin execution endpoint to explore and list files.

A dropper pulled a binary over HTTP, wrote it to a world-writable directory such as /tmp, and opened a command-and-control channel. Wiz said it also saw a custom Rust backdoor with command-and-control features dropped in multiple cases.

The chain's reach is narrower than either flaw alone, because a server must be vulnerable to both. But the third flaw in the same report widens the picture considerably, and it is why a server running a newer branch may still be exposed.

The standalone bypass and its scale

CVE-2026-82329 is a critical authentication bypass rated 9.8 on the CVSS scale. It targets Artifactory's default configuration and requires no additional flaw: an unauthenticated attacker with network access can obtain administrator privileges through it alone, across six release branches up to 7.161. Wiz said it saw this flaw exploited separately, between September 1 and September 8.

The Hacker News reported on September 1 that attackers had begun creating administrator tokens for themselves through that flaw days after JFrog disclosed it. CISA added it to its catalog of known exploited vulnerabilities on September 2 and set a September 5 deadline for federal agencies. Fastly, a content delivery network, said in an analysis that a public exploit appeared on September 1 and that scanning followed. Fastly counted about 406,000 exploitation attempts across its platform on September 2, its busiest day — attempts seen in traffic, not confirmed compromises.

On servers taken through that flaw, Wiz said attackers read the system configuration and, in several cases, took the cluster join key — the shared secret Artifactory nodes use to register with one another. That key is a distinct problem from a stolen token, because changing software does not change a secret an attacker already holds.

Which builds carry the fixes

JFrog's security advisories list fixed builds per release branch. For CVE-2026-42018, affected versions are below 7.111.20, and below 7.117.27, 7.125.19, 7.133.28, and 7.146.8 on those branches; the fixes are 7.111.20, 7.117.27, 7.125.19, 7.133.28, and 7.146.8. For CVE-2026-42016, affected versions are those before 7.133.11, fixed in 7.133.11. For CVE-2026-82329, affected versions are below 7.111.21, and below 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20 on those branches; the fixes are 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20.

JFrog lists a single fixed version for CVE-2026-42016 — 7.133.11 — with no separate fix for each branch, and its advisory does not state whether a later build on an older branch, such as 7.117.28, also closes it. The Hacker News said it has asked JFrog that question and has asked Wiz which versions the compromised servers were running.

For CVE-2026-82329, JFrog publishes a workaround for teams that cannot upgrade quickly: generate a random value and add it as an extra join key in system.yaml, so that only your own keys are accepted when a service registers. The advisories and reports consulted offer no interim option for the two chained flaws.

Why an upgrade is not enough

Administrator accounts created by attackers do not disappear when the software is updated. Wiz saw such accounts created through both the two-flaw chain and CVE-2026-82329.

A patch does not revoke tokens already minted.

— Fastly, in its analysis of the exploitation activity.

For CVE-2026-82329, Fastly advises treating any exposed server as compromised. It recommends rotating the platform join key, revoking access tokens issued since August 28, and reviewing administrator accounts, repositories, and configuration changes. An upgrade likewise does not change a join key an attacker has already taken.

Wiz's report lists attacker addresses and a payload hash for defenders building detections.

Signals worth checking for

The clearest indicator is an account doing something its privileges should not allow — the internal anonymous user, or any low-privilege account, creating tokens, listing users, or reading and writing plugins. From there, the next step is hunting for administrator accounts nobody created on purpose.

Most of the accounts Wiz saw carry proof-of-concept names such as 0xTerror, or svc_ and labadmin_ followed by random characters. Some were made to blend in, with names like jfrog-distribution, jfrog-insight, and repo-service. Those names look plausible enough that an inventory review based on naming conventions alone could miss them.

JFrog says cloud instances need no action; the fixes and workarounds apply to self-hosted deployments.

Where the flaw chain came from

CVE-2026-42016 was published on July 27 as part of a batch of Artifactory advisories, several of which credit OpenAI researchers, including this one. The Hacker News reported in July that JFrog had confirmed OpenAI models exploited an Artifactory zero-day during an internal evaluation, and that neither company had said which CVE records match the flaws used in that incident.

That leaves an open thread between the two episodes. A vendor confirmation that an exploitation event occurred, without a matching CVE record attached to it, gives defenders no reliable way to trace which of their own systems were involved in the earlier incident versus the later campaign.

What this means for teams running Artifactory

Artifactory sits at a point in the build pipeline where trust is concentrated, and administrator access to it is a position from which the artifacts other systems consume can be shaped. The compromise path Wiz describes does not stop at reading source code — it ends with malicious plugins executed on the host and a backdoor channel opened. For organizations that treat their artifact repository as internal infrastructure rather than a security boundary, the practical consequence is that an unpatched instance is not just a vulnerable server; it is a potential distribution point into everything downstream.

The timelines in the source material suggest two different response problems. For the standalone bypass, there is a workaround available immediately and a large volume of exploitation attempts observed on a single day, which points to broad automated scanning rather than targeted work. For the two-flaw chain, there is no interim mitigation in the advisories, and the chain requires an internally inconsistent token check that a defender cannot patch around from the outside. Teams that prioritize by available stopgap rather than by severity score will find the standalone flaw easier to act on than the chain, even though both end in administrator access.

The remediation detail that outlasts any upgrade is the one about credentials. Tokens and join keys that existed during the exposure window remain valid after the vulnerable build is gone, so an upgrade closes the entry path without undoing what was taken through it. Any response plan that stops at the version number leaves the accounts, the rotated secrets, and the configuration changes unattended.