Attackers Chain Two JFrog Artifactory Flaws to Mint Admin Tokens and Plant Rust Backdoors

Attackers took administrator control of self-hosted JFrog Artifactory servers by chaining two already-patched flaws, and in some cases went from an unauthenticated request to a brand new administrator account in under five minutes. Wiz observed the activity between August 15 and September 8, 2026. Artifactory is the repository that build pipelines pull from, so whoever holds administrator on that server decides what every downstream build consumes.

Two flaws, neither enough alone

CVE-2026-42018 makes Artifactory hand an internal anonymous-user token to a caller who has never logged in, and it does this even when anonymous access is switched off. On its own that token is low value. CVE-2026-42016 supplies the second half: Artifactory validates a token's signature and its issuer, but not what the token is actually permitted to do, so a low-privilege token can be exchanged for one carrying administrator scope.

Every case Wiz examined followed the same shape. An unauthenticated request goes to a token endpoint and comes back with a token for the internal anonymous user. That token is then presented to Artifactory's token-creation endpoint and exchanged for an administrator-scope token. From there the attacker owns the platform.

What followed administrator access

Wiz noted that no single actor performed every step it saw, which suggests more than one crew working the same exposure. Across the compromised servers the post-exploitation pattern was consistent:

• Administrator accounts created and left in place for persistence
• Malicious Groovy plugins installed through Artifactory's plugin framework, giving code execution on the host
• Shell commands run through the plugin execution endpoint to explore the filesystem and list files
• A dropper pulling a binary over plain HTTP, writing it to a world-writable directory such as /tmp, and opening a command-and-control channel
• A custom Rust backdoor with command-and-control features, dropped in multiple cases

The narrow chain and the wide one

The two-flaw chain reaches a smaller population than either flaw alone, because a server has to be vulnerable to both. Closing either one breaks it. In JFrog's published ranges, CVE-2026-42016 ends at 7.133.11, which leaves the 7.146 and 7.161 branches outside that range entirely. 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 Wiz saw the attacks start.

The wider problem is a third flaw in the same report. CVE-2026-82329 is a critical authentication bypass rated 9.8, it targets Artifactory's default configuration, and it needs no partner flaw: an unauthenticated attacker with network access gets administrator privileges on its own, across six release branches up to 7.161. A public exploit appeared on September 1 and scanning followed immediately. Fastly counted roughly 406,000 exploitation attempts across its platform on September 2, its busiest day. Those are attempts observed in traffic, not confirmed compromises. CISA added the CVE to its known exploited vulnerabilities catalog on September 2 with a September 5 deadline for federal agencies. On servers taken this way, Wiz saw attackers read the system configuration and, in several cases, lift the cluster join key, the shared secret Artifactory nodes use to register with one another.

Fixed builds

Upgrade self-hosted Artifactory to the fixed build for your release branch. JFrog lists a single fixed version for CVE-2026-42016, 7.133.11, with no per-branch build, and its advisory does not state whether a later build on an older branch such as 7.117.28 also closes it. If you are on an older branch, treat that as unresolved and go to the newest build available for your branch. For CVE-2026-82329 there is a documented workaround if you cannot upgrade today: generate a random value and add it as an extra join key in system.yaml, so only your own keys are accepted at service registration. No interim option exists for the two chained flaws.

grep -F 'token:anonymous' /opt/jfrog/artifactory/var/log/artifactory-request.log
grep -E 'anonymous.*(POST|PUT).*/access/api/v1/tokens' /opt/jfrog/artifactory/var/log/artifactory-request.log
grep -E '(POST|PUT) /artifactory/api/plugins/(execute|reload)' /opt/jfrog/artifactory/var/log/artifactory-request.log
ls -lt /opt/jfrog/artifactory/var/etc/artifactory/plugins/

Patching does not undo what already happened

An upgrade removes the entry path and nothing else. Administrator accounts the attackers created survive the update. Tokens already minted stay valid. A join key already copied is still a working key on your cluster. As Fastly put it, "A patch does not revoke tokens already minted." Its guidance for CVE-2026-82329 is to treat any exposed server as compromised, rotate the platform join key, revoke access tokens issued since August 28, and review administrator accounts, repositories, and configuration changes.

Hunting for it

The clearest signal 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. After that, look for administrator accounts nobody created on purpose. Most of the ones Wiz documented carried proof-of-concept names such as 0xTerror, or svc_ and labadmin_ followed by random characters, though some were built to blend in with existing naming conventions.

If your Artifactory instance is reachable from the internet and was running an unpatched build during August 15 to September 8, work the assumption that it was reached. The cost of a token rotation and an account audit is a morning. The cost of an attacker holding admin on the repository your builds pull from is every artifact you shipped after that.

curl -s -H "Authorization: Bearer $JFROG_TOKEN" "$ART_URL/artifactory/api/system/version"

grep -aE 'anonymous' /opt/jfrog/artifactory/var/log/artifactory-request.log | grep -aE 'POST|PUT|DELETE' | head -50

curl -s -H "Authorization: Bearer $JFROG_TOKEN" "$ART_URL/access/api/v2/users" | jq -r '.users[].username' | sort

docker pull releases-docker.jfrog.io/jfrog/artifactory-pro:7.133.29

openssl rand -hex 32

curl -s -X DELETE -H "Authorization: Bearer $JFROG_TOKEN" "$ART_URL/access/api/v1/tokens/$TOKEN_ID"