← Back to Feed CACHED · 2026-08-18 07:21:19 · CACHE_KEY CVE-2026-42018
CVE-2026-42018 · CWE-287 · Disclosed 2026-08-12

JFrog Artifactory could return an internal anonymous-user token to an unauthenticated caller when anonymous…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone left a skeleton key under the doormat of your artifact vault, and the door is labeled 'No Entry'

CVE-2026-42018 is an authentication bypass in JFrog Artifactory's /api/v1/aws/token endpoint. A trailing-slash mismatch in the request filter causes Artifactory to fall back to an anonymous security context and mint a valid JWT for the internal anonymous user — even when anonymous access has been explicitly disabled. This affects both Artifactory OSS and Enterprise editions prior to version 7.146.8. The flaw was discovered by NetSPI and is chainable with CVE-2026-69107 (stash search path traversal + arbitrary export), which together allow an unauthenticated attacker to read restricted artifact bytes and write them to attacker-chosen filesystem locations.

JFrog's HIGH / 7.5 rating is *defensible but slightly conservative*. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) accurately captures the unauthenticated remote access and high confidentiality impact. However, it doesn't account for two real-world amplifiers: (1) Artifactory is canonically a supply-chain component — every artifact your CI/CD pipeline publishes or consumes lives here, and (2) the anonymous JWT enables the chain with CVE-2026-69107, turning a token leak into file-system-level exfiltration. The vendor score treats this as a standalone information-disclosure bug; in practice, it's the entry point to a supply-chain read-out chain. We nudge it to 7.8 to reflect the role multiplier while acknowledging that most Artifactory instances sit behind corporate networks, limiting the unauthenticated attack surface.

"Auth bypass in a supply-chain artifact store stays HIGH — the anonymous JWT is the skeleton key to your build pipeline."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover exposed Artifactory endpoint

The attacker identifies a JFrog Artifactory instance reachable over the network. This could be internet-facing (for remote CI runners or developer access) or reachable from a post-initial-access position inside the corporate network. Shodan/Censys/FOFA queries for Artifactory login pages or /artifactory/api/system/ping are trivial.
Conditions required:
  • Artifactory instance reachable on the network (TCP 8081/8082 or reverse-proxied on 443)
Where this breaks in practice:
  • Many enterprise Artifactory instances are behind VPN or corporate firewall, not internet-facing
  • Cloud-hosted JFrog SaaS instances are managed by JFrog and patched independently
Detection/coverage: Network scanners (Shodan, Censys) can enumerate public instances. Internal asset inventory should flag Artifactory hosts.
STEP 02

Send trailing-slash request to /api/v1/aws/token/

The attacker sends a crafted HTTP request to /api/v1/aws/token/ (note the trailing slash). The jf-router component's path-matching filter fails to apply authentication enforcement to this variant, passing the request through to the Tomcat backend. Artifactory falls back to an anonymous security context and returns a signed JWT for the internal anonymous user.
Conditions required:
  • Artifactory version < 7.146.8
  • Anonymous access is *disabled* (ironically, the bug only manifests when anonymous access is off)
Where this breaks in practice:
  • No public proof-of-concept exploit code has been published as of 2026-08-18
  • The trailing-slash trick is a well-known class but the specific endpoint and JWT minting behavior must be understood
Detection/coverage: WAF rules can flag trailing-slash variants on /api/v1/aws/token. Artifactory access logs will show token-minting requests from unauthenticated sessions.
STEP 03

Authenticate with the anonymous JWT

The attacker uses the minted JWT in subsequent API calls' Authorization: Bearer header. Artifactory validates the JWT signature (it was legitimately minted by the server) and grants the anonymous user's permission set. Even with anonymous access disabled, the internal anonymous user object may retain residual read permissions on repositories, especially if the instance was ever configured with anonymous access enabled.
Conditions required:
  • The anonymous user's permission set grants access to at least one repository
Where this breaks in practice:
  • If the Artifactory admin has explicitly stripped all permissions from the anonymous user principal, the token is valid but useless
  • Hardened deployments with zero repository permissions for anonymous limit blast radius to API metadata
Detection/coverage: Audit logs showing API calls from the anonymous principal when anonymous access is disabled are a strong anomaly signal.
STEP 04

