JFrog Artifactory piles up two exploited authentication flaws, and your binary registry is the next link

September 11, 2026. CISA adds two JFrog Artifactory vulnerabilities to the KEV catalog. July 27, 2026. The first, CVE-2026-42016, was published to the NVD at CVSS 8.1. August 12, 2026. The second, CVE-2026-42018, followed at CVSS 7.5. Why it matters: a binary registry like Artifactory is not just a file store — it is the supply-chain node through which every artifact your pipelines build, sign and deploy passes. Compromise it, and you can poison what everyone downloads.

A binary registry is a supply-chain target

Artifactory occupies a singular position in the software lifecycle. It is where teams publish artifacts, where CI/CD pipelines resolve them, and where Docker images, npm, Maven or PyPI packages are proxied and cached. A privilege escalation on this layer does not grant access to one more server: it hands over what developers are about to deploy.

That is exactly what makes the two September 11 flaws more expensive than their scores suggest. They hit access control — the boundary that decides who can read, write or delete an artifact. And both were confirmed exploited in the wild by Wiz, before they ever entered the KEV.

CVE-2026-42016: check the signature, not the scope

The first flaw is an authorization validation defect. According to the NVD description, Artifactory validated a token’s signature and issuer but not its scope. The direct consequence: a token issued for a narrow scope — read-only access to a specific repository, say — could be stretched to gain higher privileges, up to full privilege escalation.

The mechanism is the classic JWT anti-pattern. The signature guarantees the token is authentic, but authenticity is not authorization. A system that checks “this token is signed by us” without checking “this token is allowed to do this” opens the door to every escalation. The fix, shipped in self-hosted Artifactory 7.133.11, restores the scope check at authorization time.

CVE-2026-42018: the anonymous token that leaks when it should not exist

The second flaw is sneakier still. When anonymous access is disabled — the posture most teams adopt on an exposed registry — Artifactory could still return an internal anonymous-user token to an unauthenticated caller. In other words, the server leaked a secret that should never have been issued, potentially exposing sensitive resources.

The risk is twofold. First, a wrongly-issued anonymous token can be replayed to reach artifacts the team believed protected. Second, the leak itself is an indicator of compromise worth monitoring: a caller obtaining an anonymous token while anonymous access is disabled should never happen in a healthy deployment. Seeing that behaviour in the logs is a signal to escalate.

A series, not an accident

The two flaws are not isolated. They join CVE-2026-82329, a CVSS 9.8 authentication bypass fixed on September 3, and CVE-2026-66384, an out-of-cache write in the Docker registry fixed in late August. We covered both episodes here (CVE-2026-82329 and CVE-2026-66384). Read over time, the sequence says Artifactory is under sustained pressure on its authentication surface — which, for a supply-chain product, is the most dangerous profile there is.

Wiz’s work changes the picture. Their write-up, “Artifactory under attack: in-the-wild exploitation of CVE-2026-42016 and CVE-2026-42018”, documents real exploitation, not a proof of concept. When a binary-registry vendor enters the KEV, it is no longer “patch because it is prudent” but “patch because someone is already using it against you”.

Patch, revoke, audit

The minimum fix is one version: 7.133.11 for self-hosted instances. Verify it through the system API rather than trusting the login page:

# Check the self-hosted version actually being served (7.133.11+ is fixed)
curl -s https://artifactory.example.com/artifactory/api/system/version

A version earlier than 7.133.11 is vulnerable to both flaws — not just one. But the patch alone is not enough, because tokens already issued or already stolen keep working after the upgrade. Three actions complete the fix:

• Revoke and reissue tokens. Every access token, especially the broad-scope ones, must be invalidated and regenerated after the upgrade. A token stolen before the patch stays valid after it.
• Audit anonymous access. Confirm that anonymous access is genuinely disabled on every repository, and that no anonymous token appears in the access logs after that disabling.
• Restrict the network surface. A binary registry has no business being reachable from the whole internet. Limit it to your CI/CD ranges and runners, exactly as you would a secret store.

Verdict

Artifactory has become a convergence point that attackers identified before many teams did. If you self-host Artifactory, move to 7.133.11 immediately, then revoke tokens and audit anonymous access — in that order, because a patch without revocation leaves stolen tokens live. If you consume artifacts from an internal registry, treat this alert as a reminder that dependency provenance is a first-class security control: a compromised registry can ship a signed, apparently legitimate artifact carrying a backdoor. If you manage a fleet of registries, add your binary vendor’s KEV flaws to your watchlist alongside your application servers — that is where the next supply-chain compromise will start.

References

• Wiz — “Artifactory under attack: in-the-wild exploitation of CVE-2026-42016 and CVE-2026-42018”
• JFrog — Security Advisories
• NVD — CVE-2026-42016
• NVD — CVE-2026-42018
• CISA — Known Exploited Vulnerabilities Catalog