CVE-2025-2934 Overview
GitLab has patched a denial of service vulnerability affecting GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw impacts all versions from 5.2 prior to 18.2.8, 18.3 prior to 18.3.4, and 18.4 prior to 18.4.2. An authenticated attacker can trigger the condition by configuring a malicious webhook endpoint that returns crafted HTTP responses to the GitLab server.
The vulnerability is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling]. It requires low privileges and no user interaction, and can render the GitLab instance unresponsive for legitimate users.
Critical Impact
Authenticated users can exhaust GitLab server resources through crafted webhook response handling, disrupting availability for the entire instance.
Affected Products
- GitLab CE/EE versions 5.2 through 18.2.7
- GitLab CE/EE versions 18.3 through 18.3.3
- GitLab CE/EE versions 18.4 through 18.4.1
Discovery Timeline
- 2025-10-08 - GitLab releases patch versions 18.4.2, 18.3.4, and 18.2.8
- 2025-10-09 - CVE-2025-2934 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-2934
Vulnerability Analysis
The vulnerability resides in how GitLab processes HTTP responses returned from user-configured webhook endpoints. Webhooks in GitLab allow projects and groups to send outbound HTTP requests when repository events occur, such as pushes, merge requests, or pipeline changes. When the receiving endpoint returns a response, GitLab parses and stores relevant metadata for auditing and debugging.
Because GitLab does not sufficiently limit the resources consumed while handling these responses, an attacker who controls a webhook target can craft responses that force the server to allocate excessive memory or CPU cycles. This aligns with [CWE-770], where a system allocates resources based on attacker-influenced input without enforcing appropriate limits.
The condition affects availability only. There is no impact to confidentiality or integrity, and the attacker gains no data access from exploitation. However, sustained abuse can render the GitLab web interface, API, and CI/CD pipelines unresponsive to legitimate users.
Root Cause
GitLab's webhook subsystem accepts and processes HTTP responses from external endpoints without enforcing strict bounds on response size, parsing complexity, or resource allocation. An attacker-controlled server can respond with content designed to consume disproportionate server-side resources during processing.
Attack Vector
Exploitation requires an authenticated GitLab account with permission to create or modify webhooks on a project or group. The attacker configures the webhook URL to point at a server they control. When any event triggers the webhook, the malicious endpoint returns a crafted response that GitLab must process, exhausting server resources.
Repeated webhook triggers, or configuration across multiple projects, amplify the impact. Because webhook events can be induced by ordinary repository activity, the attacker does not need continuous interaction to sustain the denial of service.
For technical details, see GitLab Issue #528979 and HackerOne Report #3058791.
Detection Methods for CVE-2025-2934
Indicators of Compromise
- Webhook configurations pointing to unusual or newly registered external domains, particularly those created by low-privilege users.
- Sustained high memory or CPU consumption on GitLab Rails workers (sidekiq, puma) correlated with webhook execution jobs.
- Elevated error rates or timeouts in webhook_logs associated with specific endpoints returning oversized or malformed responses.
Detection Strategies
- Review the WebHookLog table for entries with abnormally large response payloads or repeated failures from the same endpoint.
- Monitor Sidekiq queues for backlogs in webhook-related job classes such as WebHookService and ProjectServiceWorker.
- Correlate webhook creation events in audit logs with subsequent spikes in resource usage on GitLab application nodes.
Monitoring Recommendations
- Enable audit logging for webhook creation and modification across all projects and groups.
- Instrument GitLab Rails and Sidekiq processes with resource-usage telemetry forwarded to a centralized SIEM.
- Alert on webhook endpoints resolving to non-corporate IP ranges or dynamic DNS providers.
How to Mitigate CVE-2025-2934
Immediate Actions Required
- Upgrade GitLab CE/EE to version 18.4.2, 18.3.4, or 18.2.8 depending on the deployed release branch.
- Audit existing webhook configurations and remove any pointing to untrusted or unrecognized external endpoints.
- Restrict webhook creation permissions to trusted maintainers where operationally feasible.
Patch Information
GitLab released fixed builds on 2025-10-08. Refer to the GitLab Patch Release 18.4.2 advisory for upgrade procedures and version-specific guidance. Self-managed instances should apply the patched release matching their current major.minor branch to avoid unnecessary upgrade complexity.
Workarounds
- Disable outbound webhooks at the instance level using the GitLab Admin Area outbound request settings until patching is complete.
- Configure the allowlist for outbound webhook destinations to restrict callbacks to internal, trusted IP ranges only.
- Apply rate limits on webhook execution through GitLab's application settings to reduce the amplification potential of malicious endpoints.
# Example: restrict outbound webhook destinations in gitlab.rb
gitlab_rails['webhook_timeout'] = 10
gitlab_rails['allowed_hosts'] = ['internal.example.com']
# Apply changes
sudo gitlab-ctl reconfigure
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.