JFrog Artifactory CVE-2026-82329 Hit CISA’s Exploited List

If your team still runs self-hosted JFrog Artifactory, the September 2 CISA listing is the one that matters for the registry that holds your packages. JFrog Artifactory CVE-2026-82329 is an improper-authentication flaw that, under default configuration, can let an unauthenticated network attacker obtain administrative privileges. Cloud instances were already fortified by JFrog. Self-hosted boxes are not done until someone upgrades them — and then rotates what an attacker may already have minted.

This is not another edge firewall story like SonicWall SMA1000 on CISA’s exploited list, and it is not the telephony leftover we covered for Sangoma Switchvox CVE-2026-9586. Artifactory is the supply-chain shelf: binaries, containers, AI models, and the credentials that sit next to them. When admin lands on that shelf, the blast radius is the build pipeline, not just one workstation.

What JFrog Artifactory CVE-2026-82329 actually is

JFrog’s security advisory (published 28 Aug 2026) describes CVE-2026-82329 as Critical, CWE-287 Improper Authentication: Artifactory “contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.” That is the vendor sentence. Keep it. Do not upgrade it into a claim of remote code execution on the host OS unless a primary source says so for this CVE.

JFrog CTO commentary reported by SecurityWeek draws the same line: improper authentication rather than RCE, and the issue does not affect JFrog SaaS — only self-hosted deployments. Cloud environments “have already been fortified,” per the advisory. Self-hosted operators own the upgrade.

CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities catalog on 2 September 2026 in the same seven-CVE batch that included SonicWall SMA1000 and Sangoma Switchvox. The KEV JSON due date for federal civilian agencies is 5 September 2026, with forensic triage marked Yes under BOD 26-04. That federal clock is already past as of this writing. For a NYC software shop, treat the overdue KEV date as a residual-risk flag: if you were exposed and have not patched and rotated, assume the registry needs more than a version bump.

Patched builds — and why Tuesday’s older patch is not enough

JFrog’s fixed self-hosted builds for CVE-2026-82329, all tied to the 28 Aug 2026 advisory, are:

• 7.111.21
• 7.117.28
• 7.125.20
• 7.133.29
• 7.146.38
• 7.161.20

Match the train you are on. Do not invent a middle build that never shipped. Public write-ups have already flagged a trap on the 7.146 branch: some advisory tables have been read as pointing at a 7.146.37 that does not exist. The advisory’s patched floor for that train is 7.146.38. Likewise, a 25 Aug patch wave that landed builds such as 7.161.19 / 7.146.36 for other CVEs does not clear CVE-2026-82329. If your inventory still shows those earlier August builds, you are not on today’s fixed list.

If you cannot upgrade immediately, JFrog documents a temporary workaround: set a strong random additionalJoinKeys value under shared.security in system.yaml (or the equivalent JF_SHARED_SECURITY_ADDITIONALJOINKEYS env var for container/Helm installs), then restart Access / the JPD. That is a bridge, not the finish line. The advisory’s preferred remediation is still the patched build for your branch.

Exploitation is not theoretical anymore

WatchTowr, as reported by SecurityWeek, said its Attacker Eye honeypot network showed attackers minting administrator tokens and enumerating users, groups, credential sets, and federated access topologies after disclosure. Fastly’s public research on the same CVE describes the weaponization curve after the 28 Aug disclosure: low probe volume for roughly two days, then a sharp climb once a public exploit circulated, peaking around 406,000 observed attempts on 2 September across their platform telemetry — with mass scanning and a smaller tier of more targeted attempts. Those Fastly counts are global CDN/WAF observations, not a claim that Midtown registries were hit, and not a MicroSky customer count.

We are not pasting exploit paths, forged token recipes, or request bodies into this post. Operators need the build numbers, the exposure question, and the post-patch audit — not a cookbook.

Why an artifact registry is different from “just another admin panel”

Admin on Artifactory is supply-chain admin. WatchTowr’s public framing, via SecurityWeek, is the practical one: with admin on a central artifact system, an attacker can do what engineering teams do — build, ship, and distribute — including tampering with pipelines and pushing bad changes downstream. For a 20-person product company in Brooklyn or a fintech shop near Jersey City that still self-hosts Artifactory “because CI is already on that VLAN,” that is the difference between a stolen laptop and a poisoned release.

