Bug bounty

Public

GNOME Bug Bounty Program

Securing Open Source Ecosystem

Reward

Bounty

Hall of fame

€500

Low

€500

Medium

€3,000

High

€5,000

Critical

€10,000

Program

Avg reward

Max reward

Scopes

Supported languages

English

Hacktivity

Reports

1st response

< 1 day

Reports last 24h

Reports last week

Reports this month

Program description

Program activity

Project

GNOME is a fully featured desktop environment and application platform for Linux. It is used by people all over the world (on e.g. Ubuntu, Fedora, RHEL, Tails) in many different security-critical contexts, including by activists, journalists, corporations, and governments. This makes it a valuable target to attack, and is why it's critical to keep it secure.

The GNOME desktop consists of hundreds of individual modules. However, to begin with we're focusing this bug bounty program on two critical components, GLib and libsoup.

This bug bounty program is managed by the Sovereign Tech Fund.

Program Rules

We are convinced that external review by skilled security researchers is crucial to identifying weaknesses in our software.
We are pleased to collaborate with you to resolve issues in our specifications and software, and to fairly reward you for the discovery of new security issues.
Any type of attacks on our infrastructure, including our source code repositories, is prohibited.
When you report an issue, we must be able to reproduce it with our setup.
An issue reported to us is considered to be a duplicate if it describes a similar attack to a known vulnerability (including issues received outside of YesWeHack) regardless of the component affected. That is, the triage team will use the "One Fix One Reward" process: if two or more programs or libraries use the same code base and a single fix can be deployed to fix all the others' weaknesses, only one issue will be considered as eligible for a reward, and other reports will be closed as Informative. We reward based on vulnerability, not per issue.
When reporting bugs against libraries, please ensure your proof of concept program does not itself violate preconditions of the library's public API functions, unless the violation results from a bug in GNOME code. Especially be sure to respect GLib's rule regarding valid UTF-8 string encoding. Failure to UTF-8 validate untrusted input is a vulnerability in the code using the library. GLib's UTF-8 string encoding rules apply to all GNOME libraries unless documented otherwise.
Please note that denial of service issues have been removed from the program scope.

Important precautions and limitations

As a complement to the program rules and testing policy:

DO NOT include Personally Identifiable Information (PII) in your
report and please REDACT/OBFUSCATE the PII that is part of your PoC
(screenshot, terminal transcripts, etc.) as much as possible.
DO NOT include secret key material unless that has been created exclusively for testing purposes.

Scopes

Modules:

libsoup: HTTP client/server library for GNOME. It uses GObjects
and the glib main loop, to integrate well with GNOME applications.
GLib: Low-level core library providing data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.
glib-networking: Implementations of certain GLib networking features that cannot be implemented directly in GLib itself because of their dependencies.

Eligibility

We are happy to thank everyone who submits valid reports that help us improve the security of GNOME; however, only those that meet the following eligibility requirements may receive a monetary reward:

You must be the first reporter of a vulnerability
The vulnerability must be a qualifying vulnerability (see below)
You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots as necessary. PoC exploit code in the form of a unit test similar in style to those already present in the code (where applicable) is highly appreciated.
You must not be a regular contributor to GNOME or the relevant modules
Our analysis is always based on the worst impact demonstrated in your PoC
When reviewing source code, the "main" or "master" branches represent the current versions that are available as packages. Only reports for those branches will be eligible for bounty

Reward

Asset value	CVSS Low	CVSS Medium	CVSS High	CVSS Critical
Medium	€500	€3,000	€5,000	€10,000

Scopes

Scope	Type	Asset value
GLib	other	Medium
Low €500 Medium €3,000 High €5,000 Critical €10,000
glib-networking	other	Medium
Low €500 Medium €3,000 High €5,000 Critical €10,000
libsoup	other	Medium
Low €500 Medium €3,000 High €5,000 Critical €10,000

Out of scopes

Only the list of modules in the description is in scope. We may add more modules in the future such as

json-glib

libxml2

libxslt

gdk-pixbuf

librsvg

flatpak

xdg-desktop-portal

xdg-desktop-portal-gnome

GNOME Shell (particularly lock screen)

tracker-miners

libsecret

libsecret

json-glib

Vulnerability types

Qualifying vulnerabilities

All reports must come with a full working proof of concept (PoC) that demonstrates the real impact of the issue.

Memory safety issues (e.g. use-after-free, double free, aliasing, out-of-bounds access)

Undefined behavior leading to a security vulnerability (e.g. integer overflow)

Race conditions (e.g. time-of-check-to-time-of-use races on file system checks)

Missing validation of untrusted inputs (e.g. injection of unescaped markup in output, following untrusted symlinks)

Privilege escalation (e.g. trusting environment data which comes across a privilege boundary when running as setuid)

Cryptographic problems (e.g. using insecure crypto primitives, insufficient randomness, incorrect handling of keys)

Exfiltration of confidential material (e.g. publicly caching thumbnails outside an encrypted partition, creating files with overly-generous permissions)

Supply chain issues (e.g. non-verifiable chain of trust on release artifacts)

Non-qualifying vulnerabilities

Denial of service (e.g. due to crashes / panics, unbounded memory allocation, non-termination, algorithmic complexity attacks)

Everything not in the qualifying vulnerabilities list is not accepted

Issues only found in outdated versions of our software (i.e. not vulnerable on the HEAD of the main or master branch)

Issues found in dependencies, that does not impact directly our project

Hunters collaboration

When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.

For more information, see help center.
Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.

To submit a vulnerability report, you need to login with your hunter account.