JFrog Artifactory privilege escalation, exploited (CVE-2026-42016)

Actively exploited in the wild - CVE-2026-42016 is a high-severity privilege escalation in JFrog Artifactory (self-hosted) versions before 7.133.11 that lets an attacker with low privileges escalate to administrative control because the platform validates a token’s signature and issuer but never checks its scope. Patched in 7.133.11; upgrade immediately.

Overview

JFrog Artifactory is a widely deployed artifact repository manager. Many organizations run it self-hosted as the central store for build artifacts, container images, and release packages, which makes it a high-value target. CVE-2026-42016 lives in the access-token validation path.

When Artifactory checks a request, it verifies two things about the presented token: that the signature is valid, and that the issuer is trusted. It does not verify the token’s scope. Scope is what defines the permissions a token was issued with - which repositories it can read, which it can write, and which administrative APIs it can reach. An attacker who can obtain or mint a token with a valid signature and trusted issuer is therefore not confined to that token’s intended permissions. In practice, the effective privilege level becomes whatever the attacker requests.

CISA has added CVE-2026-42016 to the Known Exploited Vulnerabilities catalog, confirming active exploitation in real environments. The EPSS score is low at roughly 0.3 percent for the next 30 days, meaning broad opportunistic scanning has not been observed. The KEV listing, however, reflects confirmed targeting, so the practical risk to exposed instances is real regardless of the aggregate probability figure.

Impact

An attacker who already holds a low-privilege account or a narrowly scoped token can escalate to full administrative control of the Artifactory instance. From there, the likely consequences are:

• Read and write access to every repository, including internal release artifacts and container images.
• The ability to inject malicious packages into trusted repositories, which can propagate into downstream CI/CD pipelines and production deployments.
• Access to credentials and configuration material that Artifactory stores or brokers, including remote repository credentials for external registries.
• Modification of users, permissions, and authentication settings to establish persistence.

Because Artifactory frequently sits at the center of a software supply chain, a compromise can extend well beyond the instance itself.

Remediation

The fix is straightforward: upgrade self-hosted Artifactory to 7.133.11 or later. JFrog has published the corrected release, and no configuration workaround fully closes the scope-check gap.

If an immediate upgrade is not possible, treat every token and account as suspect and take these interim steps:

1. Restrict network access to the Artifactory UI and API to trusted networks only.
2. Rotate all access tokens and service account credentials, and audit token creation logs for unexpected issuances.
3. Review recent administrative actions and repository write events for unauthorized changes, especially to release artifacts and internal images.
4. Monitor for newly created admin users or permission changes that no operator can account for.

Organizations that find evidence of tampering should treat the incident as a supply chain compromise and review downstream pipeline and registry integrity. Breach reports and follow-up coverage are collected at breach reports and security news.

Security Insight

This class of bug is a recurring pattern: teams build robust cryptographic validation (signature and issuer checks) and then treat that as the end of the authorization problem, forgetting that a valid token still needs its scope enforced. The same gap has appeared in OAuth resource servers and API gateways, where signature validity is mistaken for permission.

What makes this instance notable is that Artifactory is a supply chain control point. A privilege escalation here does not just expose data; it gives an attacker a way to alter the artifacts that other systems trust and install. KEV status confirms someone is already using it. Vendors with this much downstream trust should treat scope enforcement as a first-class invariant, not a secondary check bolted onto token handling.

Further Reading

• All High Vulnerabilities
• Recent Critical Vulnerabilities
• Top Critical CVEs