> ## Documentation Index > Fetch the complete documentation index at: https://vincent-feature-cpl-357-docs-revamp.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Bug Bounty Program > How to report security vulnerabilities in Lit Chipotle, what is in and out of scope, the rules of engagement, and how rewards work. We pay rewards for security vulnerabilities responsibly disclosed to us. If you find a way to break the security model described in this section — extract keys, forge attestation, bypass the permission model, escape the Lit Actions sandbox — we want to hear about it, and we will pay you for it. This program rewards **demonstrated, exploitable vulnerabilities**. It does not reward theoretical weaknesses, best-practice deviations, scanner output, or speculation. Reports that do not meet the requirements below are closed without triage. ## How to report Email **[security@litprotocol.com](mailto: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](https://github.com/LIT-Protocol/chipotle/security/advisories/new) 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. 1. **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. 2. **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. 3. **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). 4. **Reproduction context.** The commit hash, compose hash, or deployment URL you tested against. Where the issue is reproducible against a [self-hosted deployment](/architecture/self-hosting) in default configuration, say so and include the steps. 5. **One vulnerability per report.** Do not bundle unrelated findings. Do not split one finding into several reports. 6. **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. Reports must be in English and in plain text or Markdown. We do not open attachments other than source files, patches, and HTTP captures. We reply to reports that meet these requirements with an **acknowledgement within 3 business days** and a **triage and severity assessment within 7 business days**. Reports that do not meet them receive a short closure notice or no reply. Follow-up emails asking for status do not change the triage order. ## 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](https://www.first.org/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](#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](https://github.com/LIT-Protocol/chipotle), covering the following components, subject to the exclusions below: * The `lit-api-server`, `lit-actions` runtime, and `lit-static` dashboard. * 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. Before reporting an issue that depends on "what code is running," verify the live state yourself — see [Verify in 30 Seconds](/architecture/verification/quick-verify). ## 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](/architecture/verification/attestation) and [upgrade governance](/architecture/verification/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](https://www.intel.com/content/www/us/en/security-center/default.html), [dstack](https://github.com/Dstack-TEE/dstack), or [Phala](https://docs.phala.com/) 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.). **Out-of-scope assets** * **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. **Low-value findings without demonstrated impact** The following are closed without triage unless the report includes a working PoC that chains them into a concrete compromise of keys, funds, user data, or a security guarantee: * 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. If you are unsure whether something is in scope, email us and ask before you start testing. "Is this in scope?" questions are welcome; speculative reports are not. ## 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](/architecture/self-hosting)) or with trivial value at stake, prefer that. ## Safe harbor We will not pursue legal action against researchers who make a good-faith effort to follow these rules, stay within scope, and report promptly. This safe harbor does not extend to actions that intentionally harm users, destroy data, or violate the rules above.