Vulnerability Rating Criteria

Prepared by HashDit

Bug Bounty Reward / Ratings

Bugcrowd uses a P (severity) system rating, which is a less detailed version of CVSS 3.0 for categorising vulnerability severity levels. We use CVSS 3.0 for our rating.

Please note: this program takes reference from the Bugcrowd Vulnerability Rating Taxonomy for the prioritisation/rating of findings. Prioritisation/ratings may vary from the Bugcrowd Vulnerability Rating Taxonomy.

Proposed Rates Summary (CVSS-aligned)

Vulnerability Classification

P* (Extraordinarily severe)

• Core protocol contracts allow arbitrary withdrawal or unlimited minting of funds

• Remote disclosure of unencrypted private keys / mnemonics / critical multisig keys

• Governance / Owner / Admin role can be hijacked by anyone, allowing control of all funds or upgrade logic

• Critical Merkle / credential / signature proof verification flaws that release funds at scale

P1 (Critical)

• Lending protocol liquidation or collateralisation-ratio flaws that drain user funds or protocol reserves

• Oracle manipulation (including flash-loan price manipulation) leading to liquidations or borrowing exploits

• Reentrancy attacks leading to fund theft (including cross-function / read-only reentrancy)

• LST/LSD mint/burn ratio manipulation or bypass, distorting system collateralisation

• Unauthorised upgrade of critical contracts / proxy implementations

• Governance token voting power manipulation enabling low-cost passage of malicious proposals

• Cross-chain bridge / asset channel double-spend or illegitimate minting

• Transaction-source spoofing or transaction malleability impacting fund safety

P2 (High)

• Interest rate, rewards, debt index, or accrual math errors causing incorrect settlement of protocol or user funds

• Errors in collateral valuation, health factor, or liquidation thresholds (not directly drainable but high-impact)

• Protocol fee or revenue distribution errors causing misallocation

• Misuse or bypass of emergency pause / risk-parameter management roles

• Unauthorised modification of key governance parameters (interest models, collateral factors, etc.)

• Missing or bypassable access control in critical modules (no direct fund drain yet)

• Cross-contract call ordering issues causing exploitable state inconsistencies

P3 (Moderate)

• Non-critical DoS limited to a single market or pool (no impact on overall protocol)

• Governance parameter manipulation constrained by timelocks/multisig (limited impact)

• Front-running / sandwich attacks causing minor user losses with no protocol-side mitigation

• DoS on non-critical oracles or relayers

• Application-layer DoS of the official website or key query services caused by a code-level flaw (e.g. unauthenticated resource exhaustion via a single crafted request, algorithmic complexity issue) — not simple traffic flooding (impacts UX but not fund safety)

P4 (Low)

• Non-critical DoS not affecting fund safety

• Front-end / browser stability or availability issues

• Information disclosure that cannot be leveraged for privilege or fund access

• Non-exploitable code smells / best-practice issues (treated as Informational)

Accepted Scope

Only security issues related to in-scope assets and their components are eligible.

Out of Scope

Only the targets listed in the Scope & Policy are covered by the Bug Bounty Program ("Bounty Scope"). The following items are out of scope:

• Social engineering tactics (e.g. phishing or vishing)

• Physical security vulnerabilities

• Issues affecting third-party systems, services, or applications outside our domain

• Denial-of-service attacks against live production infrastructure (e.g. network/volumetric flooding of RPC nodes, websites, or servers). Protocol- or code-level DoS vulnerabilities remain in scope and are rated per the Vulnerability Classification table above, but must be demonstrated via code review, unit tests, or a forked testnet — actual traffic flooding or attacks against live systems will not be accepted as valid PoCs and may be treated as a violation of the Prohibited Actions section.

• Vulnerabilities that affect only outdated or unpatched devices/browsers

• Known issues / known audit issues

PoC Guidelines

A proof of concept is essential for most submissions — without one, it is often impossible to verify a bug exists or assess its impact. A strong PoC removes ambiguity and speeds up review, response, and payout.

• PoCs must fork mainnet using tools such as Hardhat or Foundry; unit tests are not accepted.

• They should include runnable exploit code (not screenshots), in any framework or language, along with all dependencies, config files, and environment variables needed to run them.

• PoCs should include clear information (e.g. print statements) and code comments detailing each step of the attack, and display relevant information such as funds stolen/frozen.

• Ideally, researchers should also estimate funds at risk — for example, by totalling affected tokens multiplied by the token's price at submission time.

Prohibited Actions

The following actions are prohibited. Violating these rules may lead to temporary or permanent suspension from the Bug Bounty Program, forfeited reports, and/or zero payouts.

• Any testing against mainnet or public testnet contracts

• Whitehacking to rescue user or protocol funds, unless the project has given explicit written consent

• Submission of AI-generated / automated bug reports that lack sufficient evidence proving the vulnerability's root cause and impact

Non-security Issues

Issues that do not require a fix or remediation do not meet the Bug Bounty Program standard and may be marked as invalid.

For issues that do not affect security, please contact the BNB Chain community via Telegram at @bnbchain_official_bot.

SLA Standards

Target timelines

From the time a report enters the workflow for its severity tier, target deadlines are as follows. Unless noted otherwise, "N working days" means business days.

Notes:

• "1 month" for Fix means one calendar month. All other durations in the table are in working days.

• The table reflects target SLAs from the program documentation. Operational execution follows the actual internal process and any written agreements.