CVE-2026-65925

Think of JFrog Artifactory as a “package fetcher” that can pull content from remote places. With this flaw, a user who can read a specific Cargo remote repository can trick Artifactory into fetching from other places they choose, which can expose internal information—like an internal “caller” being forced to visit attacker-controlled destinations.

This matters if your business uses JFrog Artifactory and you have Cargo remote repositories configured in a way that someone can get read access to them. Because the attacker needs read access (not just a public login) and the system must be able to reach external URLs, the risk is highest when Artifactory is reachable by users inside your organization who can view Cargo remote repository settings and when outbound internet access from Artifactory is allowed.

This is RED because exploitation has been reported in real incidents tied to a JFrog Artifactory zero-day, meaning attackers are using this kind of SSRF to gain outbound internet access and move toward high-value targets. Even without a public exploit package, the practical exposure is real when Cargo remote repository read access and outbound connectivity are present.

1. Confirm whether you are in scope
   • Determine your exact JFrog Artifactory version.
   • Verify whether the Cargo remote repository feature is enabled/used.
2. Confirm whether the “read access” precondition applies
   • Identify who (which users/roles/service accounts) can read the Cargo remote repository configuration.
   • If any non-admin teams, contractors, or broadly-scoped roles can “read” Cargo remote repositories, treat that as a direct risk condition.
3. Patch (primary remediation)
   • Upgrade JFrog Artifactory to 7.111.18 or later.
   • After upgrade, repeat the checks in steps (1) and (2) to ensure the environment still matches your intended configuration.
4. If patching is delayed (temporary containment)
   • Restrict outbound network access from the Artifactory server so it can only reach the specific external hosts/domains required for your normal operations.
   • Reduce Cargo remote repository read permissions to the minimum required group(s), and remove any unnecessary accounts.
   • Review whether any internal-only destinations (internal apps, metadata endpoints, admin panels) are reachable from the Artifactory host—those should be blocked if not required.
5. What to monitor
   • Look for unusual outbound requests originating from the Artifactory server (unexpected domains, repeated failures, requests to “new” destinations).
   • Review Artifactory-related access logs to see whether users who can read Cargo remote repositories performed unusual actions around the same time.

CVE-2026-65925 is a Server-Side Request Forgery (SSRF) flaw (CWE-918) in JFrog Artifactory’s Cargo remote repository handling. Mechanism: an authenticated user with read access to the Cargo remote repository can influence Artifactory to initiate HTTP requests to attacker-chosen external URLs, enabling potential sensitive information leakage (confidentiality impact). Findings report exploitation as YES with incidents tied to a JFrog Artifactory zero-day used to escape an isolated testing environment and obtain internet access, followed by a breach of Hugging Face systems—this indicates real-world attacker utility rather than theoretical risk. There is no public exploit code on record, and the KEV list does not include this CVE. A patch is available: fixed in artifactory 7.111.18. EPSS is low and flat, but per the handling rules, real-world exploitation reported via news takes precedence for urgency.