Server-Side Request Forgery in GitBucket

Executive Summary

CVE-2026-13540 is a Server-Side Request Forgery (SSRF) vulnerability in GitBucket versions up to 4.46.1. It occurs in the function Git.cloneRepository.setURI within the RepositoryCreationService.scala file. When an authenticated user creates a new repository by cloning from a user-supplied URL, the URL is not properly validated. This allows an attacker to manipulate the URL argument to force the GitBucket server to make outbound HTTP/HTTPS requests to arbitrary or internal network addresses.

The vulnerability enables remote attackers to make the server send requests to internal services or attacker-controlled endpoints, potentially exposing sensitive internal network information or cloud metadata services. The issue was fixed by a patch that blocks cloning from private IP addresses unless explicitly whitelisted.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring for outbound HTTP/HTTPS requests initiated by the GitBucket server with a distinctive User-Agent header "JGit/...". Specifically, when an authenticated user creates a new repository by cloning from a user-supplied URL, the server makes an outbound request to that URL without validation.

To detect exploitation attempts, you can monitor network traffic for outbound requests from the GitBucket server to unusual or internal IP addresses, especially those with the User-Agent header starting with "JGit/".

Example commands to detect such activity might include:

• Using tcpdump or tshark to capture outbound HTTP requests from the GitBucket server:
• tcpdump -i <interface> -A 'tcp dst port 80 or tcp dst port 443' and src host <gitbucket-server-ip>
• Using grep or similar tools on web server or proxy logs to find requests with User-Agent containing "JGit":
• grep 'User-Agent: JGit' /var/log/proxy/access.log
• Review GitBucket application logs for repository creation events with cloning URLs.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by allowing an attacker with an authenticated account to make the GitBucket server perform unauthorized requests to internal or external systems. This can lead to information disclosure about internal network services, cloud metadata endpoints (such as AWS IMDS, GCP metadata, Azure IMDS), or scanning of private networks.

Such unauthorized requests can be used to gather sensitive information, potentially leading to further attacks or exploitation of internal infrastructure. Since the default GitBucket configuration allows all registered users to create repositories, the attack surface is broad.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability CVE-2026-13540 is a Server-Side Request Forgery (SSRF) issue in GitBucket that allows authenticated users to make the server send requests to arbitrary internal or external addresses. This can lead to unauthorized access to internal network services and cloud metadata endpoints, potentially exposing sensitive information.

Such unauthorized access and data exposure risks could impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of personal and sensitive data against unauthorized access and disclosure.

The vulnerability enables attackers to probe internal services and cloud metadata, which may lead to confidentiality breaches. This undermines the security controls expected by these regulations.

The patch and mitigation measures, such as blocking private IP addresses and allowing IP whitelisting for cloning operations, help reduce the risk and improve compliance posture by limiting unauthorized outbound requests.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to apply the patch that fixes this vulnerability, which is included in GitBucket version 4.47.0 and later.

Additionally, enable the new security feature that blocks cloning repositories from private or internal IP addresses unless explicitly whitelisted. This feature can be configured in the system settings under "Outbound requests" by enabling "Block sending to private addresses" and managing the IP whitelist.

If immediate patching is not possible, restrict repository creation permissions to trusted users only, as the vulnerability requires authenticated user access.

Monitor and audit repository creation activities to detect any suspicious cloning attempts.

Useful 0 Not Useful 0