Introduction
Attackers with authenticated access to GitLab can abuse webhook custom headers to make the server issue internal network requests, potentially exposing sensitive services and data. This vulnerability, tracked as CVE-2025-6454, affects a wide range of GitLab Community and Enterprise Edition deployments and is rated high severity (CVSS 8.5) due to its potential for lateral movement and internal resource exposure in enterprise environments.
GitLab is a major DevOps platform used by millions of developers and organizations worldwide. Its webhook integration capabilities are central to CI/CD workflows and third-party integrations, making vulnerabilities in this area especially impactful for the software development ecosystem.
Technical Information
CVE-2025-6454 is a server-side request forgery (SSRF) vulnerability in GitLab CE and EE. The flaw exists in the webhook custom header feature, introduced in version 16.11. When users configure webhooks, they can specify custom HTTP headers to be sent with outbound requests. GitLab's implementation did not sufficiently validate or sanitize these custom header values.
Authenticated users (typically with Maintainer or Owner roles) could inject crafted sequences into custom headers. In environments where GitLab is deployed behind a proxy, these headers could be manipulated to alter request routing. This allows the attacker to force the GitLab server to make requests to internal network resources, cloud metadata endpoints, or other sensitive services that are not directly accessible from outside the network. The vulnerability leverages the trusted position of the GitLab server within the network, bypassing perimeter controls.
The attack requires authenticated access to a project or group with webhook configuration permissions. No public code snippets are available for this issue. The vulnerability is categorized under CWE-918 (Server-Side Request Forgery).
Patch Information
In the GitLab 18.3.2 security release, several critical vulnerabilities were addressed to enhance the platform's security posture. One significant fix involved a cross-site scripting (XSS) vulnerability in the blob viewer. This issue allowed attackers to inject malicious scripts into the blob viewer, potentially leading to unauthorized actions on behalf of users. The patch implemented strict input validation and output encoding to neutralize such threats.
Another addressed vulnerability pertained to improper handling of permissions in the project API. Authenticated users with maintainer privileges could manipulate shared infrastructure resources beyond their intended access level, causing denial of service to other users' CI/CD pipelines. The fix involved refining permission checks to ensure that users can only access resources within their authorized scope.
Additionally, a cross-site scripting issue in labels was resolved. Authenticated users could inject malicious HTML content into scoped label descriptions, leading to stored XSS attacks. The patch introduced proper sanitization of label descriptions to prevent the execution of unauthorized scripts.
These patches collectively reinforce GitLab's commitment to security by addressing vulnerabilities that could compromise user data and system integrity. Users are strongly encouraged to upgrade to version 18.3.2 to benefit from these critical security enhancements.
Patch source: GitLab 18.3.2 Security Release
Affected Systems and Versions
- GitLab Community Edition (CE) and Enterprise Edition (EE)
- All versions from 16.11 before 18.1.6
- 18.2 before 18.2.6
- 18.3 before 18.3.2
- Any configuration where users can configure webhooks with custom headers is potentially vulnerable
Vendor Security History
GitLab has previously addressed SSRF and webhook-related vulnerabilities, often discovered through its active bug bounty program. The vendor typically responds quickly with coordinated patch releases and detailed advisories. However, the recurrence of SSRF issues in webhook features highlights ongoing challenges in securing complex integration points. GitLab's transparency and engagement with the security community are positive indicators of security maturity, but continued vigilance is necessary.