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.

Overview of the GitLab CI Lint API SSRF Vulnerability

• 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.

Technical Breakdown of the Exploitation Flow and Attack Scenario

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.

1. Identification of Externally Exposed GitLab Instances Attackers perform internet-wide scanning based on GitLab resource patterns to discover externally exposed instances.
2. SSRF Execution via the CI Lint API By crafting malicious API requests, attackers induce the GitLab server to issue requests to attacker-specified URLs.
3. Internal Resource Access and Scanning By observing whether connections to internal IP addresses and ports succeed, attackers can map the internal network.
4. Sensitive Information Disclosure Tokens, keys, or configuration data may be exposed through cloud metadata services or responses from internal services.
5. Lateral Movement via Secondary Vulnerabilities or Credentials Using the leaked information, attackers attempt lateral movement to registries, internal APIs, and other systems.

Internet-Exposed GitLab Instances Identified Through Criminal IP Analysis

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.

Remediation Measures and Security 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

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