CISA added three JFrog Artifactory vulnerabilities to its Known Exploited Vulnerabilities catalog in September 2026. CVE-2026-82329 went in on 2 September with a due date of 5 September. CVE-2026-42016 and CVE-2026-42018 followed on 11 September, both due 25 September.
All three are authentication or authorization bugs in self-hosted Artifactory. The worst one, CVE-2026-82329, lets an unauthenticated attacker with network access obtain administrative privileges under the default configuration. JFrog rates it Critical. If your build system pulls from Artifactory, an admin compromise there is a compromise of what you ship.
What's affected
JFrog says its cloud environments were already fortified and need no action. Self-hosted instances need to upgrade.
CVE-2026-82329 (Critical, CWE-287, published 28 August 2026). JFrog lists these affected ranges and patched builds:
| Branch | Affected | Patched |
|---|---|---|
| 7.161 | 7.161.0 to 7.161.19 | 7.161.20 |
| 7.146 | 7.146.0 to 7.146.36 | 7.146.38 |
| 7.133 | 7.133.0 to 7.133.28 | 7.133.29 |
| 7.125 | 7.125.0 to 7.125.19 | 7.125.20 |
| 7.117 | 7.117.0 to 7.117.27 | 7.117.28 |
| 7.111 | from 7.111.4 | 7.111.21 |
CVE-2026-42016 (High, CWE-863, published 27 July 2026). Artifactory checked a token's signature and issuer but not its scope, which allows privilege escalation. JFrog lists all self-hosted versions before 7.133.11 as affected, with 7.133.11 as the patched version.
CVE-2026-42018 (High, CWE-287, published 12 August 2026). Artifactory could hand an internal anonymous user token to an unauthenticated caller even when anonymous access is disabled. JFrog's fixed builds are 7.111.20, 7.117.27, 7.125.19, 7.133.28 and 7.146.8.
Read those together and one thing stands out. CVE-2026-42016 is only listed as fixed from 7.133.11. If you run the 7.111, 7.117 or 7.125 branch, patching for CVE-2026-82329 on your branch does not clear CVE-2026-42016 according to JFrog's table. The cleanest target is 7.133.29, 7.146.38 or 7.161.20, which sit at or above every fixed build listed for all three CVEs.
There was a fourth Artifactory entry just before this window: CVE-2026-66384, a path traversal that lets an authenticated user write outside the Docker cache path, added to KEV on 27 August with a 10 September due date. It is fixed in 7.146.35 and 7.161.16.
How to check if you're exposed
Get the exact version from the REST API:
curl -s -u "$ART_USER:$ART_TOKEN" \
https://artifactory.example.com/artifactory/api/system/version | jq -r .version
Then check whether you applied JFrog's interim workaround for CVE-2026-82329. It adds an extra join key so that only your own keys are accepted for service registration:
grep -n "additionalJoinKeys" "$JFROG_HOME/artifactory/var/etc/system.yaml"
env | grep JF_SHARED_SECURITY_ADDITIONALJOINKEYS
JFrog has not published indicators of compromise for these CVEs. Your hunting has to start from what an attacker with admin would do:
- Admin users, groups or permission targets created since late August that nobody can account for.
- Access tokens with admin scope or long expiry minted from unfamiliar IPs.
- Changes to remote repository URLs, especially for npm, PyPI, Maven or Docker remotes. Pointing a remote at an attacker server is a quiet way to poison builds.
- Artifacts in local repositories overwritten or redeployed with new checksums but the same version string.
What to do now
- Upgrade self-hosted Artifactory to 7.161.20 or 7.146.38. Those builds are at or above every fixed version JFrog lists for all four KEV entries, including CVE-2026-66384, which is listed as affecting everything before 7.146.35. 7.133.29 clears the three September entries but not CVE-2026-66384.
- If you can't upgrade quickly, apply JFrog's CVE-2026-82329 workaround. Generate a random value with
openssl rand -hex 16, add it asadditionalJoinKeysundershared.securityinsystem.yaml(or setJF_SHARED_SECURITY_ADDITIONALJOINKEYSin Helm or container deployments), then restart the Access service or the JPD. Your existing join key keeps working. - Take the Artifactory UI and REST API off the open internet. Build agents and developers can reach it through a VPN or private network.
- Rotate admin passwords, API keys and access tokens, and revoke any token you can't attribute.
- For your most important release artifacts, compare checksums in Artifactory against the values your CI recorded at build time. A mismatch is the signal that matters most.
Why it matters
An artifact repository is part of your build, not just storage. Whoever controls it decides which bytes your pipelines download and which bytes your customers install. That makes an unauthenticated admin bug in it a supply chain incident in waiting, even if no one ever touches your source code.
It also shows why a patch table needs reading, not skimming. The fixed build for one CVE on your branch may not fix its neighbors, and the three Artifactory CVEs here have different fixed version lists.
Try it yourself
Export a CycloneDX SBOM from one of your services and look at where each component was resolved from. If everything comes through a single Artifactory remote, write down what would happen if that remote's upstream URL changed tonight. Then check whether anyone would be alerted.
This demo shows how a dependency inventory is built and where each package sits:
Click through it at your own pace, or open it full screen.
Quick check
Does JFrog's cloud service need patching for these CVEs?
No. For each of the three advisories, JFrog states that affected cloud environments have already been fortified and no action is required for cloud instances.
I upgraded the 7.125 branch to 7.125.20. Am I done?
Not according to JFrog's tables. 7.125.20 is the fix for CVE-2026-82329 on that branch, but CVE-2026-42016 is listed as affecting everything before 7.133.11. Move to 7.133.29 or a later branch.
What does the additionalJoinKeys workaround do?
JFrog says it enforces that only your own keys are accepted for service registration. It reduces risk from CVE-2026-82329 until you upgrade, and it does not replace the upgrade.
