Build1 publisher2 min readPublished Updated
Attackers chained two already-patched Artifactory flaws to take admin and plant backdoor plugins
Attackers chained two self-hosted JFrog Artifactory flaws, both patched more than a month before exploitation, to take admin and install backdoor plugins. Either fix breaks the chain, yet on the published tables only release 7.133.28 closes both.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- CVE-2026-42018 hands a signed JWT for Artifactory's internal anonymous user to a caller with no auth header, even after an admin has turned anonymous access off.
- CVE-2026-42016 checked a token's signature and issuer but not its scope, so a low-privilege token could be escalated.
- Once in, attackers created admin accounts, sometimes with their own SSH keys, deployed a malicious plugin to drop a second-stage payload, and exported configuration, tokens and cluster keys.
- CISA added both CVEs to its Known Exploited Vulnerabilities catalog on September 11, 2026, and set a federal remediation deadline of September 25.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Admin can replace cached packages and misuse publishing credentials, so on a compromised instance every downstream Maven, npm, PyPI, Docker or Helm build falls inside the incident's scope.
- constraint Teams on the 7.146 branch cannot use public material to certify an instance as fully patched, because 7.146.8 is documented only for the CVE-2026-42018 fix.
- cost Operators owe a compromise review on top of the upgrade, covering recently created admin accounts, the plugin directory, and token-endpoint and admin activity in access logs.
CVE-2026-42016 cannot be used on its own by an outsider. It needs a token as input, and an unauthenticated attacker normally has none [8]. According to a write-up published on dev.to, CVE-2026-42018 supplies the identity and CVE-2026-42016 escalates it [9]. No password is needed at any step, and the write-up says blocking either half breaks the chain [9].
So the version string decides exposure, and the write-up warns that the two fix tables are easy to misread [11]. CVE-2026-42016 affects self-hosted versions before 7.133.11, and 7.133.11 is its only listed fix [10]. CVE-2026-42018 is fixed branch by branch, in 7.111.20, 7.117.27, 7.125.19, 7.133.28 and 7.146.8 [11].
Read literally, the first three of those releases sit below 7.133.11 and so inside the CVE-2026-42016 range [1]. An instance upgraded to 7.125.19 has closed the anonymous token leak, and with it the chain [9]. On the published tables, it still has the scope bug for anyone who already holds a low-privilege token [1].
The 7.133 branch has the opposite gap. Releases 7.133.11 through 7.133.27 carry the scope fix and still leak the anonymous token [2]. Of the published fix points, 7.133.28 is the only one the tables show closing both flaws [2].
JFrog rates both flaws High, and CISA's catalog entries record the CWE types and the remediation requirement [13]. CISA notes that self-managed releases are the focus. The write-up says the vendor hardened the cloud version [14].
The best detail in the write-up is a detection signal. On the token request, the bare path returns 401, and the same path with a trailing slash or another variant returns 200 [6]. Real clients have no reason to answer a 401 by adding a slash, and the write-up notes that normal clients do not first hit a 401 and then retry with a different path form [6]. A 401 followed by a 200 on a variant of the token path is the pattern to search access logs for [6].
What to watch
- A JFrog statement on whether 7.146.8 includes the CVE-2026-42016 fix would settle whether the 7.146 branch has a release that closes both flaws.
- Reports of tampered packages found in builds downstream of a compromised instance would move the supply-chain exposure from possible to observed.
- Published indicators for the malicious plugin or its second-stage payload would give plugin-directory checks something specific to match.