Artifactory Under Attack: In-the-Wild Exploitation of CVE-2026-42016, CVE-2026-42018 & CVE-2026-82329

Change log:

• September 11, 2026 3PM UTC: Corrected the HTTP method for CVE-2026-82329 and the impacted fixed versions for CVE-2026-42018.

• September 17, 2026 7PM UTC: Added section on malicious Groovy plugins observed in post-exploitation activity and additional IOCs.

Wiz Research has identified active, in-the-wild exploitation of three critical and high-severity vulnerabilities affecting JFrog Artifactory: CVE-2026-42016, CVE-2026-42018, and CVE-2026-82329. Attackers are chaining these vulnerabilities to bypass authentication, escalate privileges, and gain administrative control over vulnerable Artifactory instances. Observed post-exploitation activity includes the creation of persistent administrator accounts, the deployment of malicious Groovy plugins for code execution, and the installation of Rust-based backdoors to establish persistence. This blogpost provides an analysis of the exploitation patterns observed, the impact on affected organizations, and actionable guidance for security teams to detect and remediate these threats.
We will continue to update this blogpost as new information becomes available.

These CVEs are trivial to exploit, a handful of unauthenticated HTTP requests. If your instance was exposed while vulnerable, assume compromise and hunt for post-exploitation artifacts. Upgrading closes the door but does not evict an attacker who is already inside: the admin users and plugins described below survive restarts, and stolen Access signing keys let an attacker mint valid tokens indefinitely without ever returning to the host.

CVE-2026-42018: Exposure of an internal anonymous-user token

CVE-2026-42018 is an improper-authentication vulnerability that may cause Artifactory to return an internal anonymous-user token to an unauthenticated requester, even when anonymous access is disabled. An attacker could use the exposed token to access resources available to the internal anonymous identity, potentially exposing sensitive artifacts or repository data.

CVE-2026-42016: Token scope validation flaw

CVE-2026-42016 is a privilege-escalation vulnerability caused by insufficient token validation. Artifactory validates the token’s signature and issuer but does not properly enforce its intended scope. As a result, an attacker with low-privileged access may be able to use a valid token to perform unauthorized actions and gain elevated privileges.

CVE-2026-82329: Unauthenticated access to administrative privileges

CVE-2026-82329 is a critical authentication-bypass vulnerability affecting Artifactory under its default configuration. An unauthenticated attacker with network access to a vulnerable instance may be able to obtain administrative privileges, potentially gaining complete control over the Artifactory deployment and the artifacts, credentials, and integrations it manages.

What is the risk to cloud environments?

Our data indicates that 67% of organizations running JFrog Artifactory had at least one vulnerable instance when CVE-2026-42016 was first published on July 27. Similar levels were observed for CVE-2026-42018 (69% at publication on Aug 12) and CVE-2026-82329 (67% at publication on Aug 28).

Patching velocity has been slow for the lower-severity CVEs. As of six weeks after the first disclosure, 59% of organizations remain vulnerable to CVE-2026-42016, and CVE-2026-42018 has only declined from 69% to 62% over four weeks. However, CVE-2026-82329 has seen significantly faster remediation, dropping from 67% to 49% within two weeks of publication, likely due to its critical severity rating driving more urgent attention from security teams.

What evidence of exploitation has Wiz Research identified?

Wiz Research has confirmed in-the-wild exploitation of all three vulnerabilities across multiple environments.

CVE-2026-42018 and CVE-2026-42016 Exploitation

Between August 15 and September 8, 2026, we observed multiple actors chain CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory instances. Across multiple cases we observed a custom Rust backdoor with C2 capabilities being dropped. Wiz Research is not aware of any prior public reporting of in-the-wild exploitation involving those two CVEs. Neither vulnerability grants administrative control on its own. CVE-2026-42018 exposes a token for the internal anonymous user, and CVE-2026-42016 lets that low-privileged token be escalated to admin scope. Together, the two can turn an unauthenticated request into an admin-scoped token in two steps.

