CVE-2026-13540: GitBucket SSRF Vulnerability

CVE-2026-13540 Overview

CVE-2026-13540 is a Server-Side Request Forgery (SSRF) vulnerability in GitBucket up to version 4.46.1. The flaw resides in the Git.cloneRepository.setURI function within src/main/scala/gitbucket/core/service/RepositoryCreationService.scala. An authenticated attacker can manipulate the url argument during repository creation by cloning to force the GitBucket server to issue outbound requests to arbitrary destinations, including internal network resources.

The issue is tracked as [CWE-918] and has a public exploit disclosed alongside the advisory. The vendor has released a fix in commit 487a9b980f56aa73b6a044b1e86a92eed5043215, which introduces private-address blocking and IP whitelisting for the clone operation.

Critical Impact
Authenticated attackers can coerce GitBucket to send HTTP requests to internal services, enabling reconnaissance of otherwise unreachable systems on the host network.

Affected Products

GitBucket versions up to and including 4.46.1
Component: src/main/scala/gitbucket/core/service/RepositoryCreationService.scala
Component: src/main/scala/gitbucket/core/controller/AccountController.scala

Discovery Timeline

2026-06-29 - CVE-2026-13540 published to NVD
2026-06-29 - Last updated in NVD database
Patch commit - 487a9b980f56aa73b6a044b1e86a92eed5043215 merged via Pull Request #4056
Related issue - GitHub Issue #4044

Technical Details for CVE-2026-13540

Vulnerability Analysis

GitBucket allows users to create a new repository by cloning an existing repository from a user-supplied URL. The clone URL is passed directly to Git.cloneRepository.setURI without validation of the destination host. Because the clone runs server-side, any URL the attacker supplies is fetched from the GitBucket process, not the attacker's client.

An authenticated user can point the clone source at internal addresses such as 127.0.0.1, link-local ranges like 169.254.169.254, or private RFC1918 addresses. This turns GitBucket into a proxy for probing internal HTTP services, cloud metadata endpoints, and other network resources normally isolated from external users. The EPSS probability is currently low, but a public proof-of-concept increases the likelihood of opportunistic scanning.

Root Cause

The root cause is missing validation of the sourceUrl argument in the repository creation flow. The application accepted any URL and delegated fetching to JGit without checking whether the resolved host was private, loopback, or link-local. This is a classic [CWE-918] Server-Side Request Forgery pattern where user-supplied URLs drive server-initiated network requests.

Attack Vector

Exploitation requires an authenticated account with permission to create repositories. The attacker submits the "create repository by clone" form with sourceUrl set to an internal target. GitBucket resolves the host and initiates the clone, exposing response timing, error messages, and partial content that reveal information about internal services.

text

// Patch: src/main/scala/gitbucket/core/controller/AccountController.scala
} else if (form.initOption == "COPY" && !context.settings.basicBehavior.allowCreateRepositoryByClone) {
  // Creating by cloning is disabled by system settings
  BadRequest("Creating repositories by cloning is disabled.")
+} else if (form.initOption == "COPY") {
+  // Additional security: block cloning to private/internal addresses unless whitelisted
+  form.sourceUrl match {
+    case Some(src) =>
+      try {
+        val host = new java.net.URI(src).toURL.getHost
+        val isPrivate = HttpClientUtil.isPrivateAddress(host)
+        val whitelisted =
+          context.settings.webHook.whitelist.exists(range => HttpClientUtil.inIpRange(range, host))
+        if (context.settings.webHook.blockPrivateAddress && isPrivate && !whitelisted) {
+          BadRequest("Creating repositories by cloning from this address is blocked by system settings.")
+        } else {
+          // OK - proceed to create
+          createRepository(...)
+        }
+      } catch {

Source: GitHub Commit 487a9b98

Detection Methods for CVE-2026-13540

Indicators of Compromise

Repository creation events where the sourceUrl field resolves to loopback, link-local, or RFC1918 addresses.
Outbound HTTP requests from the GitBucket JVM process targeting internal hosts, cloud metadata IPs (169.254.169.254), or non-standard ports.
Failed clone operations in GitBucket logs with source URLs referencing internal DNS names.

Detection Strategies

Inspect GitBucket application logs and reverse-proxy access logs for POST requests to the new-repository endpoint containing suspicious sourceUrl values.
Correlate repository creation timestamps with unexpected outbound connections from the GitBucket host at the network layer.
Alert on repository creation by newly registered or low-reputation accounts to reduce insider abuse windows.

Monitoring Recommendations

Enable egress filtering on the GitBucket host and log any blocked connections to internal ranges.
Monitor for repeated failed clone attempts from the same account, which may indicate SSRF probing.
Track configuration changes to the GitBucket webhook.whitelist and webhook.blockPrivateAddress settings.

How to Mitigate CVE-2026-13540

Immediate Actions Required

Upgrade GitBucket to the version containing commit 487a9b980f56aa73b6a044b1e86a92eed5043215 or later.
Enable the Block sending to private addresses setting under Administration to activate the new SSRF protection for clone operations.
Review the webhook.whitelist configuration and remove any overly broad IP ranges that would bypass private-address blocking.

Patch Information

The fix is delivered in Pull Request #4056 and applied by commit 487a9b98. The patch validates the clone sourceUrl host against HttpClientUtil.isPrivateAddress and the administrator-defined IP whitelist. The admin UI section previously labeled "Web hook" is renamed to "Outbound requests" to reflect that the setting now governs both webhooks and repository cloning. Additional references are available at VulDB CVE-2026-13540.

Workarounds

Disable repository creation by cloning by unsetting allowCreateRepositoryByClone in system settings until patching is possible.
Restrict GitBucket egress at the network layer to only the external Git hosts required by your workflow.
Limit repository creation permissions to trusted users while the patch is being rolled out.

bash

# Configuration example: restrict GitBucket egress with iptables
# Block outbound traffic from the GitBucket host to internal ranges
iptables -A OUTPUT -m owner --uid-owner gitbucket -d 127.0.0.0/8    -j REJECT
iptables -A OUTPUT -m owner --uid-owner gitbucket -d 10.0.0.0/8     -j REJECT
iptables -A OUTPUT -m owner --uid-owner gitbucket -d 172.16.0.0/12  -j REJECT
iptables -A OUTPUT -m owner --uid-owner gitbucket -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner gitbucket -d 169.254.0.0/16 -j REJECT