CVE-2026-13540 GitBucket SSRF Vulnerability: Authenticated Server-Side Request Forgery in Repository Clone

Technical summary

The vulnerability exists in the Git.cloneRepository.setURI function within src/main/scala/gitbucket/core/service/RepositoryCreationService.scala. Insufficient input validation on the URL parameter allows an authenticated user to inject arbitrary URLs, triggering server-side HTTP requests under the server's network context. This is a classic SSRF vector (CWE-918) where attacker-supplied input flows directly into URL processing without adequate sanitization. The attack surface is network-accessible and does not require special conditions beyond valid authentication.

Business impact

An authenticated user within or with access to your GitBucket instance could probe internal network segments, access cloud metadata endpoints, or interact with services that trust the GitBucket server's IP address. In cloud deployments, this could expose AWS/Azure/GCP credentials. In on-premises environments, it may allow discovery and lateral movement toward internal infrastructure such as databases, monitoring systems, or CI/CD pipelines. The confidentiality and integrity impact is limited to what the server can reach; direct code execution is not possible through this flaw alone.

Affected systems

GitBucket 4.46.1 and earlier versions are affected. Organizations running any version up to and including 4.46.1 should evaluate their exposure immediately. Later versions or the patched commit (487a9b980f56aa73b6a044b1e86a92eed5043215) resolve this issue.

Exploitability

Public exploit code is available, lowering the bar for opportunistic attackers. However, exploitation requires valid authentication—a user or account with GitBucket login permissions. In environments where GitBucket is internet-facing or has high user turnover, this significantly increases risk. The attack is trivial to execute once credentials are obtained; no special timing, race conditions, or user interaction is required.

Remediation

Apply the patch identified by commit 487a9b980f56aa73b6a044b1e86a92eed5043215 or upgrade to a version confirmed to include this fix. Verify patch application against the official GitBucket release notes or repository. As an interim control, restrict network egress from the GitBucket server to only necessary destinations and consider tightening access controls to limit who can create repositories.

Patch guidance

Consult the official GitBucket repository and release notes to confirm the exact version tag or release that includes commit 487a9b980f56aa73b6a044b1e86a92eed5043215. Apply patching in a test environment first to verify compatibility with your configuration. If you are running a version significantly older than 4.46.1, test thoroughly before deploying to production, as intervening updates may carry additional changes. Consider scheduling patching during a maintenance window given the authentication requirement—exploitation risk is elevated but not zero-day critical.

Detection guidance

Monitor GitBucket logs for unusual repository clone operations, particularly those targeting internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1) or cloud metadata endpoints (169.254.169.254). Network-based detection should capture HTTP requests originating from the GitBucket server to unexpected internal or external hosts. Log authentication events to identify compromised accounts or privilege escalation before exploitation. Search for repository creation or clone events immediately following suspicious login or user activity.

Why prioritize this

This vulnerability merits prompt attention despite CVSS 6.3 (MEDIUM) because public exploits are available and the attack surface spans any authenticated user. In multi-tenant or untrusted-user environments, the risk is elevated. However, it is not critical because exploitation requires valid credentials, limiting opportunistic automated attack. Prioritize patching if GitBucket is internet-facing or contains sensitive IP ranges in your internal network; deprioritize if it is internal-only with strict access controls.

Risk score, explained

CVSS 6.3 reflects the combination of network accessibility (AV:N), low attack complexity (AC:L), requirement for authentication (PR:L), and moderate impact on confidentiality, integrity, and availability. The score does not account for public exploit availability or the increased likelihood of abuse in cloud and hybrid environments. Your risk may be higher if you operate GitBucket in a segmented network with high-value internal services reachable from the GitBucket server.

Frequently asked questions