Every exploitation followed a similar shape. An unauthenticated POST /access/api/v1/aws/token/ with a trailing slash returned HTTP 200 with a JWT for the internal anonymous user, exploiting CVE-2026-42018. The actor then exchanged that JWT for an admin-scoped token through POST /access/api/v1/tokens , which returned HTTP 200 and exploited the CVE-2026-42016 scope-validation flaw. The escalated token kept the anonymous username but carried admin authority, so later requests appear with an actor of token:anonymous. In some instances, actors moved from the first request to a created admin account in under five minutes.

A request sequence looked like this:

• POST /access/api/v1/aws/token/ 200 anonymous JWT for internal anonymous user (CVE-2026-42018)

• POST /access/api/v1/tokens 200 anonymous admin-scoped token (CVE-2026-42016)

• PUT  /api/security/users/<username>  or /access/api/ui/users/<username> 201  token:anonymous persistent admin account created

Since admin access is granted to the actor, post-exploitation varies. No single actor ran every step below. Across compromised Artifactory instances, we observed:

• Persistent admin accounts - PUT /api/security/users/<username> or /access/api/ui/users/<username>

• Groovy plugin deployment - malicious plugins installed through Artifactory’s native plugin framework to gain arbitrary code execution on the server

• Ad-hoc command execution - shell commands run through the plugin endpoint GET or POST /api/plugins/execute/<plugin>, which include recon and file enumeration commands

• Second-stage payload delivery - a dropper fetched a binary over HTTP, wrote it to a world-writable path such as /dev/shm, /tmp, or /var/tmp, and established C2 communication

• Webshell upload - actors occasionally uploaded a script into a repository path to maintain follow-on access

CVE-2026-82329 Exploitation

This vulnerability has been reported by several vendors as being actively exploited in the wild, and has also been added to CISA KEV. Between September 1 and September 8, 2026, we observed several threat actors carry out successful exploitations of CVE-2026-82329. Every initial exploitation followed the same pattern: an unauthenticated POST /access/api/v1/registry/join returning HTTP 200 or 201 with an admin-scoped token in the response body, followed by post-exploitation activities. Rather than a unified attack chain by a single threat actor, the following behaviors represent distinct patterns observed across various affected Artifactory environments: 

• Configuration exfiltration - GET /api/system/configuration.

• Persistent admin accounts - PUT /api/security/users/<username> with customData.artifactory_admin: true.

• Long-lived credentials - token minting via /access/api/v1/tokens.

• Cluster key theft - several operators pulled the join key directly from /access/api/v1/system/security/join_key.

• Enumeration - Users, repos and tokens enumeration with GET /access/api/repositories/<name> or  /api/repositories/<name>,  GET /access/api/security/users or /api/security/users and GET /access/api/security/tokens or /api/security/tokens

• Bring-your-own-Key - In some cases we also observed attackers attaching their own SSH keys to the created users.

Most attacker-created accounts carry proof-of-concept boilerplate: usernames such as Nxploited_[a-zA-z0-9]{3}, labadmin_<hex>, 0xTerror, and svc_[a-zA-z0-9]{8}. Some actors created more legitimate-looking accounts like: jfrog-distribution , jfrog-insight, repo-service and more.

Malicious Groovy plugins used in post-exploitations

Across the intrusions we analyzed, the most consistent post-exploitation step was the deployment of an Artifactory user plugin, a Groovy file dropped into $JFROG_HOME/var/etc/artifactory/plugins/ and exposed at /artifactory/api/plugins/execute/<name>. This is an attractive persistence mechanism because user plugins run unsandboxed inside the Artifactory JVM with the service account's full privileges, are reloaded automatically on restart, and are reachable over ordinary, TLS-wrapped API traffic that is indistinguishable at the network layer from normal registry usage. Critically, a plugin dropped through CVE-2026-42018 / CVE-2026-42016 or CVE-2026-82329 survives patching, upgrading Artifactory closes the entry point but leaves the backdoor in place.

We recovered six distinct plugins, which fall into three tiers of sophistication.

Tier 1 - disposable command shells

