How to report
Email security@litprotocol.com. Please do not open a public GitHub issue for security vulnerabilities. If you prefer, you may instead open a private security advisory on the repository.Report requirements
Every report must include all of the following. Reports missing any item are closed without triage and are not eligible for a reward.- A working proof of concept. A PoC is required, not optional. It must be something we can run or replay ourselves: a script, an HTTP request sequence, a Foundry/Hardhat test, a Lit Action, or exact step-by-step instructions with the actual inputs used. Screenshots or video alone are not a PoC. A description of a vulnerability class (“this endpoint could be vulnerable to X”) is not a PoC.
- Demonstrated security impact against our system. State concretely what an attacker gains: which key, account, funds, or data is compromised, or which guarantee (attestation, permission model, sandbox isolation, governance) is broken. “Could potentially lead to” is not impact.
- The exact target. The endpoint, contract address and function, file and line, or component (API server, Lit Actions runtime, contracts, deployment/CI, governance, attestation/verification flow).
- Reproduction context. The commit hash, compose hash, or deployment URL you tested against. Where the issue is reproducible against a self-hosted deployment in default configuration, say so and include the steps.
- One vulnerability per report. Do not bundle unrelated findings. Do not split one finding into several reports.
- Human-written and human-verified. You must have personally reproduced the issue. Unverified output from automated scanners or AI tools — including reports that cite code paths, endpoints, or behavior that do not exist — is closed immediately. Repeatedly submitting such reports results in a permanent ban from the program.
Rewards
Rewards are paid for valid, previously unknown, demonstrated vulnerabilities, sized by severity and real-world impact. Issues that compromise keys, funds, user data, or the attestation and governance guarantees earn the largest rewards. We determine severity using CVSS as a starting point, adjusted for actual exploitability and impact on the deployed system — we set the severity, not the reporter. Sharing your discovery methodology increases the likelihood of a reward. Include the steps you took to find and investigate the bug, the tools you used, and, if you used AI, the prompts that helped you uncover it. Explain how you personally verified the finding. This context helps us understand and validate your work. Methodology is encouraged, but optional; all report requirements and reward eligibility criteria still apply.- Severity floor. Only findings we assess as Medium or higher are eligible for a reward. Low and Informational findings are not paid, though we will fix them and may credit you.
- Only the first reporter of a given issue is eligible for a reward.
- Duplicates of issues we already know about (internally, from another reporter, or already tracked in this repository’s issues, advisories, or changelog) are not eligible. We will tell you it was a duplicate.
- Findings that reduce to the same root cause are treated as one issue and rewarded once.
- Findings that are only reachable through an out-of-scope precondition (a malicious insider, a compromised governance signer, a compromised user device) are not eligible.
- Rewards are at our sole discretion and require that you followed the rules of engagement below. We may require identity and tax information before paying, and we cannot pay individuals or entities we are legally prohibited from paying.
In scope
The repository in scope is LIT-Protocol/chipotle, covering the following components, subject to the exclusions below:- The
lit-api-server,lit-actionsruntime, andlit-staticdashboard. - Smart contracts in this repository (account/permission model, and the attestation-governance contracts on Base).
- The deployment pipeline and TEE attestation / verification flow.
- The on-chain governance and key-release model.
Out of scope
The following are not eligible for rewards. Reports consisting only of items on this list are closed without a response. Threat-model exclusions- Insider attacks. Attacks that require a malicious Lit employee, a compromised governance signer, or any other privileged insider as a precondition. The threat model for insiders is addressed by attestation and upgrade governance, not by the bounty program.
- Vulnerabilities in the underlying platform — Intel TDX, the dstack OS, or Phala Cloud infrastructure. Report these upstream to Intel, dstack, or Phala respectively — but do tell us if they affect our deployment.
- Third-party dependencies. Report upstream; we track advisories via
deny.toml. “You use version X of library Y, which has CVE Z” is not a finding. A working exploit of that CVE against our deployment is in scope. - Denial of service of any kind — volumetric attacks, resource exhaustion, rate-limit exhaustion, gas griefing without loss of funds — and any report whose proof requires degrading the service for real users.
- Social engineering and phishing of Lit employees, contractors, or users.
- User misconfiguration. Issues caused by a user configuring their setup insecurely — for example, granting overly broad permissions or disabling available security controls — are user error and are not valid bounty reports. The ability to choose an insecure configuration is not itself a vulnerability.
- Physical attacks on data centers, offices, or hardware, including physical side-channel attacks against the TEE hardware itself.
- Self-inflicted issues: self-XSS, attacks requiring a victim’s rooted or malware-compromised device, browser extension, or a victim who pastes attacker code into their own console or signs an arbitrary attacker-supplied transaction.
- Leaked or compromised user credentials and API keys obtained outside our systems (credential stuffing, keys committed to third-party repos, etc.).
- The marketing website (litprotocol.com and other brochure/marketing properties), the blog, the documentation sites, and the status page. These hold no keys and no user data.
- Third-party services we use (GitHub, npm, Stripe, Railway, email providers, analytics) and anything hosted on domains we do not control.
- Testnet deployments and local development builds, except as a reproduction vehicle for an issue that also affects production.
- Missing or misconfigured security headers (CSP, HSTS, X-Frame-Options, etc.), cookie flags, CORS configuration, and clickjacking.
- SPF/DKIM/DMARC configuration, email spoofing, and mail-server settings.
- TLS/SSL cipher-suite, protocol-version, or certificate-configuration preferences.
- Software version disclosure, server banners, stack traces, verbose error messages, and directory listings.
- Missing rate limiting, missing CAPTCHA, account or username enumeration, password-policy and session-timeout opinions, and lack of 2FA options.
- Open redirects, tabnabbing, host-header injection, and content or text injection without a demonstrated exploit.
- CSRF on unauthenticated endpoints, logout, or endpoints with no state-changing effect.
- Public files and metadata (
robots.txt,.well-known, source maps, EXIF data, public API keys that are designed to be public). - Secrets in git history or public repositories that are not valid or grant no access.
- Theoretical race conditions, timing side channels, or cryptographic weaknesses without a working exploit.
- Smart-contract gas optimizations, style, floating pragma, unused variables, missing events, and compiler-version warnings.
- Anything found by an automated scanner, static-analysis tool, or AI tool and submitted without independent human verification and a working PoC.
- Reports whose only evidence is a video, a screenshot, or a link to a third-party writeup.
Rules of engagement
To be eligible for a reward, you must:- Test only against your own accounts and data. Never access, modify, or delete another user’s data or keys. If a vulnerability exposes someone else’s data, stop immediately, capture the minimum evidence needed to demonstrate the issue, and report it.
- Not degrade the service. No DoS, no high-volume automated scanning, no spamming endpoints. Keep testing traffic modest.
- Not pivot. If you gain unexpected access, demonstrate the issue and stop — do not use it to move laterally, persist, or explore further.
- Not publicly disclose the issue before we have released a fix and agreed on a disclosure timeline with you. We work in good faith on coordinated disclosure and will credit you (if you wish) when the fix ships.
- Not extort. Reports conditioned on payment before details are shared, reports that withhold the PoC pending a reward commitment, and reports that threaten disclosure are not eligible and end your participation in the program.
- Not spam. Sending many low-quality reports, resubmitting closed reports without new evidence, or repeatedly requesting status updates results in a ban from the program.
- Use mainnet funds and production accounts at your own risk. Where a vulnerability can be demonstrated against a local deployment (see Self-Hosting) or with trivial value at stake, prefer that.