Chain with CVE-2026-69107 for artifact exfiltration

Using the authenticated anonymous session, the attacker exploits CVE-2026-69107 to populate stash search results with attacker-controlled repository paths, then triggers the /artifactory/ui/stashResults/export endpoint with a path-traversal payload. This copies restricted artifact bytes to an arbitrary filesystem location readable by the attacker or exfiltrable via another channel.
Conditions required:
  • Artifactory version also vulnerable to CVE-2026-69107 (fixed in 7.146.8)
  • The anonymous JWT grants sufficient access to invoke stash/export endpoints
Where this breaks in practice:
  • Requires both CVEs to be present — patching either one breaks the chain
  • The export-to-filesystem step requires the attacker to have a read-back mechanism for the written files
Detection/coverage: File integrity monitoring on the Artifactory data directory. Anomalous export operations in audit logs.
STEP 05

Exfiltrate supply-chain artifacts

The attacker now has access to Docker images, npm packages, Maven JARs, PyPI wheels, Helm charts, or any other artifact type stored in Artifactory. These artifacts may contain proprietary source code, embedded secrets (API keys, certificates), or can be analyzed to understand the organization's entire software supply chain. In the worst case, the attacker uses this intelligence for a downstream supply-chain attack.
Conditions required:
  • Valuable artifacts stored in accessible repositories
Where this breaks in practice:
  • Organizations using Artifactory primarily as a proxy/cache for public repositories have lower-value artifacts
  • Secrets scanning and rotation policies reduce the value of embedded credentials
Detection/coverage: DLP or network monitoring for large outbound data transfers from the Artifactory host.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo confirmed in-the-wild exploitation of CVE-2026-42018 specifically. However, JFrog Artifactory was actively targeted in the July 2026 OpenAI/Hugging Face incident where AI models autonomously discovered and exploited *different* Artifactory zero-days (CVE-2026-65xxx series), demonstrating that Artifactory is a high-value target.
Proof-of-ConceptNo public PoC as of 2026-08-18. The NetSPI writeup describes the attack chain conceptually (trailing-slash bypass → JWT minting → stash export path traversal) but does not publish exploit code.
EPSS0.00298 (approximately 30th percentile) — low predicted exploitation probability, consistent with no public PoC and no KEV listing.
KEV StatusNot listed on CISA KEV as of 2026-08-18.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — Network-accessible, no privileges required, no user interaction, high confidentiality impact. The Scope:Unchanged and I:N/A:N limit the score to 7.5.
Affected VersionsJFrog Artifactory OSS and Enterprise editions prior to 7.146.8. Both self-hosted and self-managed deployments are affected. JFrog SaaS (cloud-hosted) instances are managed and patched by JFrog.
Fixed Version7.146.8 (includes fixes for both CVE-2026-42018 and CVE-2026-69107). Backported fixes available for several earlier release branches.
Scanning / ExposureJFrog Artifactory has over 5,000 enterprise customers globally, with the majority being organizations with 10,000+ employees. Approximately 72% of Artifactory deployments are cloud-hosted (JFrog SaaS), reducing the self-managed exposure population. Internet-facing self-hosted instances are discoverable via Shodan/Censys.
Disclosure Date2026-08-12 — disclosed 6 days ago.
ResearcherNetSPI — discovered both CVE-2026-42018 and CVE-2026-69107 as part of a chained vulnerability research effort.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.8/10)

Artifactory is canonically a CI/CD artifact store — the supply-chain role multiplier floors this verdict at HIGH regardless of network-access friction. The single most decisive factor sustaining HIGH is the role multiplier: compromise of the artifact repository grants read access to every build artifact in the organization's software supply chain, and the unauthenticated entry point requires zero prior access.

HIGH Vulnerability existence and mechanism (vendor-confirmed, researcher-documented)
MEDIUM Real-world blast radius of the anonymous JWT (depends on per-instance permission configuration)
LOW Exploitation in the wild (no evidence, but Artifactory is a demonstrated target)

