The Empty String Was the Key: Why Patching Artifactory Doesn't Evict Anyone

Every vulnerable JFrog Artifactory instance has been logging the evidence against itself, once per restart, at WARN level, for as long as it has been running:

Adding join key with kid: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

That hex string is the SHA-256 hash of the empty string. Anyone who has ever typed echo -n "" | sha256sum recognises it on sight. Its presence in your Access startup log is not a warning about a possible problem. It is a receipt confirming that your authentication service registered a cluster join key that any stranger on the internet could reconstruct in about two seconds of arithmetic.

That is CVE-2026-82329. JFrog patched it on 28 August 2026. CISA added it to the Known Exploited Vulnerabilities catalog on 2 September with a federal due date of 5 September, three days later. By the time most teams read the advisory, watchTowr's honeypot network had already caught attackers using it in the wild.

I have spent enough time in post-incident calls to know how this one goes. Somebody pulls up the version string, confirms 7.111.21 or later, and marks the ticket resolved. That is the wrong call, and the reason why is buried in one method signature.

Two lines of Java, and a secret that was never there

Bishop Fox published the full reproduction on 11 September, and the root cause is almost embarrassing in its simplicity.

On a default self-managed install, the additional-join-keys setting is unset. The lookup in JoinKeyAccess.java returns an empty string rather than signalling absence. Three separate guards then fail to catch it. The emptiness check runs against the result wrapper, so it tests whether the lookup succeeded rather than whether the string has content. Splitting "" on a comma yields one element, so the registration loop runs. And JoinKeyHashPair validates that the key is well-formed hex rather than that it exists, and an empty string is perfectly valid hex.

So the empty string gets registered as a live join key. Both halves of it are computable offline: the key id is that SHA-256 hash above, and the signing secret is the hex decode of nothing, PKCS7-padded to 32 bytes, which gives you 32 bytes of 0x20. Sign an HS256 JWT with that, POST it as text/plain to /access/api/v1/registry/join on port 8082, and a vulnerable instance answers HTTP 201 with a token.

Bishop Fox's writeup put the lesson in one line that deserves to be printed and taped to a wall: check that a secret exists, not just that it is well formed.

The claim nobody is talking about

Here is the part that changes the incident response math, and I have not seen a single vendor advisory lead with it.

The token that comes back is built with .scope("admin").expiresIn(0). It carries "scp":"admin" and it carries no exp claim at all. Not a long expiry. No expiry. One unauthenticated HTTP request produces a permanent Access administrator credential, and a second call widens the audience from Access to *@*, which reaches Artifactory itself.

Patching the binary does not touch that token. JFrog treats Access tokens as standalone credentials with their own lifecycle and their own revocation path. Upgrade to 7.161.20 and the forging route closes. The credential forged last Tuesday still authenticates on Monday.

This is the same structural failure we wrote about when CVE-2026-55040 let attackers mint a SharePoint admin without a login event. When the artifact of an exploit is a valid credential rather than a dropped file, your remediation clock and your eviction clock are different clocks, and almost every patch process only runs the first one.

It was never one bug

The single-CVE framing collapsed entirely on 11 September, when Wiz published telemetry from a campaign that had been running since mid-August.

Wiz Research observed multiple distinct actors chaining CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory between 15 August and 8 September 2026, twenty-four days of activity. Neither flaw is admin on its own. CVE-2026-42018 returns a JWT for the internal anonymous user to an unauthenticated caller, and it works even when anonymous access is explicitly disabled: an unauthenticated POST to /access/api/v1/aws/token/ with a trailing slash returns HTTP 200 and a token. CVE-2026-42016 is insufficient token validation, where Artifactory checks the signature and issuer but does not properly enforce the token's intended scope. Chain them and a low-privileged token becomes an admin one.

Three separate, independently discovered paths to the same outcome in the same product in six weeks. That is not bad luck. That is a token validation layer that was never designed to be adversarial input.

The exposure numbers Wiz published are the ones I would put in front of a board. Between 49% and 62% of reachable Artifactory instances were vulnerable to at least one of the three flaws. When CVE-2026-42016 was published on 27 July, 67% of organisations running Artifactory had at least one vulnerable instance. For CVE-2026-42018, 69% were vulnerable at publication on 12 August, and four weeks later that had only fallen to 62%. JFrog shipped the 7.133 branch fix for CVE-2026-42018 on 12 August, three days before Wiz saw the first chain exploitation. The patch existed. Nobody applied it.

What the actors did next reads like a checklist written by somebody who understood exactly what an artifact repository is worth:

• Created admin accounts, in some cases less than five minutes from first request
• Issued themselves long-lived access tokens
• Installed malicious Groovy plugins for arbitrary command execution
• Uploaded webshells and staged payloads in /dev/shm, /tmp and /var/tmp
• Dropped a custom Rust backdoor with command and control
• Stole Artifactory configuration data and cluster join keys
• Enumerated repositories, tokens and users
• Added SSH keys to the accounts they had just created

Look at item six again. They stole the join keys. Rotating the empty one is necessary and nowhere near sufficient, because the replacement you configured may already be in somebody's notes.