This sits next to other leftover on-prem patterns we keep writing about — the print Application Server, the edge appliance, the RMM console. Different product. Same habit: the cloud cutover left one high-value box that still answers from places it should not.

Eight things a small engineering org can finish this week

1. Confirm hosting model. JFrog Cloud / SaaS: vendor says already fortified — no customer patch for this CVE. Self-hosted (on-prem, hybrid control plane, “we run the VM”): you own it.
2. Record the exact version from the Artifactory UI or node inventory before you touch anything. Screenshot it. You want proof you were below the fixed build if a customer or insurer asks later.
3. Upgrade to the matching fixed build from JFrog’s advisory list above. Multi-node clusters: check every node. Do not stop at an August 25 build that fixed other CVEs.
4. If upgrade is delayed, apply the additionalJoinKeys workaround from the advisory, restart Access, and schedule the real upgrade. Workaround first is better than open default config on the internet.
5. Shrink who can reach the registry. VPN, allowlists, and no public Artifactory UI “for the contractor” are not substitutes for the patch, but they shrink who gets a free shot while you schedule the window.
6. Assume compromise if you were exposed before the patch. Fastly’s operator guidance is blunt: a patch does not revoke tokens already minted. Rotate the platform join key, revoke access tokens issued since 28 Aug 2026, and audit for unexpected admin users, repositories, and configuration changes.
7. Hunt logs for the join endpoint. Public research points defenders at successful registrations against the cluster-join / registry-join API path as a high-signal lead. Treat unexpected success responses in that window as investigation triggers — not as proof every shop was hit. We are not publishing payload indicators here; use your vendor and WAF guidance.
8. Write down what you checked. Version before/after, who patched, token rotation done or not, and whether any unexpected admins showed up. NYC regulated clients will ask for that paper trail.

What NYC SMBs and product teams should ask this week

You do not need to know JFrog build strings by heart. You need answers in writing:

1. Do we run self-hosted Artifactory or JFrog Cloud?
2. If self-hosted, what exact build are we on — and is it one of 7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20?
3. Was the registry reachable from the public internet between 28 Aug and the patch date?
4. After patching, did anyone rotate join keys and revoke tokens issued since disclosure?
5. Did anyone audit for unexpected admin users, new repositories, or odd federated-access changes?
6. If something looked wrong, what is the customer / downstream notification path?

That list is the practical sibling of the RMM questions we raised after N-central hotfix news and the edge questions after SonicWall and Switchvox hit KEV. Same city, different shelf in the stack.

How this fits the rest of the September patch pile

CISA’s 2 September KEV batch pulled several management-plane and edge issues into the same week. Artifactory is the one that sits inside the software factory. Patch priority should match blast radius: a registry with admin tokens is not “just another CVE on a slide.”

MicroSky’s take for co-managed and fully managed clients is boring on purpose: identify every self-hosted Artifactory, confirm the build, patch to the advisory floor, remove lazy internet exposure, rotate tokens, then audit. No invented “half of Midtown is infected” math. No exploit cookbook. Just the build number and the follow-through.

Need a second set of eyes on that leftover registry?

If you are a NYC or Staten Island business and you are not sure whether your self-hosted JFrog Artifactory is on a fixed build — or whether tokens minted since late August were revoked — call MicroSky at (718) 672-2177 or visit https://microskyms.com. We will help you ask the right version-and-exposure questions and close the gap if the answer is fuzzy.

Sources

• JFrog Security Advisories — CVE-2026-82329 — docs.jfrog.com
• CISA — Adds Seven Known Exploited Vulnerabilities to Catalog (2 Sep 2026) — cisa.gov
• CISA KEV catalog JSON — CVE-2026-82329 (dateAdded 2026-09-02, dueDate 2026-09-05)
• SecurityWeek — Critical JFrog Artifactory Vulnerability Reportedly Exploited in the Wild (Eduard Kovacs; WatchTowr / Landman context)
• Fastly — CVE-2026-82329: JFrog Artifactory Authentication Bypass Exploitation Activity (telemetry and operator recommendations)