JFrog Artifactory Hacked in 24-Day Campaign; Rust Backdoors Survive Patching

Multiple threat actors compromised self-hosted JFrog Artifactory build servers across a 24-day window by chaining two patched authentication vulnerabilities — then used administrator access to install persistent Rust backdoors with command-and-control capabilities, as Wiz Research disclosed on September 10. The campaign ran from August 15 through September 8 on installations where available fixes had not been applied, and in some cases attackers moved from an unauthenticated network request to a newly created administrator account in under five minutes.

The attack sits at the nerve center of enterprise software delivery. JFrog Artifactory is the artifact repository that build pipelines pull packages and dependencies from, meaning whoever controls the platform controls what every downstream software build consumes. Approximately 6,600 organizations worldwide depend on JFrog products, including 83% of the Fortune 100. A compromised Artifactory instance is not merely a breached server — it is a staging point for poisoning software artifacts before they reach users and enterprise environments.

The campaign exploited fixes that existed before the attacks began. JFrog published the patch for CVE-2026-42018 on the 7.133 branch on August 12 — three days before Wiz observed the first chain exploitation on August 15. Wiz found that at the time CVE-2026-42016 was first published on July 27, 67% of organizations running Artifactory had at least one vulnerable instance, and patching velocity remained slow throughout the campaign period.

How the Chain Works

The attack exploits two flaws that are individually insufficient but devastating together.

The first, CVE-2026-42018 (CVSS 7.5), is an improper-authentication vulnerability that causes Artifactory to return an internal anonymous-user JSON Web Token (JWT) to an unauthenticated caller — even when anonymous access has been explicitly disabled. Attackers triggered it by sending a POST request to the token endpoint with a trailing slash variant that bypasses the access control applied to the standard path. On its own, the token carried minimal privileges.

The second, CVE-2026-42016 (CVSS 8.1), provides the escalation path. Artifactory’s token validation checks the JWT’s cryptographic signature and issuer — but does not verify whether the token’s scope claim matches what the bearer is actually authorized to receive. An attacker presenting the low-privilege anonymous-user token to Artifactory’s token-creation endpoint received in return a token carrying full administrator scope. The root cause, classified as CWE-863: the server correctly signs tokens but fails to enforce that the caller’s existing privileges permit the scope embedded in the newly issued one.

That two-step sequence — leaking an anonymous JWT, then exchanging it for an admin token — is the engineering gap that made the chain possible. Security researchers at BishopFox, who separately analyzed the related vulnerability CVE-2026-82329, identified the same class of flaw in their CVE-2026-82329 root-cause analysis: the system validates whether a secret is well-formed rather than whether it actually exists.

The Audit Trail Problem That Makes Hunting Hard

There is a structural detection problem built into how CVE-2026-42016 works that the raw vulnerability description does not capture: the administrator-scoped token produced by this chain retains the anonymous username. Every administrator action taken with it appears in Artifactory’s logs as token:anonymous rather than under any named account.

A security operations center hunting for a rogue administrator by searching for unexpected named accounts will find nothing — because the attacker never needed to register an identity to acquire administrator authority. The attacker created a named account only after already possessing admin scope, meaning the log signature of actual exploitation is a low-privilege identity doing high-privilege things, not a new admin account appearing from nowhere.

This means standard incident response instincts — "look for accounts nobody created" — are insufficient until a defender specifically searches for privilege anomalies: the internal anonymous identity, or any low-privilege identity, creating tokens, listing users, reloading plugins, or reading repository configuration.

What Attackers Did With Administrator Access

Across compromised servers, Wiz observed a set of post-exploitation steps that varied by actor — no single actor ran every step, suggesting multiple crews working the same exposure independently.

Attackers created persistent administrator accounts designed to blend into legitimate service identities: names such as jfrog-distribution, backup-service, jfrog-insight, and repo-service alongside proof-of-concept handles including 0xTerror and pattern-generated names like labadmin_ followed by random characters.

