JFrog Artifactory Under Attack: Affected Versions, IOCs, and the First-Hour Response Runbook

CVE-2026-82329, reported by Wiz in September 2026, is a critical severity (CVSS 9.8) authentication bypass in self-hosted JFrog Artifactory that gives an unauthenticated attacker with network access administrator control of the repository. Two further JFrog Artifactory vulnerabilities, CVE-2026-42018 and CVE-2026-42016, were chained in a separate campaign to reach the same outcome, in some cases moving from the first unauthenticated request to a new administrator account in under five minutes. This post is written for AppSec engineers, platform teams, and incident responders working active exposure as of September 2026, and covers the affected version matrix, the two exploitation paths, the indicators of compromise, the first-hour runbook, and the downstream question that outlives the patch.

Three JFrog Artifactory Flaws Were Exploited Along Two Separate Paths

Wiz reported in-the-wild exploitation of three JFrog Artifactory vulnerabilities. CVE-2026-42018 and CVE-2026-42016 were chained together to escalate an anonymous token to administrator scope, and CVE-2026-82329, a critical authentication bypass affecting Artifactory under its default configuration, was exploited separately to reach administrator access on its own.

The timeline is tight. Wiz observed chained exploitation of CVE-2026-42018 and CVE-2026-42016 between August 15 and September 8, 2026. A public exploit for CVE-2026-82329 appeared on September 1 and mass scanning followed, with exploitation observed between September 1 and September 8. CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities catalog on September 2 and set a September 5 remediation deadline for federal agencies.

Scale is the number worth carrying into the incident review. Wiz assessed that between 49% and 62% of reachable Artifactory instances are vulnerable to at least one of the three flaws. CVE-2026-42016 was published on July 27 with credit to OpenAI researchers, so the patch predated the exploitation wave by roughly three weeks. The exposure window was a patching cadence problem, not a zero-day problem.

JFrog Cloud instances required no customer action. Everything below applies to self-hosted Artifactory.

Public reporting does not agree perfectly on the upper bound of the 7.146.x branch across the three advisories. Diff the table above against JFrog's own release advisory for your branch before acting on a single version string.

How the Attack Chain Turns an Anonymous Token Into an Administrator

The chain starts with an unauthenticated request that returns a token Artifactory should never hand out, and ends with an administrator token that Artifactory mints itself. Artifactory validated a token's signature and issuer but never checked what the token was permitted to do.

Stage One: Anonymous Token Disclosure

CVE-2026-42018 causes Artifactory to return an internal anonymous-user token to a caller who has not logged in, even when anonymous access is switched off. Wiz observed the request against POST /access/api/v1/aws/token/, and the trailing slash is the whole bypass: the bare path rejects the caller, the variant does not.

Stage Two: Scope Escalation

CVE-2026-42016 allows that low-privilege token to be exchanged at POST /access/api/v1/tokens for a token carrying administrator scope. The root cause is a missing authorization check rather than a broken cryptographic one. Artifactory confirmed who issued the token and that the signature held, then granted an escalation the original token had no right to request.

Stage Three: Persistence and Secret Collection

With administrator scope, the attacker created accounts through PUT /api/security/users/<username> or /access/api/ui/users/<username>, then swept configuration and credentials through GET /api/system/configuration, GET /access/api/v1/system/security/join_key, GET /access/api/security/users, and GET /access/api/security/tokens. The join key matters most: that value lets a service register with the platform.

Stage Four: Code Execution on the Artifactory Host

Execution arrived through Artifactory's own plugin framework. The attacker uploaded malicious Groovy plugins and invoked them via GET/POST /api/plugins/execute/<plugin>. A dropper then pulled a binary over HTTP and wrote the binary to a world-writable directory such as /tmp, /var/tmp, or /dev/shm. The final payload Wiz recovered is a custom Rust backdoor with command-and-control capability.

The Separate Path Through CVE-2026-82329

CVE-2026-82329 skips the chain entirely. An unauthenticated attacker with network access reaches administrator control under Artifactory's default configuration, and the observed signature is a POST /access/api/v1/registry/join returning 200 or 201. This is the flaw CISA listed and the one with a public exploit, which is why scanning volume jumped on September 1.

An Artifact Repository Compromise Is a Distribution Problem

A repository manager sits at the narrowest point of the software supply chain, so compromising one server converts a single takeover into an unknown number of downstream builds. The question that outlives the patch is not whether the Artifactory instance was owned. The question is what that instance handed to applications while the instance was owned.

Every service in a typical estate pulls dependencies, base images, and internal artifacts through the same repository. Administrator access on that host means the ability to modify, replace, or add artifacts that hundreds of builds consume without further scrutiny, and builds do not re-examine what a trusted internal registry serves them.

One boundary is worth stating rather than blurring. Public reporting documents administrator takeover, rogue accounts, Groovy plugin execution, and backdoor deployment. Public reporting does not, at the time of writing, document confirmed artifact tampering at scale. Treat artifact integrity as the thing to hunt for, not the thing already proven.

Indicators of Compromise (IOCs) and Behavioral Signals

Hunt for low-privilege identities performing high-privilege actions. The single clearest signal is an administrator action recorded in the logs as token:anonymous rather than under a named account.

Administrator account names observed:

Log, file system, and network indicators:

