In early February 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2021-39935, a Server-Side Request Forgery (SSRF) vulnerability affecting GitLab Community and Enterprise Edition, to its Known Exploited Vulnerabilities (KEV) Catalog. Although this vulnerability was originally patched in 2021, renewed evidence of active exploitation targeting unpatched, internet-exposed GitLab instances led CISA to classify it as an issue requiring urgent remediation.
CISA required federal agencies to complete mitigation actions by February 24, 2026 (under BOD 22-01), and strongly recommends that private-sector organizations prioritize remediation at the same level. This article focuses on CVE-2021-39935, examining how externally exposed GitLab instances can lead to real-world attacks and outlining attack surface–driven strategies for identifying and managing such exposure.
CVE-2021-39935 Vulnerability Overview
- Vulnerability ID: CVE-2021-39935
- Affect products: GitLab Community Edition(CE), Enterprise Edition(EE)
- Vulnerability type: Server-Side Request Forgery (SSRF), CWE-918
- Attack conditions: Remote exploitation possible without authentication (unauthenticated)
- Primary impact: The GitLab server performs server-side requests to attacker-specified arbitrary URLs → enabling access to or scanning of internal resources, metadata exfiltration, and chained secondary exploitation
CVE-2021-39935 is known to stem from improper validation of user-supplied URLs in GitLab’s CI Lint API, which is used for CI/CD configuration validation and pipeline simulation. An attacker can craft malicious API requests that cause the GitLab server to issue requests to internal network addresses (e.g., RFC1918) or external resources of the attacker’s choosing. Because CI/CD and DevOps platforms concentrate high-value secrets, such as source code, tokens, deployment keys, and registry credentials, a single SSRF vulnerability can easily evolve from a “single-service compromise” into an initial access vector for organization-wide lateral movement.
CISA added this vulnerability to the KEV Catalog based on evidence of active exploitation. This indicates that attackers are already using automated scanning and exploit chains to hunt for unpatched GitLab instances actively, and that attempts to pivot into internal environments via externally exposed CI/CD platforms have re-emerged.
Attack Mechanism and Scenario
Attack Mechanism
SSRF follows a simple attack mechanism: user input → the server makes a request on the user’s behalf → the attacker indirectly accesses resources visible to the server. The core issue is that the CI Lint API does not sufficiently validate user-supplied URLs during the CI configuration validation process, creating a condition where the GitLab server can be induced to issue requests to those URLs. If an unauthenticated external attacker is able to craft and submit a request that invokes the CI Lint API, the server may attempt to connect to internal or external resources at the attacker’s direction.
Expected Attack Scenario
- Identification of Externally Exposed GitLab Instances
Attackers perform internet-wide scanning based on GitLab resource patterns to discover externally exposed instances. - SSRF Execution via the CI Lint API
By crafting malicious API requests, attackers induce the GitLab server to issue requests to attacker-specified URLs. - Internal Resource Access and Scanning
By observing whether connections to internal IP addresses and ports succeed, attackers can map the internal network. - Sensitive Information Disclosure
Tokens, keys, or configuration data may be exposed through cloud metadata services or responses from internal services. - Lateral Movement via Secondary Vulnerabilities or Credentials
Using the leaked information, attackers attempt lateral movement to registries, internal APIs, and other systems.
Status of Externally Exposed GitLab Instances Observed via Criminal IP
Vulnerability response becomes most challenging when organizations believe GitLab has been patched, while test, PoC, or department-specific instances still remain. When such instances persist, some are often left directly exposed to the internet, becoming the easiest targets for attackers. Therefore, the core issue in this case is not merely the existence of the CVE, but proactively identifying where and how many GitLab instances remain externally accessible.
Criminal IP Search Query: title: GitLab
To verify this, the above search query was applied in Criminal IP Asset Search, and as of February 6, 2026, a total of 71,069 assets were identified. When externally exposed GitLab instances exist, vulnerabilities such as CVE-2021-39935, which can be exploited at a pre-authentication stage via SSRF, can immediately turn them into active attack surfaces. Attackers are likely to infer GitLab version and configuration details indirectly, through the GitLab login page, static resources, and CI-related endpoint responses, and then prioritize unpatched environments as targets.
Criminal IP Search Query: title:”GitLab” AND port:443 OR port:80
Among the GitLab assets identified above, we further isolated those in which the GitLab web interface is directly accessible from the internet via standard web ports (HTTP/HTTPS). Applying this condition revealed a total of 311 exposed assets, indicating that a significant number of GitLab instances areimmediately discoverable regardless of authentication, simply by virtue of their publicly accessible web services.
Further analysis of a specific GitLab instance showed that four ports were open simultaneously, with more than 20 vulnerabilities identified at the same time. This indicates that the asset was not limited to exposure of a single service, but had a combination of web interfaces, remote access, and administrative functions exposed to the internet. In environments where multiple ports and vulnerabilities are exposed together, a pre-authentication SSRF vulnerability such as CVE-2021-39935 is more likely to function not as a standalone attack vector, but as an initial entry point.
After using SSRF to trigger internal requests, attackers can then pivot to other exposed components on the same asset—such as SSH (22), web services (80/443), and other vulnerable elements—to progressively expand the scope of the attack.
From the Criminal IP observation perspective, an important point is that even GitLab instances not included in an organization’s internal asset inventory are perceived by attackers as the same “external assets” the moment they respond to internet-based scanning. Test instances, temporary project deployments, or abandoned GitLab instances are therefore particularly vulnerable to attack for this reason.
Mitigation and Recommendations
Although CVE-2021-39935 has already been patched, its inclusion in the CISA KEV Catalog indicates that unpatched, externally exposed GitLab instances are being actively exploited in the wild. Accordingly, response efforts must go beyond simple version updates and include checks focused on external exposure.
- Immediate Patching and Version Verification
- Upgrade immediately to patched versions (14.3.6 / 14.4.4 / 14.5.2 or later)
- Review all GitLab deployments, including test, backup, and temporary instances
- CI Lint API and Related API Access Controls
- Reassess whether external users truly require access to the CI Lint API
- Block unnecessary API endpoints at the network or configuration level
- Log-Based Anomaly Detection
- Check for connection attempts targeting internal IP addresses or abnormal URLs
- Monitor for spikes in failed connections (timeouts, denied requests)
- Continuous Monitoring of Exposed Assets
- Use asset discovery tools such as Criminal IP Asset Search to continuously identify externally visible GitLab instances
- Establish automated checks for external exposure during new deployments or environment changes
FAQ
Q1. This vulnerability was patched back in 2021. Why was it added to KEV now?
Although a patch for CVE-2021-39935 was released in 2021, many GitLab instances that never applied the patch have remained exposed to the internet. CISA added it to the KEV Catalog not because it is a new vulnerability, but because active exploitation is still being observed today. GitLab is often deployed across test environments, temporary projects, and department-specific instances, making it easy for some deployments to fall outside patch and management scope. These unpatched, externally exposed environments become easy targets for attackers, which led CISA to classify this as a vulnerability requiring urgent action.
Q2. Is patching alone sufficient?
Patching is essential, but it is not sufficient on its own. CVE-2021-39935 is an SSRF vulnerability exploitable before authentication, meaning that external exposure itself is a key factor in determining attack feasibility.
If externally exposed GitLab instances existed prior to patching, attackers may have already probed internal network structures or accessed sensitive information. Moreover, if an organization does not have an accurate inventory of all GitLab instances, some assets may remain exposed even after patches are applied. Therefore, patching must be accompanied by an Attack Surface Management (ASM) approach that continuously identifies and validates externally exposed assets.
Conclusion
CVE-2021-39935 represents more than the resurfacing of an old GitLab vulnerability, it is a clear example of how easily externally exposed CI/CD infrastructure can be converted into real-world attacks. CISA’s KEV designation demonstrates that this is not a theoretical risk; unpatched GitLab instances still present on the internet are actively being targeted.
Organizations should not limit their checks to whether vulnerable versions are in use. They must continuously identify where externally accessible GitLab instances exist and repeatedly verify that exposure has truly been eliminated, even after patching and configuration changes. Defense strategy that combines vulnerability intelligence with visibility into the external attack surface can effectively protect CI/CD environments from pre-authentication SSRF vulnerabilities like CVE-2021-39935.
In relation to this, you can refer to CVE-2026-24061: Analysis of GNU Inetutils telnetd Authentication Bypass Vulnerability
You can subscribe to Criminal IP (criminalip.io/register) and start detecting vulnerable assets right away. Also you can request a demo through the button below, and try Criminal IP’s threat intelligence (TI) analysis of externally exposed assets on the Enterprise level.
This report is based on data from Criminal IP, a Cyber Threat Intelligence search engine. Sign up for a free Criminal IP account today to explore the search results mentioned in the report and delve into comprehensive threat intelligence.
Source: Criminal IP (https://www.criminalip.io), BleepingComputer(https://www.bleepingcomputer.com/news/security/cisa-warns-of-five-year-old-gitlab-flaw-exploited-in-attacks/), CyberSecurityNews (https://cybersecuritynews.com/cisa-warns-gitlab-ssrf-vulnerability-exploit/)
Related article: https://www.criminalip.io/knowledge-hub/blog/32569