Once they held native administrator access, several actors installed malicious Groovy plugins through Artifactory’s own legitimate plugin framework — turning a data-plane compromise into full arbitrary code execution on the underlying host without exploiting any additional vulnerability. A dropper then pulled a binary over plain HTTP, wrote it to world-writable directories including /tmp, /dev/shm, and /var/tmp, and established a command-and-control channel.

Across multiple compromised instances, Wiz confirmed a custom Rust backdoor with command-and-control capabilities. Defenders hunting this specific implant should look for a file at /tmp/.z with SHA1 hash 513a907b69edffc3cb77a494da395178d21ef9bd; payload delivery was observed from hxxp://log.gitclone[.]org:45678/smtp and hxxp://3.88.162[.]79:36789/smtp, with C2 communications to 64.207.232[.]6:8443. Additional attacker IPs and account patterns are documented in the Wiz disclosure.

Attackers also stole Artifactory configuration data and cluster join keys — the shared secrets that Artifactory nodes use to register with one another — and in several cases uploaded webshells. Exfiltration of a cluster join key is particularly consequential: the key remains valid until explicitly rotated, meaning an attacker who copied it before a patch was applied retains a valid credential even after the upgrading organization believes the server is clean.

A Third Flaw, Worse on Its Own

Separately from the two-CVE chain, Wiz also documented active exploitation of CVE-2026-82329 (CVSS 9.8), a standalone critical authentication bypass that requires no companion vulnerability. An unauthenticated attacker with network access to a vulnerable instance can obtain administrator privileges on its own, across six Artifactory release branches up to version 7.161.

BishopFox’s root-cause analysis found the underlying engineering gap: Artifactory validated the join key’s encoding — whether it was well-formed — but not its presence. Under a default installation where the join key is unset, the key’s value hashes to a predictable constant (the SHA-1 hash of an empty string), which any attacker can reproduce and present as a valid credential.

JFrog published a patch for CVE-2026-82329 on August 28. A public exploit appeared on September 1, and scanning accelerated immediately. On September 2, content delivery network Fastly counted approximately 406,000 exploitation attempts across its platform — a figure representing attempts in traffic, not confirmed compromises. CISA added CVE-2026-82329 to KEV on September 2 with a September 5 remediation deadline for federal agencies. Offensive security firm watchTowr had already confirmed exploitation before Wiz published its broader disclosure.

Yordan Ganchev, principal threat intelligence specialist at watchTowr, told The Hacker News: "This moved from disclosure to real-world exploitation with uncomfortable efficiency. Anyone following along knows what comes next: things will get worse." He added that attackers with admin access to a central software supply chain system can build, ship, and distribute software using the same trusted infrastructure as any engineering team.

How Many Organizations Are Still Exposed

The patching picture as of Wiz’s September 10 disclosure is bleak. At the time CVE-2026-42016 was first published on July 27, 67% of organizations running JFrog Artifactory had at least one vulnerable instance. For CVE-2026-42018, 69% were vulnerable at publication on August 12. Six weeks after the first disclosure, 59% remained vulnerable to CVE-2026-42016; CVE-2026-42018 had declined only from 69% to 62% over four weeks.

CVE-2026-82329 saw faster remediation — CISA’s critical rating drove more urgency — but still left 49% still vulnerable two weeks later. Wiz estimates that between 49% and 62% of reachable instances remain vulnerable to at least one of the three flaws. The cloud-hosted JFrog platform is unaffected; this campaign is exclusively a self-hosted deployment problem.

Does Patching Fix It? Not If Attackers Were Already Inside

Fastly’s guidance on CVE-2026-82329 applies equally to the chain CVEs, as cited by The Hacker News: a patch does not revoke tokens already minted. An upgrade removes the entry path and nothing else. Administrator accounts the attackers created survive the update. Access tokens already minted remain valid. A cluster join key already copied is still a working credential on the cluster.

