Threat Intel JFrog Artifactory CISA KEV

The empty join key that mints an Artifactory admin

September 4, 2026·9 min read·Chris Boker, Founder, CVEasy AI
A small attacker box on the left holding a blank credential card, a rust POST arrow through a pad-to-32 gate whose contents fill with a run of empty cells, hitting a NoAuth stamped Access API endpoint slot on a JFrog Access panel in the middle that emits an admin sealed service token card, a green follow-up arrow curving back to a tokens endpoint slot below it that emits a full platform admin token card with a rust ring, and a right side Artifactory hub tower spilling a grid of container image and package cubes down to a row of downstream CI runner tiles, plus a bottom filter band with the pre-patch side letting a blank entry through and the post-patch side catching it in a mint sieve

Auth bypass advisories that land at CVSS 9.8 come in two flavors: an implementation slip in a parser, or a piece of shared secret machinery that turns out not to be shared. Yesterday's JFrog Artifactory bug is the second kind, and the more embarrassing kind. CVE-2026-82329 lets a network adjacent attacker mint themselves a platform admin token on a self hosted Artifactory in default configuration. The shared secret nodes use to trust each other has a fully predictable value when no admin set it, and no code path rejected the blank. watchTowr confirmed exploitation on September 1, three days after JFrog shipped the patch on August 28. CISA KEV listed it September 2, September 5 federal deadline.

Where an Artifactory node's trust comes from

Every Artifactory cluster runs JFrog Access, the identity plane that mints and validates tokens for Artifactory, Xray, Distribution, and each cluster node. Nodes federate through a value the docs call the join key: a shared HMAC secret that lets one server hand another server a signed enrollment JWT and be believed. In a healthy setup an admin generates a fresh join key at cluster time and rotates it on schedule. In many real installs an admin sets it once, leaves the default, or upgrades from a version where the field started empty. That last case is where CVE-2026-82329 lives.

An empty string signs a valid join token

JFrog Access accepts a comma separated list of trusted join keys and splits it on the comma before hashing each entry into the trusted signer set. When the configured value is empty, "".split(",") returns an array containing a single empty string, and the loader passes it forward instead of filtering it out. The signing routine then PKCS7 pads that value to a 32 byte block. Applied to an empty input, PKCS7 to 32 pads the whole block with the pad length byte itself, which for a 32 byte block is 0x20. Any attacker can now forge to a signer entry that matches HMAC SHA256 with a 32 byte key of ASCII spaces, and the community PoC and patch diff repo documents the derivation directly.

What they forge is a join JWT with a short claim set: alg=HS256, kid=SHA256("") (the well known constant e3b0c442…7852b855), a fresh iat inside the 30 second server skew, an arbitrary service_id, and skip_node_registration=true. Access reads the kid to look up which signer entry to check, reads the payload as a request to enroll a virtual service without persisting a node record, and validates the signature because the key is 32 known bytes.

From service token to full platform admin

The endpoint that consumes the forged JWT is POST /access/api/v1/registry/join, served by a handler the Access source calls RegistryNoAuthResource. Routes tagged NoAuth intentionally skip the auth filter, because a joining node has no identity yet. On a valid request the endpoint returns HTTP 201 and a service token: RSA signed, non expiring, scope admin. That is the credential Access uses when its own internal microservices talk to each other, which is why the scope is so wide.

One further call converts that service token into a platform admin token: POST /access/api/v1/tokens with the service token as the bearer, requesting scope applied-permissions/admin. Access grants it, because the requester now presents credentials Access itself just issued. From that seat the attacker sees every repository, every user, every stored credential and PAT, every federated cluster relationship, and every artifact the build pipeline pushes and pulls. watchTowr's Attacker Eye honeypot network watched that enumeration within three days of the fix (HackRead).

The kid gives the game away. Access audit records a token minted through this chain with signer key id e3b0c442…7852b855, the SHA256 of empty. Any join call carrying that kid is exploitation, not a benign node bringing itself up.

What the patch actually changed

JFrog shipped fixed builds on the six supported Artifactory branches: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20. Cloud tenants are already patched. The community diff of the Access repo bump touches 12 classes. The load bearing edit is a single .filter(Strings::isNotBlank) in the join key parser, so an empty entry stops entering the trusted set. Two supporting edits tighten the JoinKeyHashPair constructor against null or blank keys and move two ProjectResource endpoints from SERVICE up to ADMIN, closing a lateral path from an already minted service token into project management. The phantom key was the only crack; the rest is defense in depth. Affected ranges and patched branches are also called out by Qualys ThreatPROTECT.

Why CVSS 9.8 undersells this row

