12 SEP 2026 — Attackers have been chaining two flaws in self-hosted JFrog Artifactory to mint administrator tokens, and Wiz reports the activity running across multiple environments between 15 August and 8 September. The administrator actions appear in the audit log as token:anonymous rather than under any named account.
In some cases the interval from the first unauthenticated request to a newly created administrator account was under five minutes.
How the two flaws combine
CVE-2026-42018 makes Artifactory hand an internal anonymous-user token to a caller who has not logged in — and it does this even when anonymous access is switched off. That is the first half, and on its own it grants very little.
CVE-2026-42016 supplies the second half. Artifactory's token-creation endpoint will exchange that low-privilege token for one with administrator scope, because it validates a token's signature and its issuer but not what the token is actually permitted to do.
Neither flaw is catastrophic on its own. The first leaks an identity with almost no rights. The second escalates a token that a caller is not supposed to possess. Chained, an unauthenticated request becomes full administrative control of the artifact repository.
The log entry is the problem
An audit trail that records the action but not the actor produces a record which looks complete and is not.
Administrator operations attributed to token:anonymous will sit in the log alongside legitimate entries. A reviewer scanning for a compromised named account — the usual instinct — finds nothing, and the search returns clean. Detection here depends on knowing to look for an identity string most teams have never had reason to notice.
That is worth converting into a query today rather than filing as context. Search the Artifactory access log for administrator-scope actions carrying that identity, across the whole window from mid-August, and treat any hit as an incident rather than an anomaly.
What the attackers did afterwards
Two post-compromise behaviours are reported, and both outlast the patch.
Administrator accounts were created and left in place. Those accounts survive an upgrade, because patching the flaw does not remove the identities created through it, and an organisation that patches without auditing its administrator list has closed the door behind the intruder.
Malicious Groovy plugins were installed through Artifactory's own plugin framework, which grants code execution on the server. That is a documented feature being used as designed. It will not appear as an exploit in any scan; it appears as a plugin.
A custom backdoor written in Rust, with command-and-control capability, was dropped across multiple cases.
Anonymous access was off, and irrelevant
The first flaw defeats the one control most operators would expect to be protected by.
Disabling anonymous access is the standard hardening step for a repository manager, it is widely documented, and a great many teams will have done it and recorded it as done. CVE-2026-42018 returns the internal anonymous-user token regardless. The setting is honoured in every code path except the one that returns the token.
An organisation that treated "anonymous access disabled" as a compensating control here was relying on something the code did not honour, and the audit checklist recording it would have passed. A toggle records an intention; enforcement happens somewhere else entirely.
An artifact repository is the worst target
Artifactory holds the binaries an organisation builds and the dependencies it consumes. Administrative control over it is the ability to alter what ships.
This is worse than reading a server's secrets. An attacker who can publish to the repository can place a modified artifact where every downstream build will collect it. The compromise, signed by the organisation's own pipeline, then propagates to customers through the normal release process.
It is the second time in two days we have written about a maximum-severity flaw in build infrastructure, after GitLab's unauthenticated file read. The recurrence is structural: build systems are reachable from the network, trusted by everything downstream, and typically owned by a platform team rather than a security one.
A third flaw, and the population
CVE-2026-82329 is a separate critical authentication bypass in the same product, which watchTowr observed being exploited earlier this month, also to mint administrator tokens.
Between 49 and 62 per cent of internet-reachable Artifactory instances are reportedly vulnerable to at least one of these flaws. This is an estimate from external scanning, not a census; the wide range reflects the limits of what a scanner can confirm.
Even at the bottom of the range, roughly half of the instances anyone can reach are exposed to at least one flaw that yields administrator scope.
What to do, in order
Patch, then audit the administrator list, then read the log, in that order. Patching alone leaves the accounts, and reading the log first wastes the window in which the instance is still exploitable.
Review installed plugins against a known-good list. Groovy plugins are legitimate, so nothing will flag one as malicious, and the only workable test is whether somebody can account for each one being there.
Then rotate. Any credential the Artifactory server held or could mint should be treated as disclosed, including signing material, because the value of this access is precisely what it lets an attacker publish.
What to watch
Whether a poisoned artifact surfaces. Exploitation ran for at least three weeks with administrative control of repositories, and the point of that access is to modify what downstream consumers pull. Nothing published so far reports a tampered artifact reaching a consumer, which is the finding that would turn this from an intrusion into a supply-chain incident.
View author profile → · Editorial policy
