Three Artifactory Auth Bypasses Chained: Anonymous Token to Admin in Under Five Minutes

Detected by CaverLive detection for 2 CVEs in the RedEye Intel Feed →

TL;DR

What: Multiple threat actors chained three JFrog Artifactory authentication flaws, CVE-2026-42018, CVE-2026-42016 and CVE-2026-82329, to reach administrator on self-hosted instances and install a custom Rust backdoor.
Impact: An admin on Artifactory owns the build artifact store: repository contents, service credentials, the cluster key, and every downstream pipeline that pulls from it, and Wiz and watchTowr measured 49 to 62 percent of internet-reachable instances as vulnerable to at least one flaw.
Fix / mitigation: Upgrade self-hosted Artifactory to 7.161.20, 7.146.38, 7.133.29, 7.125.20, 7.117.28 or 7.111.21 depending on your release line, then hunt for unexpected admin accounts, Groovy plugins and SSH keys because patching does not evict an attacker who is already resident.
Who's at risk: Any organization running self-hosted JFrog Artifactory reachable from the internet, and by extension every team that consumes packages or images from it.

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.

Disabled anonymous access is not a mitigation here

CVE-2026-42018 issues a JWT for the internal anonymous user regardless of whether anonymous access is turned off in your configuration. If your risk register lists anonymous access as disabled and calls the exposure handled, that entry is wrong. The only fix is the version upgrade.

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.

Patching is step one of four

Upgrading closes the door. It does not remove the admin account they created, the Groovy plugin they uploaded, the SSH key they added, or the cluster key they copied. Plan for all four: upgrade, audit accounts and plugins, rotate the cluster key and every credential stored in the instance, then verify artifact checksums for anything published during the exposure window.

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.

Fix It Yourself

Everything above is what happened. This is what to run. The check commands change nothing.

Check whether you are exposed

Print the running Artifactory version to compare against the fixed list

curl -s -H "Authorization: Bearer $JFROG_TOKEN" https://artifactory.example.com/artifactory/api/system/version

List every Groovy user plugin on disk so you can spot files you did not deploy

ls -la "${JFROG_HOME:-/opt/jfrog}/artifactory/var/etc/artifactory/plugins/"

Find calls to the plugin execution endpoint in the request log, the post-admin execution path

grep -F "/api/plugins/execute/" "${JFROG_HOME:-/opt/jfrog}/artifactory/var/log/request.log" | tail -50

Close it

Pull the fixed image for the 7.161 line, swap the tag for your own release line from the fixed list

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

Quarantine an unrecognized Groovy plugin by moving it out of the plugins directory, preserving it for forensics

mkdir -p /var/tmp/artifactory-plugin-quarantine
mv "${JFROG_HOME:-/opt/jfrog}/artifactory/var/etc/artifactory/plugins/SUSPECT.groovy" /var/tmp/artifactory-plugin-quarantine/

Inventory active access tokens so you can revoke the ones you do not recognize in the Access UI

curl -s -H "Authorization: Bearer $JFROG_TOKEN" https://artifactory.example.com/access/api/v1/tokens

Prompts for the agent you already run

Paste this first, to find out whether you are exposed and whether anything is already resident.

Check this host for the JFrog Artifactory exploitation chain reported on September 11, 2026. Step 1: find JFROG_HOME, then read the running version from the artifactory system.yaml or by calling /artifactory/api/system/version, and tell me whether it is at or above the fixed version for its release line, where the fixed versions are 7.161.20, 7.146.38, 7.133.29, 7.125.20, 7.117.28 and 7.111.21. Step 2: list every file in var/etc/artifactory/plugins/ with timestamps and print the first 40 lines of any .groovy file modified after July 1, 2026. Step 3: grep var/log/request.log and var/log/artifactory-request.log for the string /api/plugins/execute/ and for POST requests to /access/api/v1/tokens, and summarize source IPs by count. Step 4: list local accounts with recently added entries in ~/.ssh/authorized_keys. Show me the exact commands you ran and their raw output for each step. Do not delete, move, modify or quarantine any file, and do not restart the Artifactory service. Stop and report your findings.

Paste this after the check confirms you are on a vulnerable version and you are ready to plan remediation.

Build me a remediation plan for a self-hosted JFrog Artifactory instance vulnerable to CVE-2026-42018, CVE-2026-42016 and CVE-2026-82329. Identify the current deployment method by inspecting the host, either docker compose, helm, RPM or DEB, and show me the file that defines the current version. Then write out, without executing them, the exact commands to upgrade to the correct fixed version for the installed release line, the commands to enumerate admin users and access tokens through the Access API, and a checklist of every credential stored in this instance that needs rotation including the cluster key. Print the plan and stop. Execute nothing that changes state, upgrades a package, restarts a service or revokes a token until I approve each step individually.

What to alert on

The highest value observable is a POST to the plugin execution endpoint in the Artifactory request log. Alert on any line in artifactory-request.log or request.log where the request path begins with /api/plugins/execute/ and the source address field falls outside your CI and administrator ranges, because legitimate plugin execution comes from a small, stable set of internal callers and everything else is either a misconfiguration or this attack chain. Pair it with two correlating signals. First, in the Access audit log, artifactory-access.log or access-security-audit.log, alert on user creation and permission grant events where the new principal has admin true and the acting principal is the anonymous internal user or an account created in the same session. Second, at the endpoint, alert on process lineage where the Artifactory JVM, java running artifactory.jar, spawns /bin/sh, /bin/bash, curl or wget, since the Groovy plugin path executes shell commands as the Artifactory service account and that parent-child pair has no legitimate cause in normal operation. If you have only one detection to write today, write the third one.

Questions about your exposure?

RedEye Security provides assessments for organizations that need to understand their real risk.

Talk to us