GitLab Workhorse Security
GitLab Workhorse is a smart reverse proxy for GitLab positioned between NGINX and the Rails application[^c1]. It intercepts all HTTP traffic to and from Rails and handles resource-intensive operations such as file transfers, Git operations, and data streaming. All authentication and authorization decisions remain in the Rails application, and all requests to Rails pass through Workhorse[^c2].
Workhorse relies on a shared-secret JWT mechanism for internal authentication with Rails and other components such as [[gitaly]] and [[gitlab-shell]]. Rate limiting protects the Rails backend from overload, and a multipart middleware with allowed-path validation secures file upload processing.
The proxy has been the subject of numerous security vulnerabilities. Several classes of bypasses have been identified: parser differentials between Workhorse and Rails's middleware stack, HTTP request smuggling through inconsistent interpretation of requests, and architectural weaknesses such as upload processing code executing before authentication checks. The most critical vulnerability, CVE-2021-22205, allowed unauthenticated remote code execution through ExifTool and was widely exploited in the wild.
The May 2026 security release (versions 18.11.3, 18.10.6, 18.9.7) fixed 25 CVEs, none of which affected GitLab Workhorse[^c3], confirming that the proxy's attack surface remains concentrated in its specific responsibilities.
Note: JWT authentication scope
The statement "Workhorse relies on a shared-secret JWT mechanism for internal authentication with Rails and other components such as Gitaly and GitLab Shell" overstates the scope. Workhorse uses the shared-secret JWT mechanism to authenticate to Rails. Gitaly and GitLab Shell are consumers of the same JWT pattern when authenticating to Rails's internal API (see [[internal-api-auth]]). For direct gRPC communication, Gitaly uses its own HMAC-based token scheme (see [[gitaly]]), not JWT. GitLab Shell and Workhorse do not directly authenticate to each other.