Researcher Terms and Disclosure Policy

Introduction

Mozilla's 0Day Investigative Network (0Din) is a GenAI bug bounty program that incentivizes the discovery and reporting of security vulnerabilities in large language models, attention-based systems and other generative models to enhance Internet and personal safety.

Vulnerability Bounty

Rewards range from $500 to $15,000 based on impact and report quality.
Bounties are discretionary, evaluated by the 0Din team.
As a generality: Low severity up to $500, Medium up to $2,500, High up to $5,000, and Severe up to $15,000.
Discoverers will be credited in the final advisory and may remain anonymous if they choose.
To claim a bounty, submit your discovery to 0din@mozilla.com leveraging our GPG key (9E2088D3) for end-to-end encryption.
Eligible bugs must be original, unreported / non-public, affect the latest available model generation.
Duplicate submissions within 72 hours share the bounty, with adjustments made for report quality.
Researchers are encouraged to use test accounts and avoid harming service availability or stability.
Submission details must be kept confidential during the validation period (two weeks). If contracted, then the confidentiality period extends through the coordinated public disclosure date as per our disclosure policy below.
Bounties can be donated to any of the following charities: AccessNow, Asociación por los Derechos Civiles, Association for Progressive Communications (APC), Center for Democracy & Technology, Center for Internet and Society Bangalore, Derechos Digitales, Electronic Frontier Foundation (EFF), EngageMedia, European Digital Rights (EDRi), Internet Archive, ITS-Rio, Kenya ICT Action Network (KICTANet), OpenNet Korea, Privacy International, R3D, SimplySecure, SMEX, Tactical Tech, The Guardian Project, Tor Project, Wikimedia Foundation.
This is a rapidly evolving space and these terms and conditions are subject to change. Researchers who we have engaged with will receive notification of such changes.

Vulnerability Scope

Commonly adopted GenAI models including but not limited to those from OpenAI, Meta, Google, Anthropic, SalesForce, etc.

Affected models can be commercial and/or open source.
Affected models should be commonly used.

Eligible bugs must exist within the models themselves, as opposed to the software ecosystem around the model. Examples along with their starting severities include but are not limited to:

Guardrail Jailbreak, LOW

Circumvention of built-in ethical guidelines, constraints, or safety measures that are put in place to prevent misuse.

Prompt Extraction, LOW

Unauthorized extraction of original inputs or queries that were provided to the model.

Prompt Injection, MEDIUM

Insertion of malicious or altered prompts into the model to manipulate outputs.

Command/Code Interpreter Jailbreak, MEDIUM

Bypassing the execution environment of an LLMs interpreter to execute arbitrary code.

Training Data Leakage, HIGH

Exposure of specific data leveraged to train the model.

Training Data Poisoning, HIGH

Introducing data that can corrupt or bias the model’s learning process.

Weights Disclosure, SEVERE

Exposure of the trained weights of the model, which contain the learned patterns and knowledge from the training data

Layers Disclosure, SEVERE

Revealing the architecture and internal parameters of the models Layers.

For more up to date information, please see our website 0din.ai.

For further reference on security boundaries within scope, see the OWASP LLM Top 10 and the MITRE ATLAS.

When in doubt, contact us with the model name and high-level boundary violation for review (see Abstract Sign-off below).

Eligible Participants

You must not exploit the security vulnerability for your own gain.
You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Corporation or any of its affiliates.
You must not be an employee, contractor, or otherwise have a business relationship with the company that makes the software or service for which you are reporting a vulnerability.
You must not have contributed to or be responsible for the vulnerability.
All submissions will be covered under Mozilla's Website & Communications Terms of Use, granting us permission to make use of all submissions.
You must be the age of majority to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.
You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.
All questions regarding the status of 0din bounties should be directed to 0din@mozilla.com and not other Mozilla bug bounty programs.

Vulnerability Processing and Disclosure Policy

Abstract Sign-off and Bounty Range

This is a novel space, to ensure we’re on the same page we recommend that researchers initially submit a high-level abstract of their findings and list the affected model(s). Within 3 business days we will respond with a decision on whether or not the flaw is within scope and what the likely range of bounty will be. The researcher can then decide to progress by submitting full details of the discovery.

Confirm Receipt of Submissions

We will confirm receipt of all vulnerability submissions within 1 business day. This ensures that researchers know their submissions have been formally received and are under review.

Validate Submitted Information

We will validate the information submitted by researchers within 2 weeks. During this period, our team will thoroughly assess the vulnerability to confirm its validity and impact. If the complexity of the submission requires further time for validation, we’ll let the researcher know early in this process.

In the event that our team is experiencing a heavy load, we will inform the researcher in our initial submission receipt. This transparency helps set expectations regarding the timeline for validation and further communication.

Duplicate Discoveries

The security bug must be original and previously unreported. Duplicate submissions within 72 hours will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a prorated additional bounty on top of the split.

Researcher Payment

We commit to submitting payment to researchers within 2 weeks of reaching a contractual agreement. This ensures that researchers are compensated promptly for their contributions. Bounties can be donated to certain charities (see above), and should be indicated by the researcher during the submission process.

As a matter of both policy and law, we must know who we are paying. Researchers must submit a valid government issued photo identification (ex: passport, drivers license) to be eligible for payment. Researchers are responsible for their own tax obligations in light of the reward. US based researchers must provide a completed IRS W-9 form. Non-US based researchers must provide a completed IRS W-8 form.

Vendor Notification

We will contact the affected vendor within 72 hours of reaching a contractual agreement with the researcher. Our preference is to contact a CVE Numbering Authority (CNA) or a formal security contact designated by the vendor.

If a formal security contact is unavailable, we will attempt to reach the vendor using the following email addresses: psirt@, security@, secure@, support@, and info@. These are common addresses used for reporting security issues.

Public Disclosure Timeline

If we are unable to connect with the vendor after three attempts over a two-week period, we will proceed with public disclosure of the vulnerability within 30 days. This ensures that the information is made available to the public in a timely manner to mitigate potential risks.

If we successfully connect with the vendor, we will provide them with up to one quarter (4 months, 120 days) to address the issue before public disclosure. This time frame allows the vendor sufficient time to develop and deploy a fix while ensuring that the vulnerability is eventually disclosed.

Public Disclosure

Once the public disclosure horizon has been met, we will post and advertise the vulnerability publicly. The 0din team will handle this process, and we will provide (optional) credit to the discovering researcher, acknowledging their contribution to improving security.

By adhering to this policy, we aim to balance the need for public awareness of vulnerabilities with the necessity of giving vendors adequate time to address security issues. Our goal is to foster a collaborative environment that enhances overall cybersecurity.

ØDIN BUG BOUNTY PROGRAM