[Edenb2131]

• All tests passed. New table-driven tests added for the affected helper.
• All static analysis checks passed locally (gofmt, go vet).
• This pull request is on the dev branch.
• I used gofmt for formatting the code before submitting the pull request.

---

Summary

jf setup docker (and jf setup podman) fail immediately when invoked with --url. The CLI calls docker login "", the daemon resolves the empty registry to Docker Hub, and the user sees failed to login to container registry: docker login failed for: .

Reproduces on both SaaS and self-hosted — CLI-only defect, independent of Artifactory version. Tracked as RTECO-1352.

Reproduction

jf setup docker --url https://<tenant>.jfrog.io/artifactory \
  --user <user> --access-token <token> --repo <docker-virtual-repo>

Root cause

configureContainer derived the registry host from sc.serverDetails.GetUrl(). But createServerDetailsFromFlags (jfrog-cli) clears details.Url for the Rt command domain after copying it into ArtifactoryUrl:

case commonCliUtils.Rt:
    details.ArtifactoryUrl = details.Url
...
details.Url = ""

So on the --url path, GetUrl() returns "", url.Parse("") yields an empty URL, and ContainerManagerLogin is called with an empty registry — the daemon then defaults to Docker Hub.

The bug only manifests on --url. The --server-id path worked because saved configs populate Url from disk.

Fix

Extract a deriveContainerRegistryHost helper that:

• Reads GetArtifactoryUrl() first (populated on the --url path), falls back to GetUrl() (populated on --server-id).
• Returns parsedURL.Host directly — docker login takes only host[:port].
• Returns an explicit "server URL is empty; provide --url or --server-id" when both are empty, instead of silently redirecting to Docker Hub.

Tests

12 table-driven subtests in TestDeriveContainerRegistryHost covering: --url path, --server-id fallback, both-set precedence, ports, http scheme, self-hosted IP (with and without port), IPv6, subdomain registry method, embedded-credentials guard, no-scheme typo, both-empty. All pass.

Backward compatibility

No public API or flag changes. --server-id success path unchanged. The only user-visible change is a clearer error in the both-URLs-empty case.

Depends on:

1. jfrog-cli - RTECO-1352 - Fix jf setup docker login when using --url jfrog-cli#3517

[github-actions]

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 1 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	Not Found
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	1 Issues Found 1 Low
Secrets	✅ Done	-
Infrastructure as Code (IaC)	✅ Done	Not Found

---

🐸 JFrog Frogbot

[github-actions]

mainArtifactPath

at artifactory/commands/flexpack/maven.go (line 525)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Untrusted stored input used in file paths, allowing access to unintended files.

Full description

Vulnerability Details

Rule ID:	go-stored-path-traversal

Overview

Stored Path Traversal is a type of vulnerability that arises when user-controlled
input, such as file names or paths, is stored by the application and later used
without proper validation or sanitization to perform file operations. This can
allow an attacker to traverse directories and access or overwrite sensitive files
on the filesystem, potentially compromising the security and integrity of the
application or system.

Vulnerable example

func serveFile(w http.ResponseWriter, r *http.Request) {
    row := db.QueryRow("SELECT file_path FROM files WHERE id = 12")
    row.Scan(&filePath)
    http.ServeFile(w, r, filePath)
}

In this example, the serveFile function serves a file based on the file query
parameter provided by the user. However, in a real-world scenario, the filePath
variable might be retrieved from a stored source, such as a database or configuration
file, instead of being directly obtained from the request URL. The vulnerability
arises if the stored filePath is not properly validated or sanitized before being
used to serve files. Attackers could manipulate the stored filePath to perform
directory traversal attacks, potentially accessing sensitive files outside the
intended directory structure.

Remediation

To mitigate stored path traversal vulnerabilities, it is essential to validate
and sanitize user-controlled input before using it to construct file paths or
perform file operations. In this example, we can validate the file name to ensure
it does not contain directory traversal sequences before serving the file.

func serveFile(w http.ResponseWriter, r *http.Request) {
    row := db.QueryRow("SELECT file_path FROM files WHERE id = ?", r.URL.Query().Get("id"))
    row.Scan(&filePath)
+    // Validate file path to prevent directory traversal
+    if strings.Contains(filePath, "..") {
+        http.Error(w, "Invalid file path", http.StatusBadRequest)
+        return
+    }
    http.ServeFile(w, r, filePath)
}

Code Flows

Vulnerable data flow analysis result

↘️ os.ReadFile(pomPath) (at artifactory/commands/flexpack/maven.go line 554)

↘️ pomData (at artifactory/commands/flexpack/maven.go line 554)

↘️ pomData (at artifactory/commands/flexpack/maven.go line 560)

↘️ xml.Unmarshal(pomData, &pom) (at artifactory/commands/flexpack/maven.go line 560)

↘️ pom (at artifactory/commands/flexpack/maven.go line 568)

↘️ pom.Packaging (at artifactory/commands/flexpack/maven.go line 568)

↘️ getPackagingType(workingDir) (at artifactory/commands/flexpack/maven.go line 515)

↘️ packagingType (at artifactory/commands/flexpack/maven.go line 522)

↘️ fmt.Sprintf("%s-%s.%s", artifactId, version, packagingType) (at artifactory/commands/flexpack/maven.go line 522)

↘️ mainArtifactName (at artifactory/commands/flexpack/maven.go line 523)

↘️ filepath.Join(targetDir, mainArtifactName) (at artifactory/commands/flexpack/maven.go line 523)

↘️ mainArtifactPath (at artifactory/commands/flexpack/maven.go line 525)

---

🐸 JFrog Frogbot