Why CISA attached forensic triage to this one

BOD 26-04, issued on 10 June 2026, replaced the old BOD 22-01 patch-by-deadline model with a four-variable risk model covering public exposure, KEV status, automatability and technical impact. Sixteen combinations, sixteen timelines. Three of those combinations carry something no previous directive ever required: mandatory forensic triage of the affected asset, alongside the three-day remediation window.

Artifactory hit all of them. Internet-reachable, on the KEV, fully automatable, total system control.

CISA's stated reason for the rewrite is worth quoting plainly: AI is compressing the window between disclosure and weaponisation, while remediation performance is going backwards. The 2026 Verizon DBIR found only 26% of KEV vulnerabilities were fully remediated in 2025, down from 38% the year before. We covered the automation half of that argument when the Zerofot scanner harvested 2,975 working keys in 48 days with no human in the loop.

The implementation guidance suggests scoping within two hours of the KEV addition and collecting volatile evidence within 24 hours, before patching. Read that ordering carefully. CISA is telling federal agencies that if you patch first, you have destroyed evidence you were obligated to collect. Private sector teams are not bound by the directive, but the reasoning applies to every one of us.

An honest note on the telemetry

I want to flag something, because the reporting on this has been uneven. As of the first week of exploitation, neither GreyNoise nor Shadowserver had published corroborating scan telemetry, and there was no public count of internet-exposed Artifactory instances. The early in-the-wild reporting traced back to watchTowr alone, and watchTowr's own characterisation was measured: a small number of source IPs, no evidence of mass scanning at that point. Wiz's data, published ten days later, filled in a much larger picture.

If you are briefing leadership, the defensible numbers are Wiz's vulnerability percentages and the 15 August to 8 September window. The scale of successful compromise is still unknown, and anyone telling you otherwise is guessing.

The only noisy step

Strip the campaign down and there is exactly one phase that generates behaviour a defender can distinguish from normal operations.

The token forge is legitimate protocol traffic. The admin account creation is an admin doing an admin thing. The Groovy plugin install is a supported feature. The artifact pulls afterwards are indistinguishable from a build agent. None of it involves a stolen password, a failed login, or a malware signature to match.

The enumeration is the tell. Every one of those actors walked the repository list, the token list and the user list, because an attacker who has just arrived with a forged credential does not know what it unlocks. They have to look. That reconnaissance is the only moment where intent leaks, and it is precisely the moment where a decoy pays for itself.

Put credentials in your Artifactory that no build job will ever request. A remote repository configured with upstream registry credentials that point nowhere real. A repository named something a human would go straight for, infra-secrets-mirror or prod-deploy-keys, containing artifacts nobody has a reason to pull. A service account in the user list with a name that begs to be targeted. Honeytokens like these have one property that matters here: legitimate traffic never touches them, so a single touch is a confirmed intrusion rather than an alert to triage. Zero false positives is not a marketing claim in this context, it is arithmetic. Nothing in your CI graph references the decoy, so nothing but an unauthorised enumerator can find it.

The same logic extends to the port itself. Port 8082 is the Access router, and it is the port the join endpoint lives behind. A decoy service listening on the ports your real infrastructure uses turns internet-wide scanning for vulnerable Artifactory into a named source IP in your SIEM before anyone reaches a real instance. When we looked at the fifteen days attackers spent inside JetBrains' own CI pipeline, the same gap was in play: build infrastructure is trusted by everything downstream and monitored like a utility closet.

What to actually do this week

Version check first, then assume nothing.

1. Grep your Access startup logs for kid: e3b0c442. Every occurrence dates a window in which your instance was forgeable. That is your exposure timeline, and you will not get a better one.
2. Hunt for HTTP 201 responses from /access/api/v1/registry/join originating from nodes you do not recognise.
3. Enumerate every admin-scoped token with no exp claim. These should not exist in a healthy deployment. Revoke them individually. Patching will not.
4. Rotate in this order: the cluster join key, all Access tokens, then LDAP, proxy and mail credentials, then upstream registry credentials stored on remote repositories. That last category is the one teams forget, and it is the one that reaches other people's infrastructure.
5. Audit admin accounts and their SSH keys, plus any Groovy plugins added since 15 August.
6. Know the cache window. After you revoke an account, Artifactory still honours its basic-auth login for a period. Revocation is not instantaneous eviction, and your verification step has to account for that.

The reason an artifact repository compromise deserves this much care is the blast radius, and it does not stop at your perimeter. An Artifactory admin can alter binaries that downstream consumers already trust and pull automatically. That is the exact mechanism behind the poisoned Axios package that reached a hundred million downloads. The difference is that a public registry compromise gets a CVE, a coordinated disclosure and a news cycle, while a private registry compromise gets a quiet quarter of poisoned internal builds that nobody thinks to question.

Your patch is done. Your eviction probably is not, and the fastest way to find out whether someone is still walking your repositories is to leave them something worth walking toward. If you want to see what that looks like inside a real artifact pipeline, book a walkthrough with our team and we will map the decoys to your actual repository layout.