Introduction
A chain of three individually modest weaknesses in GitBucket 4.23.1 combines into a single, devastating unauthenticated remote code execution path on Windows installations. By brute forcing a Blowfish key with only 10,000 possible values, traversing directories via backslashes in the Git LFS upload endpoint, and leveraging automatic plugin loading, an attacker can go from zero access to full system command execution without any credentials.
GitBucket is an open source, self hosted Git platform built on Scala that emphasizes easy installation and GitHub API compatibility. It serves organizations looking for lightweight, extensible Git infrastructure and supports features like public and private repositories, SSH access, Git LFS, and a plugin system. Its plugin architecture and LFS support, while useful, are the exact features that form the attack surface for this vulnerability.
Technical Information
CVE-2018-25332 is a chain of three distinct weaknesses that, when combined, allow a completely unauthenticated attacker to achieve remote code execution on Windows hosted GitBucket instances.
Weak Blowfish Token Generation
To interact with the Git LFS API, requests require an authorization token. GitBucket generates this token using Blowfish encryption, but the key derivation is critically flawed. The BlowfishKey variable is created using only the last four digits of the current system timestamp. This means there are at most 10,000 possible key combinations. An attacker can brute force the correct key by sending crafted tokens for each candidate key and monitoring for HTTP responses that do not return a 500 status code. A successful non error response indicates the correct key has been found.
Windows Backslash Path Traversal in Git LFS
The vulnerability originates in the unrestricted file upload functionality of the Git LFS transfer servlet. The getPathInfo function splits the requested URL using the forward slash character to extract the owner, repository, and object ID. However, on Windows systems, directories can be traversed using backslash characters. Because the function only splits on forward slashes, an attacker can inject backslashes into the object ID parameter.
The application then passes this unvalidated object ID directly to the Java file creation function via getLfsFilePath, allowing an attacker to write files to arbitrary directories, including the plugins folder.
Automatic Plugin Loading and Execution
GitBucket features a PluginWatchThread class that continuously monitors the plugins directory for changes and automatically installs and activates new extensions. By combining the brute forced token with the path traversal, an attacker can upload a malicious compiled Scala JAR file directly into the plugins directory. Once the server automatically loads the plugin, the attacker can trigger remote code execution by accessing an exposed web endpoint. In the publicly available proof of concept, the Scala !! operator is used to pass parameters directly to the system command execution function.
Full Exploit Chain
The attack proceeds in four discrete steps:
| Step | Component Abused | Action Performed |
|---|---|---|
| 1 | API Endpoint | Identify GitBucket installation via rate limit URL response |
| 2 | Authorization Header | Brute force 10,000 possible Blowfish keys to obtain a valid token |
| 3 | Git LFS API | Upload malicious JAR file using backslash path traversal to the plugins directory |
| 4 | PluginWatchThread | Wait for automatic plugin loading, then execute commands via web request |
The CWE classification is CWE-306 (Missing Authentication for Critical Function), which reflects the core issue: the LFS upload path and plugin loading mechanism lack adequate authentication and authorization controls.
Platform Considerations
The unauthenticated RCE is limited to Windows installations because the path traversal relies on backslash directory separators. However, an authenticated arbitrary file read vulnerability affects all platforms, so non Windows deployments are not entirely unaffected.
Affected Systems and Versions
GitBucket version 4.23.1 and all earlier versions are vulnerable to the full unauthenticated remote code execution chain on Windows. The vulnerability was partially addressed across multiple releases:
- Version 4.24.0: Resolves the remote code execution vulnerability
- Version 4.24.1: Fixes a Web API authentication bug
- Version 4.25.0: Resolves the weak security token generation; this is the first version where both the path traversal and the cryptographic weakness are fully eliminated
Any GitBucket installation running on Windows with a version prior to 4.25.0 should be considered at risk.
Vendor Security History
The GitBucket maintainers demonstrated responsiveness to this vulnerability by releasing three sequential patches in rapid succession. Version 4.24.0 shipped on April 30, 2018, addressing the RCE. Version 4.24.1 followed on May 1, 2018, fixing a Web API authentication bug. Version 4.25.0 completed the remediation by resolving the underlying token weakness. The platform's core extensibility features, specifically its plugin system and LFS support, directly contributed to the attack surface exploited in this CVE.
References
- NVD Entry for CVE-2018-25332
- GitBucket GitHub Repository
- GitBucket 4.23.1 Unauthenticated Remote Code Execution (Kacper Szurek)
- Exploit Database: GitBucket 4.23.1 Remote Code Execution (EDB 44668)
- VulnCheck Advisory: GitBucket Unauthenticated Remote Code Execution
- GitBucket 4.25.0 Release Notes
- GitBucket CHANGELOG
