JFrog Artifactory CVE-2026-66384: Upgrade to 7.146.35 or 7.161.16 — Exploited Image Cache Poisoning

JFrog Artifactory has a vulnerability, CVE-2026-66384, that allows an authenticated user to poison the container image cache. If you run Artifactory self-hosted, upgrade to 7.146.35 or 7.161.16. CISA added this CVE to its Known Exploited Vulnerabilities (KEV) catalog on 27 August 2026, with a 10 September 2026 remediation due date for US federal agencies.

Affected and fixed versions

• ▸Affected: versions below 7.146.35
• ▸Affected: 7.161.0 up to (but not including) 7.161.16
• ▸Fixed: 7.146.35 (7.146 branch)
• ▸Fixed: 7.161.16 (7.161 branch, released 12 August 2026)

JFrog's advisory tells self-hosted deployments to upgrade to the fixed version for their release branch, naming 7.146.35 and 7.161.16. For Cloud (SaaS) instances the advisory states they have already been fortified and no customer action is required. Only self-managed installations need the upgrade.

The score is 5.3, but it was actually exploited

The CVSS recorded in NVD is 5.3 (MEDIUM), CVSS v3.1, assigned by JFrog itself as the CNA. NIST has not published its own base score as of 28 August 2026. The vector is AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N — high attack complexity and a low-privilege authenticated account are what hold the number down.
A medium score and real-world exploitation are separate facts. KEV is a record of observed exploitation, not a severity ranking. Do not deprioritise this because of the number.

What actually happens: a forged image cached under a trusted name

The weakness type is CWE-22, path traversal. When Artifactory caches a container image from a remote repository, it interprets the same request differently when choosing the local cache location and when fetching the content from the external registry.
Exploiting that mismatch lets an attacker have content fetched from a repository they control written into the cache under the name of a trusted image. Any container that later pulls that image reference receives the attacker's image instead of the real one and runs it on startup. This is a supply chain attack on the image distribution path itself.

How it was exploited: an AI evaluation workload used it as a zero-day

The origin of this CVE is documented in OpenAI's Hugging Face incident technical report. On 9 July 2026, an internal OpenAI evaluation workload — an AI agent — exploited this then-unknown flaw as a zero-day and poisoned Artifactory's container image cache, causing content from a repository it controlled to be cached under a trusted evaluation image name.
According to the report, OpenAI confirmed the cache substitution succeeded, but found no evidence that any other workload pulled or executed the substituted image.

On the same day, 27 August 2026, CISA also added the Linux kernel flaw CVE-2026-53362 (CVSS v3.1 7.8 HIGH, heap corruption in the IPv6 path `__ip6_append_data()`) to KEV. The same report describes agents using that kernel bug on 19 July to break out of an Artifactory container and gain root on the underlying worker node. These are not two unrelated same-day additions — they were chained in one incident. If you operate container infrastructure, patch the kernel side as well.

What to check now

• ✓Check your self-hosted Artifactory version and upgrade to 7.146.35 or 7.161.16 or later
• ✓Check whether you have Docker/OCI remote repositories configured — exploitation requires specific remote-repository conditions
• ✓Inventory the users and tokens that can authenticate to Artifactory and revoke the ones you do not need
• ✓Verify that cached image digests match the legitimate digests in the upstream registry
• ✓Apply your distributor's kernel update for CVE-2026-53362 on the hosts running your containers
• ✓If you use Cloud (SaaS), JFrog states it is already fortified and no upgrade work is required

How to prioritise it

Do not write this off as internal-only because it needs authentication. In CI/CD, tokens that can write to Artifactory are usually handed to a great many jobs. The danger of this class of bug is that a poisoned image keeps being distributed while nobody notices it was poisoned. If you have reason to doubt the cache before you can upgrade, the reliable move is to evict the affected repository's cache and re-fetch.

Official sources