A Docker-cache path traversal in Artifactory rattles the registry every team pulls from
CVE-2026-66384, a path traversal in Artifactory’s Docker cache, lets an authenticated user write outside the intended directory and joined CISA’s KEV catalog on 27 August 2026. Upgrade your self-hosted instance to 7.146.35 or 7.161.16 and restrict remote repository creation.
27 August 2026. CISA adds CVE-2026-66384 to its KEV catalog of exploited vulnerabilities. 10 September 2026. Federal remediation deadline, the farthest out of the day’s batch. CVSS 5.3. A Medium severity, the lowest of the three flaws added that day — and yet the most strategic, because it hits the software supply chain at its point of trust: the artifact registry.
The question is not “can someone execute code?” but “can someone tamper with what everyone downloads?”. The answer shifts the perceived severity.
A path traversal in the Docker cache
CVE-2026-66384 is a path traversal vulnerability in the Docker cache handling of JFrog Artifactory. Under specific remote repository conditions, an authenticated user can manipulate a file path to write data outside the intended cache directory, potentially toward other locations on the host.
The vector is more constrained than an anonymous RCE: CVSS 3.1 5.3, with AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N. Translated: network attack, high complexity, low privileges required, no user interaction, integrity impacted but no direct confidentiality or availability. This is an integrity flaw, not an execution flaw.
What matters here is the target. Artifactory is the chokepoint through which teams publish and pull their artifacts: Docker images, Maven packages, npm, PyPI, internal binaries. A write outside the cache is the ability to falsify an artifact exactly where pipelines fetch it, in full trust.
Affected versions and the fix
Self-hosted instances are affected in two ranges: versions before 7.146.35, and the 7.161.0 through 7.161.16 series (exclusive). The published fixes are 7.146.35 and 7.161.16. JFrog states that cloud environments are already hardened and that no managed-customer action is required.
CISA set the federal deadline to 10 September 2026, later than the day’s two other flaws — a direct reflection of the Medium severity and the authenticated nature of the attack. It did not flag this entry for “forensic triage”, a sign that the risk is more preventive than retrospective.
The artifact registry is the supply chain
An artifact registry like Artifactory is not plain file storage: it is the trust anchor of the software supply chain. When a CI/CD pipeline pulls a Docker image or a Maven package, it does not check every byte — it trusts the registry, by construction. That trust is why an integrity flaw, even one rated CVSS 5.3, has a blast radius out of all proportion to its score.
The Docker cache mechanism makes this concrete. Artifactory can act as a remote repository: it caches images pulled from external registries (Docker Hub, private registries) to speed up subsequent pulls. CVE-2026-66384 hits exactly this cache layer: under certain remote-repository conditions, an authenticated user can write outside the intended cache directory. A write that escapes the cache is the ability to tamper with an artifact at the very spot where teams fetch it.
The structural defense does not come from the patch alone. It comes from controls independent of the registry: artifact signing (Sigstore/cosign for images, SLSA for provenance) and checksum pinning. These mechanisms mean a tampered artifact is caught at pull time, even if the registry itself was compromised. A registry without signing is a supply chain that rests on the good health of a single component — and this CVE is a reminder that the single component is never perfectly healthy.
Why a Medium CVSS deserves high attention
The temptation is to slot CVE-2026-66384 at the back of the queue: Medium severity, authenticated attack, high complexity. That is a misreading. The CVSS score measures the technical impact of a one-off exploitation; it does not measure the blast radius inside a supply chain.
An artifact registry is an asymmetric target: compromising a single instance lets an attacker alter the artifacts of dozens of projects that consume it. CI/CD pipelines do not fine-check every byte — they trust the registry, by construction. A write-outside-cache that substitutes a malicious binary for a legitimate one turns a Medium flaw into a distributed entry point.
The KEV listing confirms the flaw is not theoretical: CISA only catalogs vulnerabilities exploited in the wild. Even a constrained vector, once industrialized, becomes a tool.
The history of supply-chain attacks shows how a single weak registry link scales. The Codecov breach of 2021 poisoned a build tool used by thousands of projects; the PyPI and npm ecosystems have weathered waves of typosquatting and credential-stealing packages; and SLSA emerged precisely because provenance was never verifiable. Artifactory sits at the same chokepoint. A write-outside-cache bug is not a novelty — it is the same class of weakness that turns one compromised component into many, and the only reason it is rated Medium is that it needs an authenticated foothold first.
What to do
- Upgrade self-hosted instances. Move to 7.146.35 or 7.161.16 depending on the installed branch. This is a focused maintenance task, not a rework.
- Restrict remote repository creation. Until the upgrade lands, limiting who can create or modify remote Docker repositories reduces exposure, since the vector depends on it.
- Treat the registry as critical infrastructure. The registry deserves the same rigor as secrets: restricted access, audit logs, artifact signing, and monitoring of abnormal writes.
- Verify recent artifact integrity. Even without a CISA forensic flag, checking checksums on recently published artifacts is cheap and reassuring.
# Check the version of a self-hosted Artifactory instance
curl -s -u admin:password http://<artifactory>:8081/artifactory/api/system/version
# Restrict remote repository creation: reserve the right to a dedicated group
# (via the Artifactory admin UI -> Permissions -> Remote Repositories)
# Verify the integrity of a Docker artifact pulled from the registry (example)
docker pull <artifactory>/<repo>/<image>:<tag>
docker image inspect <artifactory>/<repo>/<image>:<tag> --format '{{.RepoDigests}}' None of this requires a security vendor. The upgrade is a routine package bump, the repository restriction is a permission change, and the integrity check is a docker image inspect away. What it requires is recognizing that the registry is not infrastructure you can forget about — it is the one component whose integrity every other component inherits. In a software supply chain, the registry is not a bystander; it is the linchpin.
Verdict
If you self-host Artifactory, the upgrade to 7.146.35 or 7.161.16 is the right move, and it is fast. Do not defer it on the strength of the CVSS 5.3: an artifact registry is a target where an integrity flaw weighs heavier than its score suggests.
If you consume artifacts from a shared registry, the lesson is structural: trust in the registry must be backed by independent controls — artifact signing, checksum pinning, and audit of remote repositories. A Medium flaw in the right place does more damage than a critical flaw in the wrong one.
References
- CISA Adds Three Known Exploited Vulnerabilities to Catalog — CISA, 27 August 2026
- U.S. CISA adds ownCloud, Linux Kernel, and JFrog Artifactory flaws to its KEV catalog — Security Affairs, 28 August 2026
- August 27 2026 CVE Threat Brief — Carthage Electronics
- JFrog Security Advisories — JFrog
- CVE-2026-66384 — NVD