Wiz also published attacker source addresses for retrospective log search: 149.102.229.150, 186.247.79.240, 182.62.201.69, 146.19.216.120, 185.190.58.172, 45.61.176.88, 223.144.227.110, 129.121.56.234, 16.54.250.190, 105.188.75.16, 103.124.165.42, 176.88.121.152, 155.254.120.23, 220.246.124.92, 15.157.64.113, 104.28.251.139, and 137.184.111.69. Search history against these addresses, and resist turning a September snapshot into a permanent blocklist.

Immediate Response: The First-Hour Runbook

Patch first, then assume the patch fixed nothing that already happened. A patch does not revoke tokens that were already minted, which makes credential rotation and account review the real work of the first hour.

1. Upgrade self-hosted Artifactory to the fixed build for your release branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. JFrog Cloud instances need no action.
2. Add a random extra join key in system.yaml so only your own keys are accepted when a service registers. JFrog documents this as the mitigation for CVE-2026-82329, and the control still earns its place after patching.
3. Rotate the platform join key and revoke access tokens issued since August 28. This is the step teams skip, and every token minted during the exposure window stays valid after the upgrade, including tokens scoped to CI systems and downstream services.
4. Review every administrator account against the naming patterns above, and treat any account you cannot tie to a person or a provisioning record as hostile.
5. Audit the plugins directory and the /api/plugins/execute/ access logs. Remove any Groovy plugin that does not originate in your own source control.
6. Inspect the host for writes to /tmp, /var/tmp, and /dev/shm by the Artifactory service account, and check disk against the payload hash above.
7. Pull the configuration change history and repository permission changes for the exposure window, then diff against your last known-good export.
8. Treat any internet-reachable unpatched instance as compromised until the log review says otherwise, rather than the other way around.

Patching the Server Closes the Door. The Blast Radius Question Stays Open.

This compromise happened in build infrastructure, which is server and platform territory rather than application security territory. What an application security platform can answer is the question that arrives the next morning: which running applications actually loaded something that passed through the repository during the exposure window, and does that code execute.

Saying that plainly matters more than claiming coverage. Kodem does not protect the Artifactory host, does not watch for rogue administrator accounts on a vendor server, and does not scan generic artifacts sitting in a repository. Those are infrastructure and endpoint controls, and Kodem occupies the application layer.

Downstream is where the evidence changes the answer. A manifest records what a team declared. Runtime intelligence records what actually loaded, including shadow dependencies present at runtime and absent from the manifest. Three questions follow, and all three are answerable from execution evidence rather than from a build log reconstruction: whether the component is present in the running application, whether the specific function executes or sits inert on disk, and whether that execution path is exposed to attacker-controllable input.

Kodem's runtime-powered SCA resolves affected components across direct and transitive trees and then narrows the list to what loads and executes, with malicious-package detection covering typosquats, dependency confusion, and compromised packages in supported ecosystems. The difference between a component being present and that component having executed is the subject of proving vulnerable code was executed in production. Sensor deployment is the prerequisite for the runtime half of that picture.

Hardening the Repository Layer Against the Next Exposure Window

Assume the next control-plane flaw lands on a similar cadence, since the patch for CVE-2026-42016 shipped in July and the exploitation wave ran through August and September. Every control below is a configuration change available today, and none of them require knowing the next campaign's indicators.

1. Take the Artifactory web interface and API off the public internet, behind VPN or an identity-aware proxy. Every path in this chain required network reachability first.
2. Set a patch SLA for repository and CI control-plane software measured in days rather than quarters. Three weeks of latency was the whole exposure here.
3. Rotate platform join keys and long-lived access tokens on a schedule, so a stolen token has a short useful life independent of any incident.
4. Alert on administrator account creation and permission changes, routed to a channel a human reads. The rogue accounts in this campaign were named to survive a casual glance.
5. Treat the plugin framework as code. Source-control every Groovy plugin and alert on any plugin file appearing outside that pipeline.
6. Pin and verify artifact digests in builds, so a modified artifact fails the build rather than shipping quietly.
7. Keep a runtime inventory of what applications actually load, so the blast-radius question has an answer before anyone needs that answer. Pair it with the open source security workflow your team already runs on dependency findings.

What This Incident Signals About the Next One

The last two years of supply chain incidents targeted packages. This one targeted the pipe that packages travel through, and that shift changes where the leverage sits.

• Registry and repository control planes are now a primary target, because one server yields many downstream builds. The economics beat compromising a single popular package.
• Exploit-to-admin time is collapsing. Under five minutes from first request to a new administrator account means a detection window measured in hours is not a detection window.
• Scanner output alone cannot answer the post-incident question. What a team declared and what actually loaded are different sets, and only one of those two sets describes real exposure.

One falsifiable prediction: the next wave targets the other control planes in the same position, specifically package registries, CI orchestrators, and internal proxy caches, and at least one incident in the next twelve months gets discovered downstream in a running application rather than on the server that was breached. For the package-layer counterpart to this infrastructure-layer incident, see the Kodem keyv supply chain attack runbook from August 4, 2026.

Frequently Asked Questions

References

1. Wiz. September 2026. Artifactory Under Attack: In-the-Wild Exploitation of CVE-2026-42016, CVE-2026-42018 and CVE-2026-82329. Wiz.
2. The Hacker News. September 2026. Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors. The Hacker News.
3. BleepingComputer. September 2026. Artifactory flaws chained in attacks deploying backdoor malware. BleepingComputer.
4. CISA. September 2, 2026. Known Exploited Vulnerabilities Catalog. CISA.
5. NIST National Vulnerability Database. CVE-2026-82329. NVD.