JFrog Artifactory had never appeared in CISA's Known Exploited Vulnerabilities catalogue. On 27 August 2026 it did. By 11 September it had four entries.
| CVE | CVSS | What it gives an attacker | Added to KEV |
|---|---|---|---|
| CVE-2026-82329 | 9.8 | Unauthenticated network attacker obtains administrative privileges under default configuration | 2 Sep 2026 |
| CVE-2026-42016 | 8.1 | Privilege escalation: the token's signature and issuer are validated, its scope is not | 11 Sep 2026 |
| CVE-2026-42018 | 7.5 | An internal anonymous-user token returned to an unauthenticated caller, with anonymous access disabled | 11 Sep 2026 |
| CVE-2026-66384 | 5.3 | Authenticated write outside the intended Docker cache path | 27 Aug 2026 |
Four vulnerabilities in one product in sixteen days, every one of them confirmed as exploited in the wild. That is not a run of bad luck in a release cycle. It is what happens when attackers decide a class of software is worth their time.
Read the four together
Taken one at a time these look like ordinary authorisation bugs. Taken together they describe a single attacker objective approached from four directions.
CVE-2026-82329 is the blunt one: network access, default configuration, administrative privileges. No credential required.
CVE-2026-42016 is the interesting one. The token's signature and issuer are checked, and its scope is not. That is a specific, recognisable failure: the system proves the token is genuine and then forgets to ask what it is genuine for. A read-scoped token minted for one repository is cryptographically valid everywhere, so validation passes and authorisation never happens. Any token a build pipeline leaks — and pipelines leak tokens constantly, into logs, caches and support bundles — becomes a key to the whole instance.
CVE-2026-42018 supplies the token for free. An unauthenticated caller receives an internal anonymous-user token, and it does so when anonymous access is disabled. The operator took the documented step to lock the instance down, and the vulnerability is that the step did not hold.
CVE-2026-66384 has the lowest score of the four, 5.3, and is the one worth staring at longest. An authenticated user writes data outside the intended Docker cache path. Five-point-three reads like something to schedule for next quarter. What it actually describes is an attacker choosing the contents of a cached container layer — and the machines that consume that cache are every build in the organisation.
Why the registry is the worst host to lose
A build server holds credentials. A registry holds distribution.
Everything downstream of an artifact repository is built to trust it without argument. That is its function: your CI pulls base images from it, your deployments pull releases from it, your developers pull dependencies through it as a proxy to the public ecosystem. None of those consumers verify anything beyond "the registry returned 200". They cannot. Verification against a signature or provenance attestation is a thing organisations opt into, and most have not.
So admin access to a registry converts directly into code execution across the estate, on a delay of one build. The attacker does not need to touch your source control, your CI configuration, or a single developer laptop. They replace what the registry serves, and your own pipeline distributes it, with your own signatures where signing happens after the pull.
It is also the quietest way in. A malicious commit is visible in a diff, reviewed, attributed. A replaced binary layer in a cache is visible to nobody. There is no pull request for a container layer.
The pattern, not the instance
Patch these four and the underlying condition remains, because the condition is not JFrog's.
Developer infrastructure was built on an assumption that stopped being true: that it sits on a trusted internal network, used by trusted employees, behind a perimeter. Registries, CI servers and source hosts were designed as internal tools, then exposed to the internet so that remote developers, cloud runners and SaaS integrations could reach them, and were given the default configurations of internal tools while doing it.
The KEV catalogue reflects the consequence. In the same window as the Artifactory cluster, CISA added CVE-2026-85706, a CVSS 10.0 unauthenticated arbitrary file read in GitLab CE/EE, and in early August CVE-2026-63077, unauthenticated remote code execution in JetBrains TeamCity. Registry, source host, build server: the three points every artifact you ship passes through, all three exploited in the wild within six weeks.
Attackers are not picking these targets because the bugs are exotic. They are picking them because the blast radius per bug is enormous and the defences are thinner than on the production systems these tools deploy to. Your registry probably does not sit behind the WAF your product does. It probably does not have the same alerting. Its access tokens probably do not expire on the same schedule, if they expire at all.
What to do this week
Patching is the floor, and for these four it is urgent: CISA set the remediation deadline for CVE-2026-82329 three days after adding it.
Beyond patching, four things change the outcome of the next one:
Get the registry off the public internet. Most instances are exposed for a handful of identifiable consumers — CI runners, a VPN range, a cloud NAT gateway. An allowlist of those turns an unauthenticated internet-facing bug into an internal-only one.
Scope every token, and make scope the thing you verify. CVE-2026-42016 is a reminder that "the token is valid" and "the token may do this" are different questions. Audit what your own services check. Short lifetimes limit how long a leaked token is a key.
Verify artifacts at the point of consumption, not at the point of publication. Signing on publish proves who built something. Verifying on pull is what makes a swapped artifact fail closed. Sigstore, in-toto attestations and SLSA provenance are the mechanisms; the discipline is refusing to run what does not verify.
Treat the artifact cache as executable content. It is. Anything that can write to it is a code-execution primitive on every consumer, which is why CVE-2026-66384's 5.3 understates it.
The structural fix
The registries, build servers and source hosts in your organisation are production systems that happen to be operated by engineering rather than ops. Inventory them as such. Put them in the same asset register, the same patch SLA, the same exposure review and the same monitoring as the systems they deploy to.
A useful test: if your source host, registry and CI server were compromised tomorrow, how would you find out — and how would you know which artifacts to distrust? If the answer depends on a signature or an attestation you do not currently verify, that is the work, and it is worth more than the next four patches.
How Safeguard helps
Safeguard treats the build path as part of the software supply chain rather than as infrastructure someone else looks after. It inventories the components your artifacts are assembled from, records provenance for what your pipelines produce, and checks artifacts on the way in rather than trusting the registry that served them. Reachability analysis tells you which of the vulnerabilities in your dependencies are actually exercised by your code, so remediation effort lands where exploitation is possible rather than where the scanner was loudest.
None of that patches Artifactory. What it changes is the question you can answer after an incident: not "were we running a vulnerable version", but "did anything we shipped change, and can we prove it".