Why this verdict

  • Unauthenticated remote entry point: AV:N/PR:N/UI:N means any network-adjacent attacker can obtain the JWT with a single HTTP request — no credentials, no social engineering, no user interaction required.
  • Role multiplier — supply-chain artifact store: Artifactory is not a line-of-business app; it is the canonical CI/CD artifact repository. Over 40% market share in universal artifact management. ≥10% of installs *are* the high-value role by definition. A read-out of all artifacts = proprietary code, embedded secrets, Docker images, Helm charts. The blast radius is supply-chain-scale, flooring the verdict at HIGH.
  • Chain amplifier with CVE-2026-69107: The anonymous JWT is the entry point to a documented chain that escalates from token leak to filesystem-level path-traversal exfiltration. Both CVEs are fixed in the same release (7.146.8), meaning unpatched instances are vulnerable to the full chain.
  • Friction discount — network exposure: The majority (~72%) of Artifactory deployments are JFrog-managed SaaS, which are patched by JFrog and not in scope. Self-hosted instances are typically behind corporate firewalls/VPNs. This limits the unauthenticated attack surface but does not eliminate it — remote CI runners, developer VPN access, and post-initial-access scenarios all provide network reachability.
  • No active exploitation or PoC (partial friction): EPSS at 0.3%, no KEV listing, no public PoC. This prevents an upgrade to CRITICAL but does not override the role-multiplier floor.

Why not higher?

CRITICAL would require either active exploitation (KEV listing, confirmed campaigns) or a chain that delivers RCE/supply-chain *write* access. CVE-2026-42018 alone delivers confidentiality impact only (C:H/I:N/A:N). The full chain with CVE-2026-69107 enables read-exfiltration and filesystem writes, but the write target is limited to the Artifactory host's filesystem, not arbitrary code execution in the build pipeline. The 72% SaaS deployment share also narrows the self-managed exposure population, and no public PoC exists to lower the exploitation barrier.

Why not lower?

MEDIUM would require the blast radius to be tenant-scoped or the attack surface to be negligible. Artifactory is a supply-chain component by definition — even if only 28% of deployments are self-managed, that represents ~1,400+ large enterprises. The unauthenticated entry point (PR:N) means no prior compromise is needed, just network reachability. The July 2026 OpenAI/Hugging Face incident proved that Artifactory zero-days are actively sought and exploited, even if this specific CVE was not involved.

05 · Compensating Control

What to do — in priority order.

  1. Block trailing-slash variants on /api/v1/aws/token at WAF/reverse proxy — Add a WAF or reverse-proxy rule (nginx, HAProxy, F5, Cloudflare) that rejects or normalizes requests to /api/v1/aws/token/ with a trailing slash. This directly blocks the bypass mechanism. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
  2. Audit and strip anonymous user permissions — Even if anonymous access is disabled, verify that the internal anonymous user principal has zero repository permissions. In Artifactory Admin → Security → Permissions, ensure no permission target includes the anonymous user or the readers group (which often includes anonymous). This limits the blast radius of any minted anonymous JWT to zero. Deploy within 30 days.
  3. Restrict network access to Artifactory — Ensure Artifactory is not exposed to the public internet. Place it behind VPN, zero-trust network access (ZTNA), or IP allowlisting. If remote CI runners need access, use a dedicated service mesh or private link. This eliminates the unauthenticated remote attack vector for external adversaries.
  4. Enable and monitor audit logging for anonymous principal activity — Configure Artifactory to log all API calls and set up SIEM alerts for any activity from the anonymous principal when anonymous access is disabled. This is a direct anomaly indicator of exploitation.
  5. Upgrade to Artifactory 7.146.8 or later — The definitive fix. This patches both CVE-2026-42018 and CVE-2026-69107. Apply within the 180-day noisgate remediation SLA for HIGH, but prioritize earlier given the supply-chain role.
What doesn't work
  • Disabling anonymous access alone does not help — the entire point of this CVE is that the bypass *only works* when anonymous access is disabled. The setting you think protects you is the prerequisite for the bug.
  • IP-based rate limiting — the exploit requires a single HTTP request to obtain the JWT. Rate limiting won't prevent a one-shot exploit.
  • Application-layer authentication (SSO/SAML) in front of Artifactory — if the /api/v1/aws/token/ path is not covered by the SSO integration (many deployments exclude API paths), the bypass still works.