rce.groovy and cmd.groovy are minimal, single-purpose droppers: a GET execution that takes a command in a query parameter (base64-encoded in rce, cleartext in cmd), pipes it through /bin/sh -c or bash -c, and returns stdout+stderr in the response body. Both default to id when no parameter is supplied - the classic "am I root?" check. Their blunt naming (rce, cmd) and lack of any concealment suggest opportunistic actors or security researchers validating access rather than establishing durable footholds.

jwtToken.groovy or uploadFile.groovy is the same primitive with one important difference: its execution block declares users: ['anonymous', 'admin']. which lets anyone call it. A plain GET /artifactory/api/plugins/execute/jwtToken?token=<base64> runs shell commands with no credentials - and it keeps working after the server is patched. The name is picked to look like part of Artifactory's own token handling.

Tier 2 - credential and cluster-key harvesting

JFrogImage.groovy is a purpose-built exfiltration toolkit fronted by a single GET execution with four operating modes:

• e=1 - configuration secret export. Enumerates LDAP settings (including managerDn / managerPassword), Atlassian Crowd integration, the mail server, all configured proxies, and every remote repository with stored credentials. Each value is passed through CryptoHelper.decryptIfNeeded(), so the attacker receives plaintext upstream credentials. For an artifact registry this is a direct pivot into the organization's upstream registries, SSO directory, and outbound proxy infrastructure.

• u=1 - full user and token database dump.  First it finds the database password, looking in db.properties, system.yaml, and the JF_SHARED_DATABASE_* environment variables used in containers, and decrypting it if needed. Then it logs into the database as Artifactory itself, finds every table with user or token in the name, and dumps up to 5,000 rows from any column that looks like a password, hash, salt, email, or token.

• k=1 - Access signing material. Walks /var/etc/access/keys, /var/bootstrap/etc/access/keys, and the /opt/jfrog/... and /var/opt/jfrog/... install paths, returning base64 content for every .crt, .key, token.json, and generate.token.json.

• ts=, x=, c= — shell execution. These are three alternative ways to pass the same thing - the command to run, differing only in how hard they are to read. c= is cleartext. x= is URL-safe base64. ts= is the obfuscated one: the command is XORed against the hardcoded key jfImg2026, base64-encoded, and then the base64 string is reversed.

Two details stand out. First, every mode returns its output by throwing a RuntimeException, so results are delivered in the errors[0].message field of an HTTP 500 response. Detection logic that looks for successful (2xx) plugin executions will miss this backdoor entirely. Second, the file opens with a comment claiming "authorized testing," a plausible-deniability header we have seen reused across unrelated tooling.

The Access key theft in k=1 (and in the plugins below) deserves separate emphasis: per JFrog's documentation, private.key is the key that signs Access tokens, and the matching root.crt is the public certificate used to verify those signatures. An attacker holding private.key can therefore forge valid tokens for any user and any scope, indefinitely, without ever touching the compromised host again and patching does not revoke it. Any instance found with these plugins therefore needs its token certificate reset, not merely an upgrade.

Tier 3 - resident implants with anti-forensics

metrics.groovy is the stealthiest sample. It exposes a single POST execution that reads a one-word command from the request body:

• implant installs a second backdoor that lives only in memory. It reaches into the running Tomcat server, compiles a new servlet filter on the fly, and inserts it as traceFilter at the front of the chain, so it sees every request before Artifactory does. The filter stays dormant until it sees the attacker's password. A request whose X-Request-Trace header hashes (MD5) to a993c4553636e1606e0072a5eb1ed6f0 gets its body executed as Groovy code - full remote code execution. Every other request passes through untouched, so the server behaves completely normally. The same filter also performs anti-remediation and rival lockout: any request without the attacker's X-Trace-Pass bypass header (MD5 4948ebd2d809972d9c60751011b0492f) that targets a URI containing registry/join, api/plugins, or systemUpload is rejected with HTTP 400. This closes CVE-2026-82329's exploitation endpoint against competing actors and prevents the legitimate administrator from listing, reloading, or removing plugins. Defenders investigating a suspected compromise may find the plugin API mysteriously broken, that is itself an indicator.

• getkey reads the Access private.key, resolving its path through reflection on ArtifactoryHome and com.jfrog.sysconf.SysLayout rather than hardcoded paths.

