JFrog's July fixed version is inside August's affected range

On 27 July 2026, JFrog published an advisory for CVE-2026-42016, a privilege escalation in self-hosted Artifactory. The affected range was one line — < 7.133.11 — and the fix guidance was one number: upgrade to 7.133.11. On 11 September, CISA added it and CVE-2026-42018 to the Known Exploited Vulnerabilities catalog, due 25 September, after Wiz reported attackers chaining the two against self-hosted instances between 15 August and 8 September.

What happened to 7.133.11 in between is the part nobody put in a table.

Three advisories, 32 days, one release branch

Quoted from JFrog's security advisories page as it read on 13 September:

A team that read the July advisory the day it shipped, cut a change, and upgraded to 7.133.11 did exactly what the vendor asked. Sixteen days later that build was enumerated inside the affected range of the next advisory. Sixteen days after that, the build the August advisory named as the fix — 7.133.28 — was inside the affected range of a Critical. The 7.133 branch needed three separate upgrades in 32 days, and each one was correct on the day it was applied.

The structural reason is branch-stream versioning. Artifactory ships six concurrent release branches, and a build on one is not comparable to a build on another. < 7.133.11 is not a number line you can place 7.146.5 on, so a reader on 7.146 could not tell from the July advisory whether it applied at all. The August advisories enumerated five and six per-branch rows; July gave a single blanket string. Two advisories JFrog published on 12 August named 7.146.8 and 7.146.35 as the 7.146-branch fix for different bugs.

It is the same reading failure as a precondition that turns on a build number rather than a product name: the version string is the whole claim, and reading it approximately gives a wrong answer that feels right.

Unauthenticated to admin in three requests

In JFrog's own wording, CVE-2026-42018 means Artifactory "could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled" (CWE-287), and CVE-2026-42016 is a privilege escalation "due to a validation check of the token signature/issuer and not the token's scope" (CWE-863). Both are rated High. Separately neither is dramatic; composed, they are unauthenticated to administrator.

Wiz's reported sequence, the thing to grep for:

POST /access/api/v1/aws/token/    200   anonymous JWT            (CVE-2026-42018)
POST /access/api/v1/tokens        200   admin-scoped token       (CVE-2026-42016)
PUT  /api/security/users/<user>   201   persistent admin account

Wiz reports attackers moving from the first request to a created admin account in under five minutes, then installing Groovy plugins for code execution and a Rust backdoor for persistence. Those survive an upgrade: the version bump closes the entry and leaves the tenancy — on a host that resolves dependencies, stores release artifacts, and holds the credentials your pipelines authenticate with.

The practice: track the build, not the ticket

A fixed version is a claim with a date attached, not a property your host permanently acquires. The unit you track has to be the build string.

For every self-hosted product shipping parallel release branches, keep a record keyed to the exact build (7.133.11, not "7.133" and not "patched in July"), and on a fixed cadence re-check it against every advisory the vendor has published since you deployed it, not only the one that prompted the upgrade. Monthly, that is about twenty minutes of version tables per product — confirming a vendor fix shipped in the build you installed, extended forward in time instead of backward.

The reading is not the cost; the second maintenance window is. July's upgrade already spent the team's appetite for taking the artifact repository offline, and the argument for doing it again two weeks later — for a High, on a build you just patched — loses. Wiz's telemetry — its own visibility, not a census — still had 59% of instances vulnerable to CVE-2026-42016 six weeks on. Make the decision once instead: a standing monthly window for build infrastructure, so each month's question is "is there anything to apply," not "can we have an outage."

When you can't upgrade, read the workaround section rather than skipping to the version table. JFrog published one for CVE-2026-82329 — an additionalJoinKeys value under shared: security: in system.yaml, generated with openssl rand -hex 16. That is a config change, not a version bump, and it covers the Critical only. For 42016 and 42018 there is no equivalent, so the compensating position is to take the instance off the public internet and alert on any 200 from POST /access/api/v1/aws/token/.

Don't build the cadence on KEV membership. These two CVEs entered the catalog on 11 September — 46 days after the first advisory, 27 days after exploitation began. KEV is a lagging confirmation, not a patch trigger.

What to check this week

• What exact build is each self-hosted Artifactory running? The third number decides — 7.133.28 and 7.133.29 are different answers to CVE-2026-82329.
• Check that build against all three advisories, not the one you remediated. The 7.111, 7.117, 7.125, 7.146 and 7.161 branches each carry their own row.
• Grep the access log for any 200 on POST /access/api/v1/aws/token/, starting with 15 August to 8 September.
• Compare admin account creation dates against 15 August, and installed user plugins against the ones you meant to install. Both survive an upgrade.
• For everything else you patched in July: does your record hold the build string, and has anything been published against it since?

North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of chained testing and version verification described above. northinfosec.com