06 · Verification

Crowdsourced verification payload.

Run this script on any host with network access to your Artifactory instance. Usage: bash check_cve_2026_42018.sh https://your-artifactory.example.com. No special privileges required — it makes a single unauthenticated HTTP request.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_42018.sh — Detect CVE-2026-42018 (JFrog Artifactory anonymous JWT bypass)
# Usage: bash check_cve_2026_42018.sh <ARTIFACTORY_BASE_URL>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

if [[ $# -lt 1 ]]; then
  echo "Usage: $0 <ARTIFACTORY_BASE_URL>"
  echo "Example: $0 https://artifactory.corp.example.com"
  exit 2
fi

BASE_URL="${1%/}"
ENDPOINT="${BASE_URL}/api/v1/aws/token/"

echo "[*] Testing CVE-2026-42018 against: ${BASE_URL}"
echo "[*] Sending trailing-slash request to: ${ENDPOINT}"

# Make the request and capture HTTP status + body
HTTP_RESPONSE=$(curl -s -o /tmp/cve_2026_42018_resp.txt -w "%{http_code}" \
  --max-time 10 \
  -H "Accept: application/json" \
  "${ENDPOINT}" 2>/dev/null || echo "000")

RESP_BODY=$(cat /tmp/cve_2026_42018_resp.txt 2>/dev/null || echo "")
rm -f /tmp/cve_2026_42018_resp.txt

echo "[*] HTTP status: ${HTTP_RESPONSE}"

if [[ "${HTTP_RESPONSE}" == "000" ]]; then
  echo "UNKNOWN — Could not connect to ${BASE_URL}. Verify URL and network access."
  exit 2
fi

# Check if a JWT token was returned in the response
if echo "${RESP_BODY}" | grep -qiE '("token"\s*:|"access_token"\s*:|eyJ[A-Za-z0-9_-]+\.)'; then
  echo "VULNERABLE — Artifactory returned a token via the trailing-slash bypass."
  echo "[!] Anonymous JWT minted despite anonymous access being disabled."
  echo "[!] Upgrade to Artifactory >= 7.146.8 immediately."
  exit 1
fi

if [[ "${HTTP_RESPONSE}" == "401" || "${HTTP_RESPONSE}" == "403" || "${HTTP_RESPONSE}" == "404" ]]; then
  echo "PATCHED — Endpoint returned ${HTTP_RESPONSE}. No anonymous token minted."
  exit 0
fi

if [[ "${HTTP_RESPONSE}" == "200" ]]; then
  # 200 but no token pattern — might be a different response format
  echo "UNKNOWN — Got 200 but no token pattern detected. Manual review recommended."
  echo "Response preview: $(echo "${RESP_BODY}" | head -c 200)"
  exit 2
fi

echo "UNKNOWN — Unexpected HTTP ${HTTP_RESPONSE}. Manual review recommended."
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: Identify all self-hosted JFrog Artifactory instances in your environment and confirm their version. If any are below 7.146.8, immediately deploy the WAF/reverse-proxy rule blocking trailing-slash requests to /api/v1/aws/token/ and audit the anonymous user's permission set — strip all repository access. These compensating controls should be in place within the 30-day noisgate mitigation SLA for HIGH, though given Artifactory's supply-chain role, aim for this week. Schedule the upgrade to 7.146.8+ within the 180-day noisgate remediation SLA, but push for completion within 30 days given the chain with CVE-2026-69107. Cloud-hosted JFrog SaaS customers should confirm with JFrog that their instance is patched. If you discover any evidence of anonymous-principal API activity in your audit logs while anonymous access is disabled, treat it as a confirmed compromise and escalate to your incident response team.

Sources

  1. NetSPI Research — Stealing the Artifact (Full Chain Analysis)
  2. JFrog Security Advisories
  3. JFrog Fixed Security Vulnerabilities
  4. JFrog Artifactory Market Share — 6sense
  5. PentesterLab — Research Worth Reading Week 33 2026
  6. The Hacker News — JFrog Artifactory Zero-Days and Hugging Face Breach
  7. SecurityWeek — JFrog Zero-Days in OpenAI-Hugging Face Hack
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.