• delete schedules the plugin to remove itself from disk after a ten-minute delay, retrying five times. The on-disk artifact vanishes while the injected in-memory filter keeps running until the JVM restarts - a deliberate split between the loader and the implant.

httpSession.groovy is also carefully disguised plugin: it carries the docstring "HTTP session refresh used by support," declares description: 'HTTP session refresh', names its execution refresh, and restricts itself to users: ['admin'] so it reads as a legitimate support utility in a plugin listing. Its JSON request body selects an operation:

• open / send / recv / close - a network tunnel. These four operations let the attacker use Artifactory as a relay into the internal network. open names a host and port and tells the server to connect to it; send and recv then push and pull raw data through that connection, and close shuts it down. Up to 12 connections can run at once. The effect is that the attacker can reach anything Artifactory can reach - build servers, internal registries, databases - while all their traffic looks like ordinary authenticated calls to a plugin API. The outbound connections are also made with Proxy.NO_PROXY, deliberately bypassing any egress proxy the organization has configured, so they skip the monitoring that would normally see them.

• default (sync) - command execution. Runs a base64-encoded shell command and returns its output. It gives up after 45 seconds and truncates anything over 1 MB, so a long-running or noisy command cannot hang the server and give the backdoor away. It also checks the operating system first and simply declines to run on Windows — this implant is built for Linux hosts only.

• export and certs replicate the credential and Access-key harvesting described above, with certs additionally sweeping the trusted subdirectory.

• purge - anti-forensics. Truncates every request*.log in the Artifactory log directory to zero bytes and deletes httpSession.groovy, httpSession.groovy.backup, and httpSession.groovy.force.delete from the plugins directory, then tears down all open tunnels. The targeted log is precisely the access log that the endpoint-based detections for these CVEs depend on.

How can Artifactory users detect exploitation?

CVE-2026-42018

The exploit sends /access/api/v1/aws/token/. The highest-confidence signature is behavioural: a 401 on the bare path followed by a 200 on any variant of it, from the same client, inside a short window. That pattern is an operator confirming the vulnerable variant before relying on it, and it is not something a normal client produces.

CVE-2026-42016

The detectable anomaly is entirely behavioural - a mismatch between who the identity is and what it is doing:

• The internal anonymous identity, or any low-privilege identity, minting tokens at POST /access/api/v1/tokens or POST /artifactory/api/security/token. 

• A low-privilege identity enumerating users at GET /access/api/v1/users or GET /artifactory/api/security/users/<username>.

• A low-privilege identity reading or writing /artifactory/api/plugins.

CVE-2026-82329

Exploitation will trigger a POST request to /access/api/v1/registry/join with successful (200 or 201) status code. But this indication on its own is not enough to determine exploitation. Correlate those requests with known attacker actions, such as:

• PUT  /api/security/users/<username>  201 persistent admin account created

• GET /api/system/configuration 200 Configuration extraction

• GET /access/api/security/tokens 200 tokens enumeration

• GET /access/api/security/users 200 users enumeration

Which products are affected?

What actions should security teams take?

Organizations running JFrog Artifactory should identify affected instances and upgrade to a fixed version as soon as possible. Depending on the deployed release branch, fixed versions include 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20 or later. In addition, customers should review logs and refer to the "How can Artifactory users detect exploitation?" section for guidance on identifying potential indicators of compromise.

Given that exploitation may be possible remotely without authentication under the default configuration, organizations should prioritize internet-accessible Artifactory instances and restrict network access to trusted users and systems where possible. Organizations should also review Artifactory authentication and administrative activity for unexpected privileged access.

How can Wiz help?

Wiz customers should refer to the pre-built advisory in the Wiz Threat Intel Center for actionable steps to investigate, remediate, and harden their environments. Wiz Defend customers benefit from agentless scanning of Artifactory logs. Wiz Research will continue to update our advisory and this blogpost as the situation develops.

If you suspect a JFrog Artifactory breach or any other cloud security incident, contact Wiz CIRT for incident response support.

Indicators of Compromise (IOCs)