Artifactory's "medium" CVE hit the catalog before the critical one

On 27 August, CISA added a JFrog Artifactory flaw scored 5.3 out of 10 to its catalog of exploited vulnerabilities. On 2 September it added another one, same product, scored 9.8. The second got the headlines; the first was barely covered. They live in the same box, and the order in which each was confirmed to be in use is the reverse of the order you read the scores in.

The two dates

CISA's KEV catalog lists flaws with evidence of exploitation, not severe flaws. An entry there means somebody is using it against somebody, and it comes with a deadline: for US federal agencies, the one for the 5.3 falls on 10 September. So, the timeline:

• 12 August 2026 — CVE-2026-66384 is published, a path traversal in Artifactory, scored 5.3 (medium).
• 27 August — CISA adds that 5.3 to the KEV, alongside an ownCloud flaw and a Linux kernel one.
• 28 August — JFrog publishes and fixes CVE-2026-82329, scored 9.8: authentication bypass leading to administrative access.
• 1 September — watchTowr detects exploitation against its honeypot network. Four days after the patch.
• 2 September — CISA adds the 9.8 to the KEV, in a batch of seven that includes SonicWall SMA1000, Kestra, LiteLLM and Sangoma Switchvox.

Six days separate one confirmation from the other. If your criterion for queueing patches is the score, the 5.3 is still waiting on some board while the 9.8 got patched over the weekend. And the 5.3 had already been six days on the exploited list when the other one arrived.

The 9.8: the signing key could be computed

CVE-2026-82329 is an improper authentication flaw (CWE-287) with a CVSS of 9.8, and it does not live in the package catalog or the UI: it lives in JFrog Access, the component that issues and validates credentials. According to watchTowr's analysis, installations without an additional join key configured get a "phantom" join key; in the vulnerable versions the empty string is accepted as a valid join key, and the signing key the system derives from an empty join key is entirely predictable. From there, forging an admin token is arithmetic.

The important part of that sentence is what you do not need: no username, no password, no API key, no previously stolen session. Network reach is enough. It affects self-hosted installs; according to JFrog, its SaaS platform is out of scope.

The 5.3: writing outside the Docker cache

The description of CVE-2026-66384 fits on one line: "an authenticated user may write data outside the intended Docker cache path under specific remote-repository conditions". It is CWE-22, classic path traversal, and the fix landed in versions 7.146.35 and 7.161.16. We ran past it writing about the 136-key incident, in the list of what entered the catalog that day; back then it was a line, now it is half the story.

That "remote repository" the description mentions is the caching proxy: the way Artifactory sits in front of Docker Hub or an external registry, pulls the image once and serves it from inside. The advisory scopes the flaw to "specific conditions" and does not say how many installs meet them; that this mode is the usual reason for standing the tool up is our reading, not the vendor's data.

5.3 does not mean "not important". It means "one dimension only"

The full vector of the 5.3 is this: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N. Read piece by piece it says rather more than the number at the end.

And here comes our reading, not the advisories', because we have not seen anyone chain the two and it is worth saying out loud: on a box vulnerable to both, the PR:L of the 5.3 stops being a requirement. The 9.8 hands out admin credentials for free, and "must be authenticated" satisfies itself.

That said, do not inflate it: if you are already an admin via the 9.8, changing a repository's contents is something you can do the normal way, no path traversal needed. What the 5.3 adds is writing outside the intended directory — that is, onto the server's filesystem, as far as the Artifactory process can reach. It is the difference between "I change what is in the repository" and "I write on the machine". Not the same jump, and the second one worries us considerably more.

The version trap

The published affected ranges for the 9.8 are 7.161.0–7.161.19, 7.146.0–7.146.36 (some listings say .37), 7.133.0–7.133.28, 7.125.0–7.125.19, 7.117.0–7.117.27 and 7.111.4–7.111.21, with fixed builds 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20. Crossing that with the other flaw produces two things. First: 7.161.16 to 7.161.19, and 7.146.35 up to the end of the range, are builds patched for the "medium" and exposed to the critical. Anyone who updated in August because of the path traversal and stopped there feels current.

The second is worse, and it is our own reading of the published ranges: the 5.3 only has an announced fix in 7.146.35 and 7.161.16. Anyone on 7.111, 7.117, 7.125 or 7.133 can apply their own branch's fix for the 9.8 — .21, .28, .20, .29 — and still have no patch for the path traversal, because none is announced on those branches. If your policy is "stay on the branch and apply patches", that is where you end up halfway. JFrog may have backports that do not show up in the public summaries; we have not found them, and that is exactly the question we would put to the vendor.

One more note, just in case: the public listings disagree with each other. On 7.111, .21 shows up in some places as the last affected version and in others as the fixed build; on 7.146 some close the range at .36 and some at .37. There is a self-consistent reading in circulation ("before 7.111.21" and "7.146.0 to 7.146.37") that resolves both anomalies, but we have not been able to check it against the original advisory. Check the exact build number against the vendor. "We are on 7.146" does not answer this question.

