In June 2024, GitLab patched a critical security vulnerability tracked as CVE-2025-12575. This bug affects GitLab EE in all versions from 18. before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4. Under certain conditions, it could let an authenticated user with specific permissions make unauthorized requests to internal network services—turning the GitLab server into a proxy for lateral movement or other attacks.

This post will explain the vulnerability in plain language, walk you through a simplified proof of concept, show you how to verify if you're at risk, and provide links to deeper technical references.

What’s the Issue?

GitLab is widely used in organizations to manage repositories and code. Its Enterprise Edition allows advanced features, but also exposes more complex attack surfaces.

CVE-2025-12575 is a *Server-Side Request Forgery* (SSRF) flaw. This means an attacker with a valid GitLab account can trick the GitLab server into sending unauthorized HTTP requests on their behalf. These requests can hit *internal-only* resources that would typically not be accessible from the outside world.

What’s SSRF Again?

To recap: SSRF happens when a web app fetches a URL provided by a user, but doesn't properly validate it. This lets attackers access internal services—such as cloud metadata APIs, or even other machines—via the vulnerable app.

18.8 before 18.8.4

Enterprise Edition only! (Community Edition is *not* listed as affected.)

You have enabled internal APIs or management interfaces only exposed within your internal network.

- You use GitLab as an internal development tool, but permit developers or automation tools to access GitLab with high privileges.

How Did This Happen?

The technical details haven’t been fully disclosed by GitLab, but based on the advisory and usual patterns, the likely scenario is:

- GitLab EE allows users with certain permissions to *configure* or *test* integrations, webhooks, or import features.

Attackers could abuse a feature that lets them supply a custom URL for testing.

- GitLab validates the URL only partially, or not at all, allowing users to enter internal resource addresses like http://localhost:900 or http://10...1:808.

PoC: How The Exploit Works

Below is a simplified proof of concept (not for malicious use!) that demonstrates how an authenticated attacker, granted the right permissions, could abuse this vulnerability.

Suppose GitLab has a 'test connection' feature for a webhook.

1. Attacker logs in and goes to webhook integration

# Replace with valid email & password
curl -c cookies.txt -d "user[login]=bob@example.com&user[password]=Password123" \
    -X POST https://gitlab.example.com/users/sign_in

# Set up a webhook that targets an internal resource
curl -b cookies.txt \
     -d "url=http://127...1:808/internal-api"; \
     -X POST https://gitlab.example.com/api/v4/projects/123/hooks

# Trigger the webhook and observe if the webhook results in unexpected internal traffic
# (You’d monitor logs or use a test internal endpoint for verification.)

Check your GitLab EE version:

sudo gitlab-rake gitlab:env:info | grep 'GitLab version'

Try setting a webhook to an internal-only address (if possible, in a test environment).

If you can get GitLab to successfully reach an internal service, you’re at risk!

GitLab improved validation of URLs supplied by users.

- The server now rejects requests targeting internal (127...1, localhost, 10.../8, etc.) addresses.
- Official security advisory: GitLab security release for CVE-2025-12575
- MITRE record: NVD Entry for CVE-2025-12575

Patch immediately: Upgrade to 18.6.6, 18.7.4, or 18.8.4 (or later).

2. Restrict user permissions: Only trusted users should be able to configure integrations or add/import URLs.
3. Monitor internal network access: Logs for internal services should be reviewed for any unexplained connections from the GitLab server.
4. Audit existing integrations: Remove any webhooks or integrations targeting internal endpoints unless absolutely necessary.

Further Reading

- GitLab blog: Security Release 18.6.6, 18.7.4, 18.8.4
- HackerOne: SSRF Cheat Sheet
- OWASP SSRF page

Conclusion

CVE-2025-12575 is a potent reminder that complex applications like GitLab can be a bridge into your internal network. Even “trusted” users with the wrong permissions and a little know-how can carry out high-impact attacks if you don’t keep your software updated and review your configurations. Patch now and review your exposure!


*Stay safe, and always keep your environments patched!*

Timeline

Published on: 02/11/2026 11:34:36 UTC
Last modified on: 02/11/2026 15:27:26 UTC