In late 2022, security researchers uncovered CVE-2022-3819, a seemingly harmless but tricky vulnerability affecting GitLab Community Edition (CE) and Enterprise Edition (EE). This issue allowed unauthorized users to react with emojis on internal notes, even if they weren’t supposed to see those notes in the first place. The bug affected an enormous range of GitLab installations and highlights how even the most “fun” features can open the door to unauthorized actions.

This post will break down how the bug worked, show a sample exploit, and give tips on what you can do if your instance is still at risk.

What is CVE-2022-3819?

CVE-2022-3819 is an “improper authorization” vulnerability. In simple terms, it means GitLab didn’t properly check who was allowed to add an emoji reaction (“award emoji”) to certain comments called internal notes. Internal notes are supposed to be visible only to project members with special access, and not to everyone.

From 15.5 up to (but not including) 15.5.2.

If you are running any of these versions, your GitLab instance could be leaking information through emoji reactions.

Why Does This Matter?

At first glance, letting someone set an emoji on a note they’re not authorized to see doesn’t sound like a real security problem, but it is for a few reasons:

- Information Disclosure: Unauthorized users can see which issues or discussions exist, even if they can’t see the content. For example, the presence of internal notes can hint at sensitive investigations or discussions.
- Social Engineering: Attackers could use emoji reactions as a covert channel to communicate, signal, or annoy project members.

Audit Disruption: Reactions from outsiders can pollute audit logs and notification feeds.

If you’re running an open source project or work with sensitive code, these little leaks can add up.

Internal Notes: Visible only to authorized project members (e.g., developers, maintainers).

You can place award emojis (“reaction emojis”) on both types of notes, but the API endpoint handling emoji actions didn’t check properly if the user was allowed to see the note before letting them react.

Example API Sequence

As a lower-privileged (external) user, you shouldn’t be able to interact with internal notes at all. However, with CVE-2022-3819, you could perform the following:

1. Guess or Discover the Note ID

Suppose you know or can guess the ID of an internal note (usually sequential identifiers, so easy to brute force).

2. Craft API Request

You send a POST request to the Award Emoji endpoint, referencing that note ID.

Here’s an example using curl

curl -X POST \
  --header "PRIVATE-TOKEN: <your_external_user_token>" \
  --data "name=thumbsup" \
  "https://gitlab.example.com/api/v4/projects/<project_id>/notes/<note_id>/award_emoji";

3. Unauthorized Reaction

The API would accept this request and add a 👎 👍 🤩 or other emoji to the internal note, even though the user should have no access.

15.5.2

In the official advisory, they noted that access control checks were added to the Award Emoji API.

> “An improper authorization issue allowed unauthorized users to set emojis on internal notes. This issue is resolved in the latest patch releases.”
>
> — GitLab Security Release

How to Mitigate & Detect

- Upgrade Immediately: If you’re running a vulnerable version, upgrade your GitLab to at least the minimum patched version.
- API Auditing: Check your logs for spike in Award Emoji API calls from unexpected users on internal notes.

Rate Limiting: Apply rate limiting on your APIs to slow down brute-force note ID guessing.

- Regular Scans: Use tools like GitLab’s own Security Scanner to identify security issues.

References

- NVD Entry for CVE-2022-3819
- GitLab Security Release, Nov 2022
- Official GitLab Advisory

Conclusion

CVE-2022-3819 is a textbook case of how neglected access checks—especially on “harmless” features—can undermine security. If you’re running GitLab, check your version, apply patches, and audit your API endpoints. Sometimes, the smallest bugs can have outsized consequences.

Stay safe, and keep smiling (with authorized emojis only)!


*If you want to play with the API safely, always use a test environment. Let’s keep things ethical and responsible.*

Timeline

Published on: 11/10/2022 00:15:00 UTC
Last modified on: 11/11/2022 01:37:00 UTC