CVE-2018-19571
Description
GitLab CE/EE, versions 8.18 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an SSRF vulnerability in webhooks.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
SSRF vulnerability in GitLab webhooks allows attackers to bypass IP validation using IPv6-mapped IPv4 addresses, potentially accessing internal services.
Vulnerability
SSRF vulnerability in GitLab CE/EE webhook URL validation. The URL blocker in lib/gitlab/url_blocker.rb fails to properly check IPv6 addresses that map to IPv4 (e.g., http://[0:0:0:0:0:ffff:127.0.0.1]:6379), allowing requests to internal IPs. Affects versions 8.18 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1 [1].
Exploitation
An attacker with project maintainer permissions can create a webhook with a malicious URL using an IPv6-mapped IPv4 address, such as http://[0:0:0:0:0:ffff:127.0.0.1]:6379. By testing the webhook, GitLab sends a POST request to the internal service [1].
Impact
Successful exploitation leads to blind SSRF, enabling an attacker to send POST requests to internal services without seeing the full response. This can be used for further penetration of the internal network [1].
Mitigation
Upgrade to GitLab 11.3.11, 11.4.8, or 11.5.1. No workaround is mentioned. The issue was fixed in those versions [1].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2- GitLab/GitLab CE/EEdescription
- Range: >= 8.18, < 11.3.11; >= 11.4, < 11.4.8; >= 11.5, < 11.5.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing validation of IPv6-mapped IPv4 addresses in the URL blocker allows SSRF bypass."
Attack vector
An attacker with the ability to create or modify a project webhook sets the webhook URL to an IPv6-mapped IPv4 address, e.g. `http://[0:0:0:0:0:ffff:127.0.0.1]:9100`, which bypasses the IP address validation in `lib/gitlab/url_blocker.rb` [ref_id=1]. When GitLab sends a POST request to that webhook URL, the request reaches the internal IPv4 address (in this example, 127.0.0.1 on port 9100). The attacker does not receive the full response body, making this a blind SSRF, but can still probe internal services for further exploitation [ref_id=1].
Affected code
The vulnerable code resides in `lib/gitlab/url_blocker.rb`, where the IP address validator fails to properly handle IPv6-mapped IPv4 addresses such as `http://[0:0:0:0:0:ffff:127.0.0.1]:6379` [ref_id=1]. This allows an attacker to bypass the block on private IPv4 addresses by expressing them in IPv6-compatible notation.
What the fix does
The advisory does not include a published patch diff, but the issue was resolved in GitLab versions 11.3.11, 11.4.8, and 11.5.1 [ref_id=1]. The fix would need to extend the IP address validator in `lib/gitlab/url_blocker.rb` to also detect and reject IPv6-mapped IPv4 addresses that resolve to private or loopback ranges, closing the bypass that the original check missed [ref_id=1].
Preconditions
- authAttacker must have permission to create or edit a project webhook
- inputAttacker must know or guess an internal service address and port to target
Reproduction
1. Create a webhook in any existing project with a URL such as `http://[0:0:0:0:0:ffff:127.0.0.1]:9100`. 2. Test the webhook; GitLab will send a POST request to the internal address mapped by the IPv6 notation [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- packetstormsecurity.com/files/160516/GitLab-11.4.7-Remote-Code-Execution.htmlmitrex_refsource_MISC
- packetstormsecurity.com/files/160699/GitLab-11.4.7-Remote-Code-Execution.htmlmitrex_refsource_MISC
- about.gitlab.com/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/mitrex_refsource_MISC
- gitlab.com/gitlab-org/gitlab-ce/issues/53242mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.