Two Flaws, One Chain: How JFrog Artifactory Was Pushed to Admin

Between mid-August and early September 2026, security teams observed attackers chaining two patched vulnerabilities in self-hosted JFrog Artifactory to reach administrator control, then install a backdoor. Both flaws entered CISA's Known Exploited Vulnerabilities catalog on September 11, 2026, with a federal remediation deadline of September 25. The patches had been available for over a month before the observed exploitation.
Artifactory is the artifact repository that most build pipelines depend on. Maven, npm, PyPI, Docker, and Helm artifacts all flow through it. Administrator access to Artifactory means the ability to replace cached packages and misuse publishing credentials, which extends the impact to every build that pulls from it.

The two halves of the chain

CVE-2026-42018 is an improper authentication issue, CWE-287. Its official name is "Anonymous User Token Generation Exposure." When anonymous access is disabled, Artifactory could still return an internal anonymous user token to an unauthenticated caller. The request needs no authentication header. On an affected version, a request to the token endpoint returns a signed JWT belonging to Artifactory's internal anonymous user, even though the administrator explicitly turned anonymous access off.
One detail is worth noting. The disclosed behavior shows that the bare path returns 401, while the path with a trailing slash, or a path variant, returns 200. That difference is a useful detection signal: normal clients do not first hit a 401 and then retry with a different path form.
CVE-2026-42016 is an authorization error, CWE-863. It affects self-hosted versions before 7.133.11. The token validation checked the signature and the issuer but did not properly restrict the token's scope. A low-privilege token could be used to escalate. On its own this flaw is not usable, because it needs an existing token as input, and an unauthenticated attacker normally has none.
The chain works because the first flaw supplies the identity and the second escalates it. No password is needed at any step. Security teams verified that blocking either half breaks the chain.

Affected versions and fixes

The two flaws have different version ranges, which is easy to misread.
CVE-2026-42016 affects versions before 7.133.11. The fix is 7.133.11.
CVE-2026-42018 covers five branches:

• below 7.111.20, fixed in 7.111.20
• 7.117.0 to 7.117.27, fixed in 7.117.27
• 7.125.0 to 7.125.19, fixed in 7.125.19
• 7.133.0 to 7.133.28, fixed in 7.133.28
• 7.146.0 to 7.146.8, fixed in 7.146.8 There is a gap in the published version tables. The advisory for CVE-2026-42016 lists only 7.133.11 as a fix point. If an instance runs on the 7.146 branch, upgrading to 7.146.8 addresses CVE-2026-42018, but the public material does not state whether that release also contains the CVE-2026-42016 fix. Organizations on that branch should confirm with the vendor rather than assume that the latest fixed release on a higher branch covers both flaws. Both flaws are rated High by the vendor. CISA's KEV entries record the CWE types and the remediation requirement but do not publish CVSS scores. CISA notes that self-managed releases are the focus; the cloud version was hardened by the vendor.

What the attackers did after gaining access

The observed sequence has a consistent shape. First, establish persistent identity by creating an administrator account, sometimes attaching an attacker-controlled SSH public key to the new account. Second, install a backdoor by deploying a malicious plugin, which uses the plugin mechanism to execute code and drop a second-stage payload. Third, exfiltrate data: configuration, newly minted tokens, and cluster keys were exported, and repository assets were enumerated.
That third step is what turns a server compromise into a supply chain problem. If an attacker can replace cached packages, downstream builds may consume tampered artifacts. The impact is not limited to the Artifactory server; it extends to everything that pulls from it.

What to check

1. Confirm the running version against the vendor's fix table for the correct branch.
2. List users and look for unfamiliar administrator accounts created recently.
3. Inspect the plugin directory. Malicious plugins are the primary landing mechanism in this attack.
4. Review access logs for token endpoint calls and administrator actions, focusing on unusual source addresses and off-hours activity.
5. Check for anonymous token exposure, particularly requests that first return 401 and then succeed with a path variant. Two operational details matter. Container-deployed instances must be inspected inside the container, and log paths vary by installation method. If an unfamiliar administrator account or a suspicious plugin file is found, disable it and preserve evidence rather than deleting it, so the investigation has material to work with.

Remediation order

1. Reduce exposure. Restrict the management and token endpoints to the internal network, using allowlists and a proxy for any external access.
2. Upgrade to the fixed version for the correct branch, following the vendor's version table rather than a third-party summary.
3. Rotate. Revoke suspect tokens, rotate CI and repository credentials, and replace cluster keys. Administrator passwords and keys both need attention.
4. Audit and rebuild trust. Review administrator change records, artifact replacement records, and unusual bulk downloads. Compare high-value artifact digests against trusted build sources. The last step is the one most often skipped. Patching closes the vulnerability. It does not establish that packages distributed before the patch were clean.

References

• JFrog security advisories for CVE-2026-42016 and CVE-2026-42018.
• CISA Known Exploited Vulnerabilities catalog entries for CVE-2026-42016 and CVE-2026-42018, added September 11, 2026, deadline September 25, 2026.
• NVD records for CVE-2026-42016 (CWE-863) and CVE-2026-42018 (CWE-287).