Actively exploited Artifactory vulnerabilities grant admin access in minutes

What was discovered

Security firm Wiz.io disclosed, on September 28, 2026, three vulnerabilities in self-hosted instances of Artifactory, JFrog's artifact manager used by engineering teams to store packages, container images, and build binaries. The flaws are under active exploitation and allow, when chained, an unauthenticated attacker to become an administrator of the instance.

They are: CVE-2026-42018 (high severity), which causes Artifactory to return an internal anonymous user token even with anonymous access disabled; CVE-2026-42016 (high severity), a token scope validation flaw that lets a low-privilege attacker escalate to elevated privileges; and CVE-2026-82329 (critical severity), which lets an unauthenticated attacker gain administrative control directly, without needing any prior step.

According to Wiz, in some observed cases the attacker completed the entire escalation, from the first request to persistent administrative access, in under five minutes.

How the exploit chain works

The attack pattern reported by Wiz always follows the same form. An unauthenticated POST /access/api/v1/aws/token/, with a trailing slash at the end of the URL, returns HTTP 200 with a JWT for the internal anonymous user, exploiting CVE-2026-42018. The attacker then exchanges that JWT for a token with admin scope via POST /access/api/v1/tokens, which also responds HTTP 200, exploiting the scope validation flaw in CVE-2026-42016.

The resulting token keeps the anonymous username but carries administrator authority. This means that, in the logs, actions appear under the token:anonymous actor, which makes detection harder for anyone monitoring only named accounts. Separately, CVE-2026-82329 allows obtaining an admin-scoped token directly, without going through the chain of the other two.

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.

Wiz.io, the security firm that discovered the vulnerabilities

What attackers do after becoming admin

With administrative control, Wiz observed attackers carrying out a consistent set of post-exploitation actions:

• Creating persistent administrator accounts that survive even after the original flaw is patched
• Deploying malicious Groovy plugins, a legitimate Artifactory feature for executing arbitrary code on the server
• Harvesting credentials and the signing keys (Access signing keys) used to validate tokens
• Installing backdoors to maintain future access
• Anti-forensic measures to hinder incident investigation

It is this combination, full control of the artifact repository plus the ability to run code on the server, that makes the case especially sensitive for anyone who relies on Artifactory as part of the build and deploy pipeline.

Artifactory sits at the center of a LOT of software supply chains. This is exactly the kind of bug that turns into next year's SolarWinds story if it's not patched fast.

Erik York, cybersecurity expert, in a LinkedIn post

Who is exposed

The three vulnerabilities specifically affect self-hosted Artifactory deployments accessible over the internet. Wiz does not address, in the disclosed material, JFrog's cloud-managed service, and the report's focus is on instances that the infrastructure team itself hosts and exposes.

In practice, this covers a common scenario among Brazilian companies that run Artifactory on-premise or in their own VPC due to compliance requirements, cost, or integration with internal CI/CD pipelines. If the instance is publicly accessible, even through just a specific port, it is a candidate for automated scanning by anyone who has already mapped the exploitation pattern.

What to do today

The fix requires upgrading to a patched version of Artifactory. The minimum versions per release branch, according to the disclosed material, are:

Beyond upgrading, the step many teams skip is hunting for post-exploitation artifacts in instances that were exposed while vulnerable: admin accounts created outside the normal process, Groovy plugins not versioned in the configuration repository, and signing keys that need to be rotated if there was any suspicion of exfiltration. Upgrading the version does not undo a compromise that has already happened.

What remains unclear

The speed of exploitation is the data point that most worries those following the case closely. Jim Nitterauer, senior director of information security at Graylog, called attention to the slow adoption of patches in the face of a risk that was already being exploited:

Because Artifactory sits at the heart of software build pipelines, a compromise is a direct supply-chain risk and patch adoption has lagged badly, with attacks observed within four days of disclosure of the third bug.

Jim Nitterauer, senior director of information security at Graylog

What remains unclear, based on the material disclosed so far, is the total number of instances already compromised, nor the identity of the groups behind the observed exploitations. For anyone administering Artifactory in production, the practical lesson doesn't depend on these answers: an instance exposed to the internet without a patch is, today, an active risk, not a hypothetical one.