Security1 distinct publisher2 min readUpdated
Oligo Security says a 32-bit cache key and a trusted .jfrog/ directory let low-privileged users serve other people a poisoned index. JFrog has patched both.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
The Helm case is worth reading slowly, because the defect is not the header itself, it is a disagreement between two keys. Oligo found that the full attacker-controlled URL was written into the generated metadata, while only its 32-bit Java hash decided where that metadata got cached [7]. Construct a second URL with the same hash and it lands in the same cache slot, so the next user to ask for the index is served the attacker's copy [7]. Virtual repositories are what make that cross-user rather than self-inflicted [8]. A 32-bit space holds 4,294,967,296 values [1], and I would not describe searching that as an obstacle.
npm did not fall the same way, and the reason is the interesting part: it had a separate cache guard, but the guard checked two other override headers and not X-Orig-Client-Uri [c8b]. That is a list of headers somebody remembered, not a rule about which headers may survive the routing boundary. The same assumption appears in JFrog's own recommended nginx configuration, where X-Forwarded-Proto could influence generated absolute URLs once a caching reverse proxy sat in the path [9]. Product and guidance agreed on the wrong thing, which is that a header arriving from an external client says something reliable about routing [6].
The second bug is quieter and reads worse. Artifactory's authorization path treated .jfrog/ as trusted, and the REST COPY and MOVE APIs plus WebDAV MKCOL could reach it without the protection applied to a normal upload [10]. Oligo lists what consumes those files: npm signing keys, OCI referrers, Docker indexes and Ansible indexes [11]. An authenticated user with suitable repository access could place or create content there [12], which is a write into the directory that tells package handlers which key to believe. The 3.4-point CVSS gap between the two findings [2] is scoring the access required, not the trust reached.
A registry mirror earns its place in most threat models by being infrastructure you own, and what you own is a store of bytes with digests attached. The part that decides which bytes a client fetches, and whether it trusts the signature on them, was on an unpatched instance writable by someone who could not write a package [1]. Provenance verified at the consumer, against a digest recorded somewhere other than the registry, survives both of these findings. "It came from our Artifactory" does not.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Two vulnerabilities in JFrog Artifactory allow anonymous or low-privileged users to manipulate package metadata without modifying the underlying artifacts, creating a potential route to software supply chain compromise.
Oligo Security reported the flaws to JFrog on June 25 and detailed them in research published on August 20.
CVE-2026-69106 carries a CVSS score of 8.8 and affects the handling of the X-Orig-Client-Uri header.
CVE-2026-65922 carries a CVSS score of 5.4 and allows writes into trusted .jfrog/ metadata paths.
Both flaws are listed on the National Vulnerability Database and JFrog has issued fixes.
CVE-2026-69106 stemmed from Artifactory accepting X-Orig-Client-Uri from external clients without verifying that it originated from trusted routing infrastructure.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and coherent, but single-outlet relay of vendor research
The technical account is unusually concrete: named CVEs with CVSS scores, the exact header at fault, the 32-bit hash cache-key mismatch, the specific API verbs that reached .jfrog/, and NVD listing plus vendor fixes. All of it, however, comes from one trade article relaying Oligo Security's own research; the cluster contains no primary advisory, no NVD record, no JFrog confirmation and no patched version numbers, so corroboration and verifiable remediation detail are both thin.
Fixes shipped; real-world exposure and uptake unknown
The only observable uptake events are vendor-side: JFrog issued fixes and both CVEs were published to the NVD following coordinated disclosure. Nothing in the supplied material speaks to how many Artifactory deployments are affected or patched, whether anonymous access is commonly enabled in the field, or whether the flaws were exploited, so this scores low on real-world traction rather than on issue quality.
Slightly overstated by framing, restrained in substance
The headline framing ('enable software supply chain attacks') runs somewhat ahead of what is shown: one flaw scores 5.4 and requires an authenticated user with repository access, no exploitation in the wild is reported, and fixes already exist. The body text is measured and hedged ('potential route'), and the underlying cache-poisoning mechanism is genuinely serious, so the gap is modest rather than large.
Vendor research marketing, relayed by trade press without disclosure
The findings originate with Oligo Security, a commercial security vendor whose published research serves a marketing function, and the article does not flag that interest. JFrog's incentive runs the other way, toward downplaying severity, and its patch-and-NVD path is visible. The reporting outlet has no evident stake beyond security-news traffic, so incentives are present and one-sided in sourcing but not concealed in substance.
Moderate: coherent detail, no independent corroboration
Confidence is held down by single-publisher sourcing and the absence of primary advisories or version data, and held up by the internal specificity of the technical account, the named CVEs with CVSS scores, and the stated NVD listing and vendor fixes, which would be easy to falsify if wrong.
build
One unsigned parent, dozens of children: why image signing keeps losing to scanning1 distinct publisher
build
Your scanner finds it in seconds; the average fix now takes 252 days1 distinct publisher
build
Fabricated SQLite CVEs cleared NVD, CISA ADP and Red Hat before anyone ran the code1 distinct publisher
security
Akrites switches on in September with 20-odd members and a one-to-10 engineer donation band1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 20, 2026