Three Artifactory Auth Bypasses Chained

Between August 15 and September 8, 2026, multiple threat actors chained two JFrog Artifactory authentication flaws to take administrator control of self-hosted instances, then installed a custom Rust backdoor with command and control capability. Researchers at Wiz and watchTowr, who documented the campaign, measured that 49 to 62 percent of internet-reachable Artifactory instances were vulnerable to at least one of the three flaws involved. On September 11, CISA added CVE-2026-42018 and CVE-2026-42016 to the Known Exploited Vulnerabilities catalog, one week after adding CVE-2026-82329, and gave federal agencies two weeks to patch.

The number that should get your attention is not the exposure percentage. It is the time to admin: under five minutes from first request to a persistent administrative account. This is not a chain that requires a skilled operator babysitting a session. It is a script.

The three flaws

• CVE-2026-42018, improper authentication, patched August 12, 2026. Returns a valid JSON Web Token for the internal anonymous user even when anonymous access is explicitly disabled. That last part matters: the control most teams rely on does not stop it.
• CVE-2026-42016, insufficient token validation, patched July 27, 2026. Takes a low or no privilege token and escalates it to administrator.
• CVE-2026-82329, authentication bypass, patched August 28, 2026. Remotely exploitable with no credentials at all to forge administrator tokens, and exploited separately from the other two.

Note the patch dates against the exploitation window. CVE-2026-42016 had a fix available on July 27, nineteen days before the campaign started. CVE-2026-42018 was patched on August 12, three days before. Neither of these was a zero day during the observed attacks. This was a patch latency failure at scale, on a system that most organizations treat as internal infrastructure and therefore patch on a quarterly cadence, if that.

The chain, step by step

• Request a token through CVE-2026-42018 and receive a valid JWT for the anonymous internal user.
• Feed that token to CVE-2026-42016 and escalate to administrator, or forge an admin token directly through CVE-2026-82329.
• Create a new administrative account for persistence that survives token revocation.
• Upload a malicious Groovy plugin, which Artifactory supports natively for user extensions, giving arbitrary command execution as the Artifactory service account.
• Call the plugin execution endpoint to run shell commands, pull second stage payloads into temporary directories, and drop the Rust backdoor.
• Update the plugin scripts periodically to keep the access working across restarts and upgrades.

The Groovy plugin step is the part worth sitting with. This is not a memory corruption exploit or a fragile ROP chain. It is a documented, supported product feature being used exactly as designed, by someone who should not have been an admin. Every detection built around exploit signatures misses it, because after step two there is no exploit left to detect. There is only an administrator doing administrator things.

What they took

Post-compromise activity across the observed intrusions included enumerating every repository and stored credential, deploying webshells, exfiltrating configuration, adding SSH keys to newly created accounts, and extracting the cluster key. That last item is the one that outlives your incident response. The Artifactory cluster key protects encrypted configuration and stored secrets. An attacker holding it can decrypt secrets pulled from a backup or a replicated node later, without touching your network again.

The credential enumeration is the pivot. Artifactory holds the service accounts your CI runners use, your Docker registry pull tokens, your npm and Maven publish credentials, and frequently cloud provider keys wired into remote repository configurations. An admin session on Artifactory is a credential harvest across your entire build estate.

Why this counts as a supply chain incident

Artifactory sits between your developers and everything they build. An attacker with write access to a repository can replace an internal package or a base image, and every pipeline that pulls it inherits the change with a valid checksum, because the artifact store computed the checksum after the swap. Nobody downstream sees an anomaly. The build is green, the signature checks that most teams have not implemented would be the only control that catches it, and the poisoned artifact propagates at whatever rate your teams deploy.

The public reporting does not confirm artifact tampering in these intrusions. Treat that as an open question in your own environment rather than a clean bill of health. If your instance was exposed and unpatched during the window, artifact integrity is in scope for the investigation, not out of it.

Priority order for the next 48 hours

• Confirm your running version against the fixed list: 7.161.20, 7.146.38, 7.133.29, 7.125.20, 7.117.28, 7.111.21. Pick the one matching your release line.
• If the instance is internet-reachable and was not patched before August 15, assume compromise and open an investigation rather than closing the ticket on the upgrade.
• List every administrative account and every access token, and compare against a known good record from before August 2026.
• Inventory the user plugins directory. Any Groovy file you cannot trace to a change request is an incident.
• Search request logs for calls to the plugin execution endpoint from external addresses.
• Rotate the cluster key and every credential the instance stored, including CI service accounts and remote repository keys.

JFrog Cloud instances were patched by the vendor. This is a self-hosted problem, which means it lands on teams who installed Artifactory years ago, put it behind a load balancer with a public certificate for remote developer access, and have not thought about its patch cadence since. That description fits a large share of the 49 to 62 percent.