OpenZeppelin

As the premier crypto cybersecurity technology and services company, we’ve built OpenZeppelin Contracts with our best security practices. We are committed to ensuring the utmost security in our community-vetted smart contracts, and our bounty program provides rewards of up to $25,000 USD for reporting critical vulnerabilities in our smart contracts library. This bug bounty program is focused on OpenZeppelin Contracts and mainly intends to prevent:

• Loss of funds by freezing another user’s funds, or theft of another user’s funds
• Permanent denial of service (smart contract is made unable to operate)
• Access control bypass, including privilege escalation
• Smart contract not behaving as intended

This is an overlay bug bounty program for OpenZeppelin’s Contracts library. A vulnerability in an OpenZeppelin contract would likely affect many other projects and could trigger various other bounties. This program would be potentially additive to those cases.

OpenZeppelin may issue GHSA/CVEs for reported vulnerabilities and will offer to credit issue reports in those public reports.

Responsible Publication

OpenZeppelin adheres to category 1 - Transparent. This Policy determines what information researchers are allowed to make public from their submitted bug reports. For more information about the category selected, please refer to our Responsible Publication page.

Primacy of Impact vs Primacy of Rules

OpenZeppelin adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.

Known Issue Assurance

OpenZeppelin commits to providing Known Issue Assurance to bug submissions through their program. This means that OpenZeppelin will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission.

In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.

Previous Audits

OpenZeppelin’s completed audit reports can be found at OpenZeppelin Contracts’ Security Center while previous security advisories are available at GHSA/CVEs. OpenZeppelin will offer to credit issue reports in those public reports. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

Feasibility Limitations

OpenZeppelin will assess likelihood depending on the complexity of the steps involved in its execution and the exposure created by the vulnerability, as well as impact depending on the assets or systems at risk, capped to the worst-case impacted instance using the affected code.

OpenZeppelin will evaluate the vulnerability of the affected code considering whether the issue arises directly from the library code while used as provided or if it requires a custom user implementation. Determining the likelihood of exploit on custom implementations will depend on how likely a library user is to make such an implementation and how common is the pattern leading to it.

For example, if a data structure can be cleared by any caller of a smart contract, its likelihood will be high if it holds user balances, although, if the vulnerability allows overriding non-critical values such as an already executed governor proposal flag, its likelihood will be low but can escalate to medium if it comes with side effects that increase the incentives of exploitation (e.g. proposal re-execution).

Similarly, if an instance of an AccessManager can be made unusable, its impact will be high but could be lowered to medium if the attacker requires special permissions in the system, and finally, it will be considered low if the contract is frozen only during 1 block before a threshold is met.

The final threat level will be decided based on the matrix above. For a vulnerability with low impact, if its likelihood is high because the cost of exploiting a single instance is negligible, then its final threat level will be medium severity.

Immunefi Standard Badge

By adhering to Immunefi’s best practice recommendations, OpenZeppelin has satisfied the requirements for the Immunefi Standard Badge.

KYC Requirements

OpenZeppelin’s bug bounty program requires an invoice to be submitted and a KYC screen to be performed prior to OpenZeppelin providing a bug bounty reward. Once a payout is confirmed, a member of OpenZeppelin will reach out to you directly to collect the necessary information, including:

• Full Legal Name
• Email Address
• Mailing Address
• Wallet Address (Ethereum Mainnet Only)

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.3. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

The rewards stated here are additive to any existing bug bounty programs hosted by projects that are currently using OpenZeppelin contracts.

Bounty rewards are given according to an impact/likelihood matrix for assessing threat levels. Each issue is assessed considering the likelihood of the vulnerability being successfully exploited and the expected impact in scope to a single instance of the affected smart contract. Note that, as can be seen in the matrix, if the impact is Critical then the threat is always Critical, for other impacts the maximum reduction is one level only if the likelihood is low, and if the likelihood is high then the threat is increased one level above the impact.

Proof of Concept (PoC) Requirements

A PoC compliant with Immunefi PoC Guidelines and Rules is required for the following severity levels:

• Smart Contract: Critical
• Smart Contract: High

Bugs introduced by a release candidate version and reported during the review period, the dates for which will be declared by OpenZeppelin on each release, will receive a 50% bonus.

Payouts are handled by the OpenZeppelin team directly and are denominated in USD. However, payouts are done in ETH or USDC.

All smart contracts in the “contracts” directory are included in the bug bounty, except those under “contracts/mocks”, which are testing artifacts, and those under “contracts/vendor”.

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
• Impacts on test files and configuration files unless stated otherwise in the bug bounty program

Smart Contracts and Blockchain

• Incorrect data supplied by third party oracles
  • Not to exclude oracle manipulation/flash loan attacks
• Basic economic governance attacks (e.g. 51% attack)
• Susceptibility to block timestamp manipulation
• Lack of liquidity
• Best practice critiques
• Sybil attacks
• ERC mandated behaviors

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• Any testing with pricing oracles or third party smart contracts
• Attempting phishing or other social engineering attacks against our employees and/or customers
• Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
• Any denial of service attacks
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty