JFrog Artifactory: 4 CISA KEV CVEs in 16 Days — Fixed in 7.133.11 and 7.146.8

Between August 27 and September 11, 2026, CISA added four JFrog Artifactory vulnerabilities to its Known Exploited Vulnerabilities catalog. Four CVEs on one product in sixteen days, all with observed exploitation.

Known fixed versions: 7.133.11 for CVE-2026-42016, and 7.111.20 / 7.117.27 / 7.125.19 / 7.133.28 / 7.146.8 by branch for CVE-2026-42018.

None of these scores reaches 9.0. That's precisely why this article exists: the severity here doesn't come from the score, it comes from what Artifactory is — the repository feeding your build pipelines.

Three Authentication Failures Out of Four

The common thread is worth calling out. Of the four CVEs, three concern authentication or authorization. Not memory corruption, not injection: identity checks that don't do what they should.

CVE-2026-42016 — validating the signature, not the scope

The most instructive of the batch:

JFrog Artifactory (Self Hosted) versions before 7.133.11 are vulnerable to a privilege escalation attack due to a validation check of the token signature/issuer and not the token's scope.

The token is correctly verified — valid signature, legitimate issuer. What isn't verified is what that token is allowed to do.

This is the classic token mistake: conflating authentication (who are you?) with authorization (are you allowed?). A read-only token issued for one repository is authentically signed; if the check stops there, it opens everything.

The defect is particularly insidious in code review because the verification is present and works. It simply answers the wrong question.

CVSS 8.1, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. The PR:L is misleading in this context: any developer, any CI pipeline holds a token.

CVE-2026-42018 — an anonymous token handed out when anonymous is disabled

JFrog Artifactory could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled, potentially exposing sensitive resources.

The wording contains its own contradiction: anonymous access is disabled, and yet the unauthenticated caller receives an internal anonymous-user token.

In other words, the hardening the administrator explicitly applied doesn't hold. An organisation that disabled anonymous access — that is, an attentive organisation — believes it's protected when it isn't.

CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: no privileges required, confidentiality impact only.

CVE-2026-82329 — administrative privileges in default configuration

JFrog Artifactory contains an improper authentication vulnerability that under default configuration can allow an unauthenticated attacker with network access to obtain administrative privileges.

NVD has published neither score nor versions. But "default configuration" and "administrative privileges without authentication" are enough to place the severity: it's the most serious of the four, and the one we have the least detail on.

CVE-2026-66384 — writing outside the intended path

JFrog Artifactory contains an improper limitation of a pathname to a restricted directory vulnerability. This can allow an authenticated user to write data outside the intended Docker cache path under specific remote-repository conditions.

A path traversal limited to the Docker cache, requiring an account and particular conditions. The least severe in isolation — but an arbitrary write into an artifact repository is a means of substituting content.

Why Artifactory Is a Supply Chain Problem

Artifactory is the central artifact repository: container images, npm packages, Maven JARs, Python modules, internal binaries. It's what every build pipeline in the organisation consumes.

That creates an unusual asymmetry between effort and impact.

Substituting an artifact requires no persistence. An attacker doesn't need to stay: they replace a base image or a library version, and wait. The next build pulls it, signs it if there's downstream signing, and deploys it to production. The compromise travels on its own, through the legitimate distribution mechanism.

The content is implicitly trusted. Nobody verifies the integrity of a dependency coming from the internal repository — that's precisely why the internal repository exists.

Artifactory holds credentials. The remote repositories it caches are configured with tokens to upstream registries: Docker Hub, npm, private cloud registries. Administrative access exposes them.

CI tokens converge there. Every pipeline authenticates to Artifactory; the platform sees the identity of the entire production chain pass through.

It's the same reasoning as for the GitLab CVE published today: on developer tooling, a flaw rated moderate on the generic scale is a severe flaw in practice, because what the system holds is worth more than the system itself.

Versions

In practice, moving to the latest release on your branch covers the set. I can't give you a number for the last two and won't invent one.

⚠️ CVE-2026-42016 is explicitly limited to Self Hosted installations.

Check your version:

curl -s http://artifactory.example.com/artifactory/api/system/version | jq .

# Container
docker exec <container> cat /opt/jfrog/artifactory/app/artifactory.version 2>/dev/null

Detection

Tokens and access

This is where three of the four CVEs show:

• Access tokens created with no corresponding request: Administration → User Management → Access Tokens
• Unknown administrator users
• Successful unauthenticated API requests in the access logs
• Token use from an address or time inconsistent with the pipeline it belongs to

# Artifactory request log
grep -iE "anonymous|token" $ARTIFACTORY_HOME/var/log/artifactory-request.log | tail -100

Artifact integrity

The decisive check, and the only one that detects the scenario that actually matters:

• Artifacts republished under an existing version — an immutable tag that changes is an unambiguous signal
• Changed checksums on already-published versions
• Base images whose creation date doesn't match their history

# Recently modified artifacts via the search API
curl -s -u user:token \
  "http://artifactory.example.com/artifactory/api/search/creation?from=<timestamp>" | jq .

Remote repository configuration

Verify that upstream URLs and configured credentials haven't been altered: redirecting a remote repository to an attacker-controlled registry is a quiet way to poison builds without touching already-stored artifacts.

Mitigation

1. Update to the latest release on your branch

Four KEV CVEs in sixteen days on one product justify an out-of-cycle intervention.

2. Remove internet exposure

Artifactory has no reason to be publicly reachable. If it is, for partners or external runners, put it behind a VPN or restrict by address range. Since CVE-2026-82329 is exploitable unauthenticated in default configuration, this is the highest-value immediate measure.

3. Audit token scope

CVE-2026-42016 exploits the fact that scope wasn't checked. The defensive corollary holds regardless of the patch: minimally scoped, time-limited tokens. A permanent CI token valid across every repository turns any leak into total compromise.

4. Artifact signing and verification

This is the structural measure. If your builds verify signatures on consumed artifacts, substitution in the repository is no longer enough — that's what turns an Artifactory compromise into a contained incident.

5. If you conclude there was a compromise

1. Revoke every access token, without exception — including pipeline tokens, which will need regenerating
2. Rotate credentials to the upstream registries configured in remote repositories
3. Audit artifacts published or modified over the relevant window, base images and heavily-consumed internal libraries first
4. Verify builds produced during the window: that's the real scope of the incident, not the server
5. Notify downstream teams — if an artifact could have been substituted, whatever was deployed with it is suspect

Why Continuous Monitoring of Developer Tooling Matters

Artifactory, GitLab, Jenkins, container registries: this category almost always escapes vulnerability inventories. It's managed by development teams, updated on its own cycles, and absent from IT-driven estate scans. Yet it's the category where a 7.5-rated CVE produces impact the score doesn't describe — because the value isn't in the server, it's in what the server distributes.

With cveo.tech, inventory your development and CI tooling with exact versions, and get automatic alerts whenever a critical CVE affects one.