Uniswap
Bounty Range
$2,000 - $15,500,000
external program
/opportunities/leaderboard[/welcome](Discover Cantina)
[/login](Log in)[/signup](Sign up)
@uniswap Live
https://x.com/Uniswaphttps://github.com/Uniswaphttps://uniswap.org
Maximum reward
$15,500,000
Severity
Max. Reward
Critical$15,500,000
High$1,000,000
Medium$100,000
Deposit required
$50
Findings submitted
630
Start date
26 Nov 2024
Please sign in as a researcher to join the bounty.
[/login](Log in)
?overviewTab=0&assetGroup=0?overviewTab=1&assetGroup=0
Smart Contract Vulnerabilities
Protocol-level bugs that affect core AMM functionality, liquidity provision, or fee collection
Integration vulnerabilities in hooks, periphery contracts, or external integrations
Economic exploits that enable unfair value extraction or manipulation
Access control issues that bypass intended permissions or restrictions Infrastructure & Deployment Issues
Deployment configuration errors that could be exploited before contracts are properly configured
Upgrade mechanism vulnerabilities (where applicable)
Cross-chain bridge or messaging vulnerabilities affecting Unichain Web Application Vulnerabilities
Transaction manipulation that tricks users into signing malicious transactions
Wallet draining attacks through XSS or other client-side vulnerabilities
Phishing vectors on official domains that could compromise user funds
API vulnerabilities that expose sensitive data or enable unauthorized actions Open Source & Supply Chain Vulnerabilities (Uniswap-owned repos and release pipelines)
Release / CI compromise paths that could publish a malicious build, package, container, or artifact (e.g., tampering with build steps, signing, publishing, or dependencies).
Dependency confusion / namespace takeover risks involving packages used by Uniswap projects (including transitive deps), where exploitability is demonstrated (e.g., realistic install path in CI or consumer environments).
Malicious package injection opportunities (npm/pypi/etc.) via misconfigured publishing, weak provenance, or missing pinning/lockfile controls when you can show impact (what gets executed, where, and who consumes it).
Repository-level compromise primitives (e.g., token leakage, vulnerable GitHub Actions, PR workflow abuse) that could lead to unauthorized code execution in CI, secret exfiltration, artifact tampering, or downstream compromise via released binaries/packages.
Documentation / examples / scripts that meaningfully increase risk (e.g., runnable install scripts, copy-paste snippets) only if there’s a plausible exploit chain (not purely theoretical).
No Unauthorized Testing on Production Environments:
Do not test vulnerabilities on mainnet or public testnet deployments without prior authorization
Instead, use local test environments (e.g., Foundry forks) we can reproduce in a simulated environment
Do not test vulnerabilities against any live hosted service
Instead, show how the issue manifests and provide a proof-of-concept we can validate against an isolated environment
No Public Disclosure Without Consent:
Do not publicly disclose details of any vulnerability before your report has been fully resolved (i.e., after final disposition has been established, the report has been closed, and any associated payout has been confirmed)
You must receive written permission from Uniswap Labs prior to any public disclosure, at this time we do not typically allow public disclosure but please feel free to ask us anyway. No Exploitation or Data Exfiltration:
Do not exploit the vulnerability, rather provide a proof-of-concept with the minimum steps necessary to demonstrate the issue
Do not access private data, engage in social engineering, or disrupt service No Conflict of Interest:
Individuals currently or formerly employed by Uniswap Labs are ineligible
Those who contributed to the development of the affected code are ineligible
Please report vulnerabilities directly through the Spearbit/Cantina platform. Include:
For ALL reports, you must include a functional proof-of-concept demonstrating the vulnerability in realistic conditions. You must also provide a detailed walk-through of the entire attack scenario and all relevant assumptions, preconditions, economic considerations, etc., as well as reproduction steps and an explanation of the impact of the vulnerability.
For smart contract related reports, we strongly recommend writing a Foundry/Forge test suite or script that runs against a fork of a suitable network (e.g. mainnet). This will allow us to rapidly validate your report and determine its severity. You should also include a proposed mitigation where possible. If the exploit is economic in nature, include a clear calculation of the value at risk.
For other types of vulnerabilities, including attacks against web servers or other infrastructure, we recommend providing a minimal attack script written in Typescript or Python. If it is not possible to provide a functional exploit script, your report must outline the vulnerability in sufficient detail to enable our team to confirm its validity. We also encourage you to include a proposed mitigation plan and video demonstration.
Note that failing to provide a functional proof-of-concept greatly increases the probability of your report being rejected.
All submissions are reviewed and assigned for triage based on their scope: issues related to smart contracts and protocol logic are triaged by the Protocols team, and vulnerabilities in web applications and backend systems are triaged by the AppSec team.
Impact Multiplier (60% weight)
Impact Level | Multiplier | Critical | 1.0 | High | 0.7 - 0.9 | Medium | 0.4 - 0.6 | Low | 0.1 - 0.3 |
Impact is determined by:
Likelihood Level | Multiplier | High | 1.0 | Medium | 0.6 - 0.8 | Low | 0.3 - 0.5 |
Key drivers:
Level | Multiplier | Fully weaponized PoC | 1.0 | Working local fork exploit | 0.9 | Partial PoC | 0.7 | Theoretical | 0.4 |
Report Quality Modifier (5%)
Quality | Multiplier | Exceptional | 1.0 | Clear & Complete | 0.9 | Poorly documented | 0.6 |
Critical Impact Examples (Maximum Reward: $15,500,000)
Vulnerability Type | Example Scenario | Why Critical | Theft of Pooled Liquidity | Reentrancy in modifyLiquidity() allows draining all liquidity from a pool during a single transaction | Affects 20%+ of TVL, immediate user fund loss | Accounting Manipulation | Integer overflow in swap calculation lets attackers drain pool reserves | Protocol insolvency, affects all pools | Hook Bypass | Vulnerability allows bypassing before/after hooks on all swaps, enabling unauthorized state changes | Breaks core security assumptions, affects all v4 pools using hooks | Misconfigured Contract Takeover | A misconfigured core protocol component allows taking ownership or DoS | Catastrophic protocol-wide impact | Flash Accounting Bypass | Exploit in flash accounting system allows withdrawing funds without repaying | Direct theft, affects entire protocol TVL |
Vulnerability Type | Example Scenario | Why High | Single Pool Drain | Bug in specific tick math allows draining high-value pools (e.g., WETH/USDC) | 0.5–20% of TVL affected | Oracle Manipulation | Time-weighted average price (TWAP) can be manipulated through specific transaction ordering | Price oracle compromise, affects dependent protocols | Lock Bypassing | Reentrancy mechanism can be bypassed to perform unauthorized nested operations | Security model violation, medium exploitation difficulty | Fee Collection Exploit | Bug allows claiming fees belonging to other LPs in specific conditions | Theft of unclaimed yield |
Vulnerability Type | Example Scenario | Why Medium | Tick Manipulation | Edge case in tick bitmap causes incorrect liquidity allocation or substantially different swap outcomes than expected | Undermines protocol guarantees, impacts only one pool | Rounding Errors | Minor rounding in specific edge cases causes dust-level losses (<$1 per tx) | Minimal economic impact |
Contract Type | Example | Impact | Permit2 | Signature validation bypass allows spending any user's tokens | Affects all users using Permit2 | Universal Router | Command execution bug allows arbitrary calls with user's token approvals | Direct theft from router users |
Contract Type | Example | Impact | NFT Position Manager | Bug allows transferring someone else's liquidity position NFT | Theft of specific positions | Swap Router | Slippage protection can be bypassed, enabling sandwich attacks beyond tolerance | Affects individual swaps |
Vulnerability Type | Example | Why Critical | Wallet Drain via XSS | Stored XSS injects malicious transaction parameters during swapping that appear legitimate so that output tokens are sent to the attacker’s address | Direct fund theft | Transaction Replacement | MITM attack replaces recipient address in swap UI (extension injection explicitly out of scope) | Funds sent to attacker |
Vulnerability Type | Example | Impact | Gas Estimation Exploit | Malicious input causes massive gas estimation, draining ETH through failed transactions | Economic attack on users |
Vulnerability Type | Example | Impact | Reflected XSS | Non-persistent XSS requiring social engineering to exploit | Limited scope, requires user action | General Flaws | Flaws preventing >1,000 users from purchasing/trading | Denial of service |
Infrastructure findings include vulnerabilities affecting Uniswap Labs’ operational environment and supporting systems, including:
Vulnerability Type | Example | Why Critical | CI/CD Pipeline Compromise | Attacker gains control over deployment pipeline (GitHub Actions, artifact registry, NPM) and deploys malicious version of app.uniswap.org | Mass wallet-draining via trusted domain; entire user base affected | Cloud IAM / Secrets Compromise | Access to production IAM roles or secrets (backend signing keys, API tokens, deploy keys) | Modify routing logic, manipulate transactions, inject malicious parameters | DNS Hijack of Official Domain | DNS takeover of app.uniswap.org | Pixel-perfect phishing clone; traffic redirection; direct wallet drain |
Vulnerability Type | Example | Impact | SSRF to Cloud Metadata | SSRF allowing access to AWS IMDS or internal services, demonstrably leveraged for credential retrieval or lateral movement | Privilege escalation, stepping stone to broader compromise | Overly Permissive IAM Policies | Production roles allow unnecessary administrative actions | Viable lateral movement path; potential malicious deployment chain | Production API Exposure Without Auth | Internal/admin APIs accessible without proper auth | Unauthorized routing or operational manipulation |
Vulnerability Type | Example | Impact | Minor Privilege Escalation | Escalation within non-production or low-impact service | Limited blast radius; requires chaining | RCE on Unused Instance/System | Legacy unused instance publicly accessible and vulnerable to RCE via outdated dependency | Code execution on internal system owned by Uniswap |
Vulnerability Type | Example | Why Critical | Bridge Theft | Canonical bridge vulnerability allows withdrawing ETH without L2 burn | Direct theft of bridged assets | Finality Bypass | Fault proof exploit finalizes invalid state roots | Protocol insolvency | Sequencer Bypass | Force inclusion of malicious transactions bypassing sequencer checks | System integrity compromise |
Vulnerability Type | Example | Why High | Temporary Freeze | Bug allows griefing withdrawals during 7-day challenge period | Temporary fund freeze | Incorrect Bond Math | Challenge bonds drained through dispute sequences | Economic attack on validators | Sequencer Bypass | Malicious inclusion bypasses intended checks | System integrity compromise |
Scope
https://docs.uniswap.org/contracts/v3/reference/deployments
Maximum Reward
Scope
https://docs.uniswap.org/contracts/v3/reference/deployments
Maximum Reward
Scope
https://docs.uniswap.org/contracts/v2/reference/smart-contracts/factory
Maximum Reward
V2 is considered highly stable with years of battle-testing and substantial TVL. Rewards are capped lower than v3/v4 due to maturity, but legitimate critical vulnerabilities remain eligible.
Scope
TheCompact.sol – Core attestation and claim system
Compact ERC6909 implementation
Allocation logic
Forced withdrawal mechanisms
Nonce management Maximum Reward
Critical: $2,250,000
High: $500,000
Medium: $100,000
Scope
Only deployed contracts at the deployment addresses specified in the repository README.
Maximum Reward
Scope
Only deployed auction factories as defined in the repository README.
Maximum Reward
The following categories are explicitly out of scope and not eligible for bounty payouts:
Admin Key Compromise Assumptions
Reports that assume admin key compromise are not eligible unless the reported vulnerability directly enables the compromise.
Known MEV Strategies
Sandwich attacks, arbitrage using public infrastructure, or other MEV behaviors that function as intended within public mempools.
Third-Party Protocol Issues
Bugs in external tokens, price oracles, bridges, or other third-party protocols — even if they affect Uniswap users — unless caused directly by Uniswap-controlled code.
Governance Attacks
Attacks requiring >50% voting power or majority governance control.
Economic Attacks Requiring Massive Capital
Scenarios dependent on unrealistic capital requirements (e.g., “buy all ETH to manipulate price”).
Social Engineering
Phishing campaigns, impersonation, or other user-targeted deception (unless the vulnerability exists on an official Uniswap-owned domain).
Testnet-Only Issues
Vulnerabilities that affect testnet deployments only, unless they demonstrably impact mainnet deployments.
Gas Optimization Suggestions
Gas savings or efficiency improvements without demonstrable security impact.
Best Practice Critiques
General design critiques or deviation from best practices without an exploitable vulnerability.
Theoretical Vulnerabilities
Issues with no realistic, practical exploit path.
By submitting your report, you grant Uniswap Labs any and all rights, including intellectual property rights, needed to validate, mitigate, and disclose the vulnerability. All reward decisions, including eligibility for and amounts of the rewards and the manner in which such rewards will be paid, are made at Uniswap Labs’ sole discretion. The terms and conditions of this Program may be altered at any time. If your report comes across as spam or low-effort AI-generated content, your submission fee will not be refunded. That said, we generally refund submission fees for legitimate, non-spam reports.
Strong reports typically include:
Precise impact quantification
(e.g., “Allows stealing up to $X from pool Y”)
Clear, reproducible proof of concept (PoC)
Step-by-step reproduction that works in a realistic environment (e.g., mainnet fork).
Detailed analysis of affected contracts/functions
Clear identification of the vulnerable logic and how it is reached.
Consideration of existing mitigations
Explanation of why current protections do not prevent the exploit.
The following characteristics significantly reduce the likelihood of a payout:
Vague impact descriptions
(e.g., “could drain funds” without quantification or clear mechanics)
Theoretical issues with no exploit path
No demonstrable way to trigger the vulnerability in practice.
Duplicate of known issues
Previously reported, documented, or acknowledged findings.
Out-of-scope concerns
Issues explicitly excluded under the program’s scope or exclusions.
Vulnerabilities are more likely to be rated High Likelihood if they meet most or all of the following:
Vulnerabilities may be rated Medium Likelihood if they involve:
Vulnerabilities are likely to be rated Low Likelihood if they: