Wiz has published an account of attackers exploiting three vulnerabilities in JFrog Artifactory between 15 August and 8 September.
Artifactory is a repository manager. It is the internal library from which a company's build systems fetch the packages, containers and binaries they assemble into software. A great many organisations run it, and most of them never think about it.
All three flaws had patches when the attacks took place. That is the story.
Three flaws, two of them chained
The most serious, CVE-2026-82329, was disclosed on 28 August and rated critical. It lets an unauthenticated attacker with network access obtain administrative privileges. According to The Register's account, the product checked that a joining credential was well formed but not that it had actually been set, and on an installation where it had not been, the value was a predictable constant anyone could reproduce.
Exploitation began four days after disclosure.
The other two were older. CVE-2026-42018, disclosed on 12 August, returns internal anonymous-user tokens even when anonymous access has been turned off. CVE-2026-42016, disclosed on 27 July, checks a token's signature but not the scope it was issued for. Wiz says attackers combined them to "turn an unauthenticated request into an admin-scoped token in two steps."
Once inside, attackers created persistent administrator accounts, minted long-lived tokens, stole keys and, in some cases, attached their own SSH keys to accounts they created. Some installed malicious Groovy plugins for code execution and Rust-based backdoors for persistence. Wiz describes several independent actors rather than a single campaign.
The patch curve
Between 67 and 69 percent of organisations had a vulnerable instance when each flaw was disclosed, by Wiz's measure.
The critical one moved fastest: two weeks after its fix, 49 percent were still exposed. The two rated high moved far more slowly. A month after its patch, 62 percent were still vulnerable to CVE-2026-42018. Six weeks after its patch, 59 percent were still vulnerable to CVE-2026-42016.
That is the recurring failure in severity-driven patching. Scores rate each vulnerability alone. Attackers use them together, and two high-rated flaws that combine into full administrative control are, in practice, a critical one that nobody's dashboard ranks as such.
Why a repository is worth the trouble
Mitch Ashley of The Futurum Group put the underlying problem plainly to DevOps.com: patch urgency "still prioritizes internet exposures versus downstream dependence, which is why a repository manager can sit unpatched for weeks while a public web app gets fixed in hours or days."
The downstream dependence is the point. An administrator on a company's artifact repository can do more than read what is stored there. In principle they can change it, and every build that fetches from it afterwards assembles whatever the repository now holds.
This desk has written that everybody audits the package and nobody audits the shelf it sits on, and that installing software means running it. A compromised repository is the shelf, owned by somebody else. Wiz's report does not describe tampering with stored artifacts, and there is no evidence here that any was altered. It describes attackers establishing the level of access at which that becomes possible.
Patching does not undo it
An administrator account created during the window survives the upgrade. So does a plugin or a backdoor.
That is why Wiz's guidance goes beyond moving to version 7.111.21 or later. It advises looking for suspicious POST requests to the endpoint `/access/api/v1/aws/token/` and for user accounts nobody remembers creating. An organisation that patched on 9 September and stopped there has closed the door, not checked who came through it.
What to watch
Whether any organisation reports artifacts altered in a repository compromised this way. Until one does, this remains a story about access. The first confirmed case of a poisoned build traced to a repository manager would make it a story about supply chains, and would change how quickly these products get patched far more than any severity score has.
The three vulnerabilities, their types, severities and disclosure dates of 27 July, 12 August and 28 August 2026; the observed exploitation window of 15 August to 8 September; the chaining of CVE-2026-42018 and CVE-2026-42016; the post-exploitation activity; the percentages of vulnerable organisations; the fixed version 7.111.21; and the indicator involving POST requests to /access/api/v1/aws/token/ are as published by Wiz Research in "Artifactory Under Attack". The start of exploitation four days after the disclosure of CVE-2026-82329 and the account of its root cause in the handling of an unset join key are as reported by The Register and GBHackers on 11 and 12 September. The figure of 62 percent for CVE-2026-42018 and the quotation from Mitch Ashley of The Futurum Group are as reported by DevOps.com on 14 September. The analysis is our own.
Topics technologysecuritysupply chainvulnerabilities