A 9.8 puts CVE-2026-82329 in the top tier of the week but pins it flat next to every other unauth RCE that scores the same, which is exactly where it will get lost. Artifactory is not an edge appliance and this is not a wire level RCE. It is the box that holds and signs the artifacts every build pipeline in the estate pulls. A single admin token on the artifact registry is a supply chain foothold: substitute a signed container image the deploy job pulls at 3 a.m., push a package version that gets promoted through release channels, or read the service accounts the pipeline uses to write into production. A queue sorted by base score treats this row the same as an unauth crash bug on a marketing microsite; a queue that reads reachability and downstream blast radius treats it as the higher value target it is.

How TRIS scores a build supply chain hub

TRIS, the Threat and Risk Intelligence Scoring engine inside CVEasy AI, does not stop at the base score. Four layers decide the ranking against the actual asset.

Layer 1, exploitation status. CVE-2026-82329 sits on CISA KEV as of September 2 with a September 5 federal deadline, watchTowr confirmed hands on token minting on internet reachable instances, and a public PoC covers the full chain. TRIS pushes this layer to its top band.

Layer 2, network exposure. The forged JWT lands on the Access API, so TRIS asks a concrete question: is the Artifactory tenant reachable from outside its trust boundary. An instance published on the public internet or in a shared VPC scores top band ACT (act now). The same build behind an admin only network segment with strict ingress rules scores materially lower.

Layer 3, artifact blast radius. Access does not sit alone. It signs the tokens Xray uses to publish scan results, Distribution uses to hand builds to edge nodes, and every CI runner uses to fetch container images. TRIS looks up what the tenant hosts and who consumes from it. A hub feeding production container image pulls or signed OCI releases sits well above one hosting only npm dev caches.

Layer 4, join key posture. TRIS ships a specific check for this class: is the Access join key non empty and rotated inside a policy window. A patched instance that still carries the pre incident join key is materially safer than an unpatched one, and a rotated key is the honest signal that the credential attackers now understand is no longer trusted.

The same CVE row sorts very differently across an estate. A patched, network segmented Artifactory serving internal QA lands as a routine Attend row, while an unpatched internet reachable Artifactory pushing production container images with an empty join key and a federated relationship into a second cluster is ACT, page the on call.

Patch, rotate, hunt this week

Patch to the correct branch build. Confirm self hosted instances land on 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. Cloud tenants are already patched. Version strings matter because the fix differs per branch, as tracked by SOCRadar.

Rotate every admin token, PAT, and federated join key. The forged service token is non expiring by design, so treat any admin token in Access issued before the patch as untrustworthy and revoke it. Rotate the join key itself so the empty string signer is no longer part of the trusted set even in an offline copy of the config. Rotate PATs held by CI runners, because a platform admin can list and reissue them at will.

Hunt the token trail. Attackers left a signature you can grep for: administrator tokens minted from unauthenticated POST /access/api/v1/registry/join calls, followed by POST /access/api/v1/tokens requests from the same source, with signer kid equal to SHA256 of empty (e3b0c442…7852b855). Then look for admin tokens created by principals with no user identity, and enumerations of users, groups, credentials, and federated endpoints from a single caller in a short window.

Constrain the surface until patched. If a maintenance window pushes patching a day, put a source ACL on the Access API port for the interval so only admin jump hosts and CI runners on trusted network ranges can reach it. That is a bridge and it is not a substitute for the patch.

Non expiring service tokens outlive your patch. The fix stops new forgeries but leaves any token minted beforehand fully valid. A revoke pass on all admin scoped tokens in Access is not optional, and the join key itself needs rotation so the same trusted signer no longer exists in the config.

How CVEasy AI catches this across your build estate

CVEasy AI, the number one local first Continuous Threat Exposure Management platform, ingests the primary sources for events like this (the JFrog advisory, CISA KEV, watchTowr, Qualys, Tenable) and runs them through TRIS against the actual inventory on your own hardware. The queue answers the concrete questions directly: which self hosted Artifactory tenants are on a vulnerable build, which have the Access API reachable from an attacker segment, which have an empty or unrotated join key, and which downstream CI pipelines and container consumers are federated to a compromised tenant. Your inventory, join key posture, and pipeline federation graph never leave your hardware, and the on call team gets a prioritized queue with the KEV clock, token rotation checklist, and downstream blast radius attached to each row.

Sources: SecurityWeek, BleepingComputer, CISA KEV alert (September 2, 2026), watchTowr Attacker Eye, community PoC and patch diff repo, Qualys ThreatPROTECT, The Hacker News, Dark Reading, HackRead, SOCRadar.