CVE
CVE-2026-82329, CVE-2026-42018, CVE-2026-42016
CWE
CWE-287, CWE-863
Affected Surface
- Self-hosted JFrog Artifactory on vulnerable release branches, including `7.111.x < 7.111.21`, `7.117.x < 7.117.28`, `7.125.x < 7.125.20`, `7.133.x < 7.133.29`, `7.146.x < 7.146.38`, and `7.161.x < 7.161.20` for `CVE-2026-82329`
- Older self-hosted Artifactory builds still below the earlier fixes for `CVE-2026-42018` (`7.111.20`, `7.117.27`, `7.125.19`, `7.133.28`, `7.146.8`) and `CVE-2026-42016` (`< 7.133.11`)
- Organizations that use Artifactory to proxy or host Maven, npm, PyPI, Docker, Helm, or generic build artifacts for CI/CD and developer workstations
- Teams that trust Artifactory-issued tokens, repository credentials, and package provenance as a boundary between untrusted inputs and internal build systems
The strongest package-security story in the 10 to 13 September window is not a poisoned npm package. It is active exploitation of the system many teams use to move Maven, npm, PyPI, Docker, Helm, and generic artifacts through their own build graph.
Wiz reported that attackers chained CVE-2026-42018 and CVE-2026-42016 against self-hosted JFrog Artifactory between 15 August and 8 September. Fastly separately documented internet-scale exploitation of CVE-2026-82329 within days of disclosure, with the highest traffic on 2 September after a public proof of concept appeared. CISA then added CVE-2026-42016 and CVE-2026-42018 to KEV on 11 September, after CVE-2026-82329 had already been added earlier in the month.
That combination changes the response posture. Once an attacker can mint or escalate Artifactory tokens, they are no longer attacking one application. They are attacking the package hub that your developers, CI runners, and internal deployment pipelines already trust.
Affected branches and fixed versions
JFrog Artifactory uses long-lived release lines, so the only safe comparison is against the fixed build for your branch.
| CVE | What breaks | Affected self-hosted versions | Fixed versions |
|---|---|---|---|
CVE-2026-82329 | unauthenticated admin-token minting through the cluster-join path | 7.111.x < 7.111.21, 7.117.x < 7.117.28, 7.125.x < 7.125.20, 7.133.x < 7.133.29, 7.146.x < 7.146.38, 7.161.x < 7.161.20 | 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 |
CVE-2026-42018 | unauthenticated disclosure of an internal anonymous-user token even when anonymous access is disabled | 0 < 7.111.20, 7.117.0 < 7.117.27, 7.125.0 < 7.125.19, 7.133.0 < 7.133.28, 7.146.0 < 7.146.8 | 7.111.20, 7.117.27, 7.125.19, 7.133.28, 7.146.8 |
CVE-2026-42016 | privilege escalation because token signature and issuer are checked but token scope is not enforced | self-hosted versions before 7.133.11 | 7.133.11 and later per JFrog guidance |
JFrog cloud deployments were patched vendor-side. The immediate risk is with self-hosted Artifactory instances that were reachable before those branch updates landed.
Two real exploitation paths
The current reporting describes two distinct ways to get to administrative control.
Path 1: CVE-2026-82329 turns one unauthenticated request into an admin token
Fastly and Tenable both describe the direct path in compact terms:
blank join key in JFrog Access
-> deterministic kid = SHA256("")
-> forged HS256 JWT
-> POST /access/api/v1/registry/join
-> service-scoped admin access token
-> full admin, non-expiring platform tokenFastly’s write-up shows the core request shape:
POST /access/api/v1/registry/join HTTP/1.1
Host: artifactory.example
Content-Type: application/json
{"token":"<forged HS256 JWT, kid = SHA256(\"\")>", ...}The most useful detection detail is the kid. Legitimate cluster peers sign with a real join key, so they do not present the empty-string hash:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855If you see a join request that returns HTTP 201 with that kid, the question is no longer whether probing happened. The join path has already accepted a forged token.
Path 2: CVE-2026-42018 plus CVE-2026-42016 turns an anonymous token into admin scope
Wiz describes a second chain that matters because it does not depend on the same blank-join-key weakness:
unauthenticated caller
-> receives internal anonymous-user token even though anonymous access is disabled
-> token reaches Artifactory as a low-privilege credential
-> signature and issuer validate
-> scope is not enforced
-> admin-scoped operations become reachableCVE-2026-42018 is the leak. An unauthenticated request can still receive the internal anonymous-user token even after an administrator has disabled anonymous access. CVE-2026-42016 is the escalation step. Artifactory validates that the token was issued by the right authority and carries a valid signature, but the vulnerable code path does not enforce the token’s scope. Wiz’s finding is that those two flaws together can promote an unauthenticated request into administrative control in two steps.
This matters for defenders because it breaks a common assumption about identity systems. A token can be valid and still be dangerous if the receiver treats “properly signed” as a substitute for “authorized for this action.”
Why this is a supply-chain problem, not just an auth bug
Artifactory often sits on the centerline of modern software delivery:
developer or CI job
-> internal Artifactory
-> Maven, npm, PyPI, Docker, Helm, or generic artifact pull
-> build output used by downstream servicesAdministrative access at that layer can lead to much more than metadata leakage. Tenable notes that CVE-2026-82329 can expose server configuration, platform tokens, and hosted artifacts. Wiz reports that real-world operators created persistent administrator accounts, deployed malicious Groovy plugins for code execution, and dropped custom Rust backdoors for persistence.
At that point, the blast radius includes:
- artifact tampering for internal package consumers
- theft of repository credentials and platform tokens
- persistence inside the package repository itself
- downstream compromise of any build job or workstation that trusts the altered artifact flow
That is why this story belongs in the same queue as a registry compromise. The attacker is not forging one package tarball. They are taking control of the service that decides which tarball, wheel, jar, or image your environment gets.
What to hunt right now
Start with the Artifactory access and request logs:
rg -n '/access/api/v1/registry/join|/access/api/v1/registry/join/router' \
var/log . 2>/dev/null
rg -n 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855|jfrt/0/7\\.161\\.19|JFrog-Access/7\\.141\\.17|JFrogArtifactory/7\\.146\\.25' \
var/log . 2>/dev/nullThen review identity and repository state:
- access tokens issued or exchanged since 28 August 2026
- new administrator accounts or privilege changes
- unexpected repository definitions, permission targets, or remote credentials
- anonymous-principal activity on systems where anonymous access was supposed to be disabled
- newly added plugins, extensions, or background processes associated with the Artifactory host
Fastly’s guidance is blunt and correct here: a patch does not revoke tokens that an attacker already minted.
Response guidance
- Upgrade self-hosted Artifactory to the fixed build for your branch.
- If the instance was internet reachable, treat exposure as a possible compromise, not just a patching task.
- Rotate the platform join key and revoke Artifactory access tokens issued since 28 August 2026.
- Review administrator accounts, repository configuration, and hosted artifacts for changes that were not made by your team.
- Restrict Artifactory network reachability to trusted users and build systems while you validate the environment.
The immediate lesson is simple. Package security does not stop at package names and signatures. If the artifact hub itself can be coerced into minting admin tokens, the rest of the supply chain inherits that failure.
From research to remediation
Check whether this pattern exists in your codebase
Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.