JFrog Flaws Open Route to Package Cache Poisoning

Software supply chains are only as trustworthy as the metadata that guides how packages are fetched and verified. New research from Oligo Security shows that two vulnerabilities in JFrog Artifactory, a widely used repository manager, could let anonymous or low-privileged users manipulate that metadata without touching the underlying artifacts. The result is a cache-poisoning route that could serve malicious package indexes to downstream users.

Two Flaws, One Supply Chain Risk

Oligo Security reported the flaws to JFrog on June 25 and detailed them in research published on August 20. The findings cover CVE-2026-69106, a high-severity issue with a CVSS score of 8.8, and CVE-2026-65922, rated 5.4 on the CVSS scale. Both are listed on the National Vulnerability Database, and JFrog has issued fixes.

The first vulnerability stems from Artifactory accepting the X-Orig-Client-Uri header from external clients without verifying that it originated from trusted routing infrastructure. The second allows writes into trusted .jfrog/ metadata paths, bypassing normal authorization checks. Together, they could let an attacker influence how packages are resolved and served to other users.

Header Trust Enables Shared Cache Poisoning

Oligo found that Artifactory's trust in the X-Orig-Client-Uri header could be turned into a cross-user cache poisoning issue via virtual repositories. In Helm, the full attacker-controlled URL was written into generated metadata while only its 32-bit Java hash was used to determine the cache location. A different URL could therefore be constructed with the same hash and cause a poisoned index to be served to later users.

The researchers note that npm had a separate cache guard, but it checked two other override headers and not X-Orig-Client-Uri. This gap meant the header could still be abused in npm contexts, despite additional defenses.

The research also identified a related issue in JFrog's recommended nginx configuration. When a caching reverse proxy is deployed, the X-Forwarded-Proto header could be used to influence generated absolute URLs, potentially leading to cache poisoning.

Trusted Metadata Paths Bypass Normal Controls

The second vulnerability, CVE-2026-65922, affects Artifactory's handling of internal .jfrog/ metadata. The REST COPY and MOVE APIs, as well as WebDAV MKCOL, could reach these paths without the normal protection applied to standard uploads.

The resulting authorization path treated .jfrog/ as trusted, allowing an authenticated user with suitable repository access to place or create content there. Oligo said these files are consumed by package handlers for functions including npm signing keys, OCI referrers, Docker indexes and Ansible indexes.

Affected Users and What to Check

Organizations running JFrog Artifactory, especially those with virtual repositories, shared caches, or internet-accessible instances, should assess their exposure. Anonymous access, if enabled, could allow unauthenticated exploitation of the header trust issue. Authenticated users with repository access could exploit the metadata path flaw.

The researchers recommended upgrading Artifactory to a patched release and disabling anonymous access where it is not required, particularly in shared or internet-accessible environments. They also advised reviewing users and service accounts with repository access and stripping or overwriting client-supplied X-Orig-Client-Uri and X-Forwarded-Proto headers at the routing boundary.

Key Findings at a Glance

• CVE-2026-69106: CVSS score 8.8, affects handling of the X-Orig-Client-Uri header.
• CVE-2026-65922: CVSS score 5.4, allows writes into trusted .jfrog/ metadata paths.
• Reported to JFrog on June 25; research published on August 20.

Why It Matters

The supply chain is only as strong as the tools that manage it. These flaws highlight how trusted components—like a repository manager—can become attack surfaces if metadata is not properly validated. For organizations relying on Artifactory, the risk is not just a single compromised package, but a poisoned chain that could affect many downstream consumers. This could mean more scrutiny on header handling in other repository managers, and a reminder that even subtle trust assumptions can have cascading consequences.