The mirror you set up so you would not depend on the outside

Nobody installs an artifact repository for fun. You install it for two reasonable reasons: so a build does not fail because Docker Hub is having a bad day, and so you are not at the mercy of someone publishing a poisoned package out there — which is exactly the scenario we wrote about with the 444-package npm incident.

And from there you harden around it: build machines only pull from the internal repository, egress gets trimmed, the external registry comes off the allowlist. Every one of those rules, one by one, points at the same box. It is good architecture, with one uncomfortable consequence: whoever controls that box inherits every one of those rules as a privilege. You are the one who taught your infrastructure to believe whatever comes out of there.

And the substitution does not cross your perimeter in any way an egress filter is going to notice: same domain, your certificate, a host on your own VLAN. If on top of that you deploy by moving tag — and we have already said latest is not a version — the swap does not even leave a different number in sight.

The first thing they looked at was the keyring

Here it is worth being precise about where our information comes from, because it changes the size of the scare: watchTowr describes what attackers did against its own honeypot network, not against identified victims, and the activity came from a handful of addresses, with no mass scanning so far. That said, what they did there is the script: mint admin tokens and, with them, enumerate users, groups, credential sets and federated access relationships — survey the environment to decide whether it was worth going deeper; in a limited number of cases they also created backdoor users. With those permissions you can read artifacts, change security configuration and poison existing packages.

The order says a lot. They started with the keyring, and packages came later. An artifact repository stores the credentials it uses to talk to remote repositories, to your image registry, to your CI and to other federated instances; it is a secret store that also happens to serve files. We saw the same pattern when the continuous integration server turned out to be the one holding the production keys: what makes an internal tool valuable is who it is authorized to talk to.

We deploy with CI/CD on GitLab and containers on Docker Swarm and Kubernetes, so this one catches us inside. The rule we apply is boring: an artifact repository is a production system, not a development tool. It goes in the inventory, it has an owner, it has a maintenance window, and it gets the same conversation about exposure and credentials as a database server. It is the usual data and applications architecture discussion, applied to the piece that normally stays out of the inventory.

What we would look at on a Monday morning

• Is it reachable from the internet? Self-hosted and published outwards is the worst possible combination for a flaw that only asks for network reach. If the answer is "I think not", that is an unverified no.
• The exact build number, not the branch. And checked against both lists, not one.
• Two windows, not one. The indicators for the 9.8 — user accounts nobody asked for, admin tokens issued — only make sense from 28 August onwards. The ones for the 5.3 start earlier, on the 12th, and they are different: files appearing outside the cache directory, in paths the Artifactory process can write to. Hunting for one set inside the other's window is a comfortable way to find nothing.
• Rotate what it holds, not only what grants access to it. The remote repository credentials, the registry ones, the federation ones. If you stop at changing the admin password, you have rotated the lock and not the keys inside.
• The list of what has been deployed since those dates, with the specific image and its digest. If your answer starts with "well, whatever was in the registry", that is the answer.
• If you had to doubt an artifact, could you rebuild it from source and compare? This is where the conversation stops being about security and becomes about recovery: restoring the repository backup gives you back the state it had, including whatever was planted in it. Restoring and rebuilding are not the same thing.

Patching is not cleaning

It is the same distinction we drew with the FortiOS symlinks, and it applies here in full. An authentication bypass leaves a quiet trail: no odd process, no new binary, just well-formed requests carrying a token the system considers valid. After patching, the install looks exactly as it did before, with one more user or one fewer credential. It applies to the whole 2 September batch too, which we already wrote about from the Kestra side: four of the seven flaws were internal software nobody calls production.

When we go in to look at one of these machines, the first thing we ask is not the version. It is which other machines believe what comes out of it and what credentials it uses to talk to everything else. The version gets fixed this afternoon; those two lists, in a lot of companies, have gone unwritten for years, and they are what decides how much it hurts the day the flaw shows up.

Sources (verified): CISA alert of 27 August 2026 adding three exploited vulnerabilities to the KEV catalog, among them CVE-2026-66384 (JFrog Artifactory, CWE-22): cisa.gov. CISA alert of 2 September 2026 with the seven additions including CVE-2026-82329: cisa.gov. Description, CWE-22, vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, score 5.3, 12 August publication, 10 September federal deadline and fixed versions 7.146.35 / 7.161.16 for CVE-2026-66384: public CVE record. watchTowr's analysis of the "phantom" join key, the empty string accepted as a valid join key, the exploitation observed on 1 September against its honeypot network (four days after the patch) and the enumeration of users, groups, credentials and federated access, as reported by The Hacker News and BleepingComputer (patch date 28 August 2026, fixed builds and the ability to poison existing packages). Chaining the two flaws, the reading of the vector, the deduction that branches 7.111 through 7.133 are left with no fix for the 5.3, and the restore-versus-rebuild distinction are our own reading, not the advisories'. The per-branch ranges for the 9.8 and the 7.111.4 lower bound come from public aggregators rather than the original advisory, and they disagree with each other on two branches.