CVE-2026-42016JFrog Artifactory checks a token's signature and issuer but not its scope
What broke
JFrog's advisory, published July 27, 2026, says self-hosted Artifactory versions before 7.133.11 are open to "privilege escalation" because of a "validation check of the token signature/issuer and not the token's scope." A token that Artifactory itself had signed was trusted for any action, whatever permissions it was issued with. The CWE is CWE-863 (incorrect authorization). NVD scores it CVSS 3.1 8.8. JFrog Cloud needs no action.
Wiz reported on September 10, 2026 that attackers chained it with CVE-2026-42018, which leaked an internal anonymous-user token to unauthenticated callers. The leaked token had a valid signature and issuer, and this flaw let it act as an administrator. Wiz's detection guidance for this step is the anonymous or a low-privilege identity minting tokens at /access/api/v1/tokens, enumerating users or calling /api/plugins. After access, attackers created admin accounts, installed Groovy plugins and, in one case, read the Access signing key. CISA added it to KEV on September 11, 2026.
Why it matters
Signature and issuer tell a relying party who minted a token. Scope tells it what the token may do. Checking only the first two treats every token from the right issuer as an all-access pass, so the least-privileged credential in the system is as strong as the most privileged one. Artifactory issues tokens to CI jobs, build agents and integrations, many of them service accounts with deliberately narrow rights. This bug erased the difference. Any relying party that validates access tokens should enforce scope or audience on every request, not just at issuance.
What to do
- Upgrade to 7.133.11 or later, and to the fixed build for CVE-2026-42018 on your branch, since the two were used together.
- Restrict network access to Artifactory and review authentication logs for low-privilege identities performing admin actions.
After you patch
- Remove admin accounts and plugins you did not create. Wiz notes patching does not revoke a stolen signing key, so reset the Access token certificate on any instance that may have been compromised.
- Re-issue CI and integration tokens after the reset, scoped to the repositories each one needs.
Sources
Related identity CVEs
Related on Start with Identity
- CVEAD FS elevation of privilege exploited as a zero-day
A low-privileged local user on an AD FS server could become administrator on the box that holds the federation token-signing keys. Microsoft saw exploitation be
- CVEIvanti Connect Secure root escalation, the last link in the UTA0576 chain
The privilege escalation UTA0576 chained with CVE-2026-104935 to reach root on fully patched Ivanti Connect Secure VPNs, then mine Active Directory. Patched Oct
- CVEScreenConnect client runs transferred files without host confirmation
ScreenConnect clients before 26.6.5 could let files be pushed and run through an active session without authorization or host confirmation, including with eleva
- BlogA hijacked AI coding assistant session spread Shai-Hulud to about 100 internal repositories
Mandiant describes an intrusion at an unnamed SaaS provider where a poisoned package, recommended through a developer's AI coding assistant session, led to stol
- BlogCISA adds the last two Ivanti Connect Secure chain flaws to KEV after Ivanti's October 29 patch
CISA added Ivanti Connect Secure CVE-2026-111357 and CVE-2026-118527 to its exploited list on October 30, a day after Ivanti patched the root escalation UTA0576
- BlogCrowdSec kept a departing engineer's GitHub access open, and lost 170 private repositories through it
An engineer's laptop was infected in the May TanStack npm attack. Eleven days later his still-active GitHub OAuth token was used to copy about 170 of CrowdSec's