deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Attackers chain two patched JFrog Artifactory CVEs to mint admin-scoped tokens

Multiple actors chained two patched CVEs against self-hosted JFrog Artifactory between August 15 and September 8, turning unauthenticated requests into admin tokens that appear in logs as token:anonymous.

Attackers chain two patched JFrog Artifactory CVEs to mint admin-scoped tokens

Self-hosted JFrog Artifactory instances have been under active attack for roughly four weeks, according to Wiz research recounted in an October 4 write-up on dev.to. Between August 15 and September 8, Wiz observed several distinct actors chaining two already-patched vulnerabilities in the artifact registry, converting a single unauthenticated request into an administrator-scoped token. CISA has placed all three CVEs involved on its Known Exploited Vulnerabilities catalog, and two of them carried a federal remediation deadline of September 25.

How the exploit chain works

The chain has three moves, per the Wiz indicators of compromise relayed in the dev.to post. First, an attacker sends a POST request to the AWS token endpoint with a trailing slash appended to the path. The bare path rejects the call with a 401, but the trailing-slash variant returned HTTP 200 along with a JWT for the internal anonymous user, even on instances where anonymous access had been disabled. That flaw is CVE-2026-42018, which NVD scores at 7.5.

Second, the actor presents that JWT to the token-issuing endpoint. Artifactory validates the token's signature and issuer but not its intended scope, so the exchange returns a token carrying administrator privileges. This is CVE-2026-42016, scored 8.1 by the vendor and 8.8 by NVD, a discrepancy the dev.to author noted when cross-checking the records.

Third, the escalated token is used to create a new user via the users API, which answers with a 201 and leaves a persistent admin account in place. Wiz observed cases where the entire sequence, from first request to working admin account, took under five minutes. The report is explicit that neither chained CVE grants admin on its own; only the combination does.

A separate default-configuration bypass

Alongside the chain, the write-up describes a second way in. A POST to the registry join endpoint returned HTTP 200 or 201 with an admin-scoped token in the response body on instances running default configuration. That flaw, CVE-2026-82329, carries the highest severity of the three at 9.8, was added to the KEV catalog on September 2, and was exploited by several actors between September 1 and September 8.

The detail that makes detection hard

The escalated token keeps the anonymous username while carrying admin authority, so every subsequent attacker request shows up in logs under the actor token:anonymous, which looks like ordinary background traffic. In the dev.to author's framing, rather than stealing an identity, the intruder grafts administrator authority onto an account that already exists on every deployment. Most SIEM setups, the author argues, never alert when an anonymous principal performs an admin action, and the attacker inherits that blind spot for free.

What operators should check

Wiz lists fixed versions per release branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20 or later. However, the NVD record for CVE-2026-42016 states that everything below 7.133.11 is affected, a statement that does not obviously reconcile with the per-branch list for the oldest branches. The dev.to author, unable to settle the conflict from public records alone, recommends targeting the newest version an upgrade path allows and consulting JFrog's advisory for the specific branch before closing a ticket.

On detection, the strongest signature is behavioral: a 401 on the bare AWS-token path followed shortly by a 200 on the trailing-slash variant, from the same client. That pattern indicates an operator probing for the vulnerable variant before relying on it. Other indicators worth searching request logs for include token minting by anonymous or low-privilege identities, account creation through the users API, calls to the legacy token endpoint, reads of the system configuration endpoint, and reads or writes to the plugins API. A lone 200 on the join endpoint is not proof of compromise on its own and should be correlated with account creations or configuration reads. The author also cautions that this checklist is derived from published IOCs and version ranges and has not been validated against a live instance.

Why it matters

Artifactory sits in front of a large share of Java and DevOps build pipelines, so an admin token there is more than a server compromise: it is potential control over the artifacts that downstream builds consume, turning a registry intrusion into a supply-chain problem. Two lessons stand out. Individually moderate flaws become severe when chained, which means self-hosted instances that lag behind advisories stay exposed long after patches ship. And authorization cannot be inferred from a principal name: a credential that reads as anonymous while acting as admin defeats any detection logic that trusts logged identity over observed behavior.

  • #jfrog-artifactory
  • #security
  • #vulnerabilities
  • #devops
  • #supply-chain

Related posts