For any self-hosted Artifactory instance that was internet-accessible and running an unpatched build between August 15 and September 8, Wiz advises assuming potential compromise regardless of whether evidence of intrusion has yet been found.

JFrog recommends upgrading to one of the following fixed builds (or any later version in each branch): 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. For CVE-2026-82329 only, an interim workaround exists for organizations that cannot immediately upgrade: generate a random value and add it as an extra join key in system.yaml to prevent unauthorized service registration. No interim workaround exists for the two-CVE chain.

The correct order of operations matters. Upgrade first — rotating secrets on a still-vulnerable server hands any remaining attacker the new credentials. Then: rotate the Artifactory cluster join key; revoke all access tokens issued since August 28; audit administrator accounts for unexpected entries; and compare repository and configuration state against a known-good baseline.

How to Know If Your Server Was Already Hit

Wiz published specific behavioral detection signatures for all three CVEs. For the CVE-2026-42018/42016 chain, the highest-confidence indicator is a request to the token endpoint returning HTTP 401 on the standard path followed by HTTP 200 on a path variant — from the same client within a short window. That sequence indicates an attacker probing for the vulnerable variant before exploiting it.

For the chain exploitation broadly, defenders should search Artifactory request logs for token:anonymous performing admin operations including token creation at /access/api/v1/tokens, plugin reloading, user enumeration, or reading repository configuration. Any low-privilege identity doing administrator-class work is a compromise indicator.

For CVE-2026-82329, the trigger is a POST to /access/api/v1/registry/join returning HTTP 200 or 201. Wiz advises correlating those requests with follow-on actions: administrator account creation (PUT /api/security/users/<username>), configuration extraction (GET /api/system/configuration), token enumeration, or SSH key attachment to created users.

The attacker-created accounts that are most dangerous are the ones that do not look like proof-of-concept handles. An account named jfrog-distribution or backup-service on a server where no such service was intentionally configured is an implanted persistent admin account, not a benign service identity.

---

Frequently Asked Questions

Does upgrading JFrog Artifactory to a patched version remove attacker-created admin accounts?

No. Upgrading patches the entry path but does not delete accounts, revoke tokens, or rotate cluster join keys that attackers created or stole before the patch was applied. Any server that was internet-accessible and unpatched between August 15 and September 8 should be treated as potentially compromised. The required steps after upgrading — rotating the join key, revoking tokens issued since August 28, auditing administrator accounts, and reviewing configuration and repository state against a known baseline — are each separately necessary.

How did attackers stay hidden in logs during the CVE-2026-42016 chain?

The escalated administrator token produced by the chain retained the "anonymous" username, so every privileged action the attackers took appeared in Artifactory logs under token:anonymous rather than under a named account. Defenders hunting for unexpected named administrators find nothing — because the attacker never registered a named identity until after already holding administrator scope. Detection requires hunting for privilege anomalies: specifically, any low-privilege or anonymous identity performing token creation, plugin operations, user enumeration, or configuration reads.

Which versions of JFrog Artifactory are vulnerable?

CVE-2026-82329 (CVSS 9.8) affects all builds in the 7.111, 7.117, 7.125, 7.133, 7.146, and 7.161 release branches prior to their respective fixed builds (7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20). CVE-2026-42016 (CVSS 8.1) affects versions prior to 7.133.11. CVE-2026-42018 (CVSS 7.5) affects the 7.111 through 7.146 branch ranges below their respective fixes. JFrog Cloud instances were patched automatically and are not affected.

What makes a compromised Artifactory server dangerous beyond the server itself?

Artifactory sits at the center of software build pipelines as the authoritative source for the packages builds consume. Administrator access lets an attacker read every artifact the organization ships, publish malicious packages under trusted coordinates that downstream builds will install automatically, retrieve credentials Artifactory uses to reach upstream registries, and extract cluster join keys that enable lateral movement to other nodes. A compromised Artifactory instance is effectively a persistent foothold inside every build pipeline that depends on it — damage does not stop at the repository boundary.