CVE-2021-39935

This vulnerability can trick a GitLab server into making “phone calls” to other destinations on an attacker’s choosing. Think of your GitLab as an office switchboard—if it’s exposed, a stranger might be able to dial internal extensions or other networks for them.

Even if the attacker never logs in, the server-side requests can be used to probe internal systems or reach services that aren’t normally accessible.

This matters if your business runs GitLab (CE or EE) in any version range affected by CVE-2021-39935. The findings say it does not require authentication and is reachable in the default configuration, so exposure can be possible without special setup.

It’s a risk when the CI linting interface is reachable from the network (for example, your GitLab is accessible to the internet or otherwise reachable by untrusted clients).

This is RED because CISA has added CVE-2021-39935 to its KEV list, meaning it is treated as a real, high-priority risk. Attackers can exploit it without authentication by forcing the GitLab server to send requests to attacker-chosen destinations, including potentially internal targets.

Your priority is to upgrade to the fixed GitLab version(s) immediately, and complete the required mitigation by 2026-02-24.

1. Confirm exposure and version

   • Identify your GitLab installed version (the exact build/version number).
   • Confirm whether your GitLab is reachable from untrusted networks and whether the CI linting interface is enabled and reachable as in the default setup.

2. Determine if you’re in an affected range

   • Affected if your version is:
     • from 10.5 before 14.3.6, OR
     • from 14.4 before 14.4.4, OR
     • from 14.5 before 14.5.2.

3. Upgrade to the fixed version

   • Follow GitLab’s security update guidance and upgrade to the fixed release.
   • The findings specify: GitLab fixed in 14.3.6 (and by implication, the corresponding fixed patch releases for the other branches).
   • Plan for downtime/maintenance window if your installation requires it.

4. Verify after upgrading

   • Re-check the GitLab version number to ensure it is now on a fixed release.
   • Confirm the CI linting endpoint still functions for legitimate users, and that it is exposed only as intended.

5. If patching is delayed (temporary containment)

   • Reduce or remove direct internet exposure to GitLab where possible (network-level restrictions/VPN/IP allowlists).
   • Ensure only trusted networks/users can reach the endpoints involved with CI linting.

6. Compliance timing

   • CISA KEV remediation due date: 2026-02-24.

7. What to monitor

   • Look for unusual outbound connections from the GitLab host/network (if you have egress visibility).
   • Review GitLab logs for suspicious CI linting requests from unexpected sources.

Severity context: GitLab SSRF-class issue (CWE-918). The weakness allows triggering server-side network requests (network reach) using crafted input to GitLab’s Continuous Integration linting interface.

Attack characteristics from findings:

• Authentication required: none
• User interaction: none
• Reachable in default config: true
• Mechanism: an attacker can force GitLab servers to send requests to arbitrary internal or external destinations.

Exploitation status:

• CISA KEV: Yes (added 2026-02-03) with a remediation due date of 2026-02-24.
• Public exploit code: none on record in the provided findings.

Fix availability:

• GitLab is fixed in 14.3.6 (with branch-specific fixed releases also referenced by the vendor security release materials).

Note on likelihood metrics:

• EPSS is provided as a prediction only in the findings; public likelihood percentages are not used to drive action because CISA KEV is present.