Artifactory vulnerability chain: patch now, assume breach

If you run self-hosted JFrog Artifactory, the fastest Artifactory vulnerability chain in circulation right now takes two unauthenticated HTTP requests to reach administrative scope. The first returns a token for Artifactory's internal anonymous user; the second exchanges it for an admin-scoped one. All three CVEs involved are on CISA's Known Exploited Vulnerabilities catalogue, and patching is only half the job.

Here are the facts, checked against JFrog's own advisories and NVD rather than secondary coverage.

The chain that makes this an Artifactory vulnerability worth dropping other work for

Wiz, which published the in-the-wild analysis, documented the two-request chain plainly. An unauthenticated POST /access/api/v1/aws/token/ — with the trailing slash — returns HTTP 200 and a JWT for the internal anonymous user. That is CVE-2026-42018 on its own, and by itself it is a disclosure bug. The second request, POST /access/api/v1/tokens, exchanges that JWT for an admin-scoped token, because Artifactory checks the presented token's signature and issuer without enforcing its scope. The escalated token keeps the anonymous username and carries administrative authority.

That last detail is the one that matters for detection. The privileged actions that follow are attributed to an identity your access reviews have probably never flagged, because it is not a person and was never granted anything.

Wiz reports observing the 42018/42016 chain between 15 August and 8 September 2026, and exploitation of CVE-2026-82329 between 1 and 8 September. CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities catalogue on 2 September with a remediation due date of 5 September — a three-day window, which is unusually short. The two chained CVEs followed on 11 September, due 25 September. All three dates have passed.

Which Artifactory version fixes this — and why the published list is only part of the answer

Most coverage prints one set of fixed versions: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 or newer. That list is correct, but it is the fix matrix for CVE-2026-82329 specifically. The other two carry different numbers.

Every version in the 82329 row sits at or above the corresponding 42018 fix, so upgrading to the 82329 matrix closes all three. Print that row on the change ticket and ignore the rest — this is one of the rare cases where the highest number genuinely is the only one you need.

One wrinkle will cost you an afternoon if nobody warns you. NVD records CVE-2026-42016 as affecting Artifactory Self Hosted versions before 7.133.11, expressed as a single range rather than per branch. A scanner matching on that record will keep reporting a correctly patched 7.111.21 or 7.125.20 host as vulnerable, because those version strings sort below 7.133.11. Confirm against the branch you are actually on before you chase it.

JFrog states that Cloud instances have already been patched and no customer action is required there. This is a self-hosted problem, which is exactly the population least likely to have noticed.

What attackers did after they got in

Wiz documented the post-exploitation activity, and it is the kind that survives a patch. Operators created persistent administrator accounts, wrote malicious Groovy plugins into $JFROG_HOME/var/etc/artifactory/plugins/ for code execution, pulled the full instance configuration via GET /api/system/configuration, harvested credentials and Access signing keys, and established command-and-control.

Signing keys are the part that should set the priority. An artifact repository sits at the centre of a build pipeline; anything it signs, downstream systems trust. A stolen Access signing key means minted tokens that look legitimate after every patch has landed and every attacker session has been closed. We have written before about how a package registry supply chain attack propagates through everything that consumes the registry, and the mechanics here are the same.

A compromise-assessment checklist (ours)

The CVE detail above is from JFrog, NVD, CISA and Wiz. This checklist is ours: it is how we would work an exposed instance in the systems we build and maintain, and it assumes the patch is already applied or scheduled for tonight.

1. Establish the exposure window. Your instance was reachable and unpatched from whenever it fell below the fixed version for its branch. Take the earliest observed exploitation date — 15 August 2026 per Wiz — as the practical floor for log review, not the date you first heard about it.
2. Grep access logs for the two endpoints. Look for /access/api/v1/aws/token/ returning 200 to an unauthenticated caller, and for token issuance at /access/api/v1/tokens that you cannot tie to a known workload. A 200 on the first path is the cheapest single indicator you have.
3. Enumerate every admin account and compare against your own record. Not "does this look plausible" — compare against the list your access review produced. Persistent admin accounts were a documented outcome.
4. Diff the plugins directory against your configuration management. Any Groovy file in the plugins path that your deployment did not put there is an incident, not a finding.
5. Rotate Access signing keys and every credential the instance held. This is the step teams skip because it is disruptive. It is also the only one that invalidates what was harvested. Treat repository credentials, cloud keys and CI tokens stored in or reachable from Artifactory as disclosed.
6. Re-verify recently published artifacts. Compare checksums of anything built or signed during the exposure window against sources you control independently of the repository.
7. Assume anti-forensics. Wiz observed backdoors and C2. If your only audit trail lives on the compromised host, it is evidence of nothing. Work from whatever you shipped off-box.

Steps 1 to 4 are a morning. Step 5 is a week and a change advisory board, which is why it needs deciding today rather than after the assessment finishes.

Is my Artifactory vulnerable? The honest test

If it is self-hosted, internet-reachable and below the fixed version for its branch, assume yes and assume it was found. Automated exploitation of KEV-listed, unauthenticated, network-reachable bugs does not wait for a target to be interesting. NVD's own CISA assessment marks CVE-2026-82329 as automatable with total technical impact.

If it is self-hosted and not internet-reachable, patch on the normal cycle this week and run steps 2 to 4. The chain needs network access, and an attacker who already has that has usually done something louder first.

The broader lesson is about where a build repository sits in your threat model. Teams run DevOps and cloud engineering with the repository treated as infrastructure — something that is patched on the platform cadence — when its blast radius is that of a signing authority. The same reasoning applies to the runners and secrets around it, which is why we push clients toward a CI/CD implementation where the repository's credentials are short-lived and the build's trust in it is verifiable.

InfoQ's write-up is a reasonable summary if you need something to forward, though it prints the 82329 fix matrix without distinguishing the three CVEs. If you are deciding what to do first across a queue of open findings this week, our note on vulnerability prioritization covers why KEV membership outranks a raw CVSS score — and all three of these are on the list.

The next decision is not whether to patch. It is whether you are willing to sign off that no signing key left the building, and what evidence you would point at.