Raccoon Labs looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe. We'll try to keep you informed about our progress throughout the process.
Disclosure Policy
Please do not discuss any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
Program Rules
Reporting Guidelines
- Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
- When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug.
- For vulnerabilities involving personally identifiable information, please explain the kind of PII you believe is exposed and limit the amount of PII data included in your submissions.
Research Guidelines
- Do not impact production systems in a negative way for any testing
- All smart contract testing should be done with a forked local copy of mainnet
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact
- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced)
- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty
- Social engineering (e.g. phishing, vishing, smishing) is prohibited
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service
- Only interact with accounts you own or with explicit permission of the account holder
- Avoid using web application scanners for automatic vulnerability searching which generates massive traffic
- Make every effort not to damage or restrict the availability of products, services, or infrastructure
- Avoid compromising any personal data, interruption, or degradation of any service
- Don’t access or modify other user data, localize all tests to your accounts
- Perform testing only within the scope
- Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
- Don’t spam forms or account creation flows using automated scanners
- In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
- Don’t break any law and stay in the defined scope
- Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
- Please limit your requests to 5 requests per second.
- Please do not blast the support centre tickets with too many requests.
Rewards
Eligibility Criteria
You may be eligible to receive a monetary reward if:
- You are the first person to submit a site or product vulnerability
- That vulnerability is determined to be a valid security issue by our security team
- You have complied with all Program Rules stated above
All bounty amounts will be determined at the discretion of our Bug Bounty team who will evaluate each report for severity, impact, and quality. Rewards amounts vary depending upon the severity of the vulnerability reported. There could be submissions that we determine have an acceptable level of risk such that we do not make changes.
The minimum bounty amount for a validated bug submission is 50 USDC and the maximum bounty amount is based on the severity levels outlined below. Our Bug Bounty team retains the right to determine if the bug submitted to the Bug Bounty Program is eligible. All determinations as to the amount of a bounty made by the Bug Bounty team are final.
Impact-based rewards are our reward strategy. Thus, for example, we will offer a relatively high reward for a vulnerability that may leak sensitive user data, but very little to no reward for a vulnerability that might allow an attacker to deface a microsite. Our reward meetings have always included one question: If someone uses this in a malicious manner, how bad will it be? We assume the worst and pay out the bug accordingly.
In the event that we receive several reports for the same issue, we award the bounty to the earliest report with sufficient actionable information. We don't want to encourage people to spam us with vague issues in an effort to be first.
In the case where a single fix fixes multiple vulnerabilities, we treat it as a single vulnerability. As an example, if you find three vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, you will receive a single bounty, as always determined by impact.
The payout ranges on this page are guidelines for expressing roughly how we think about the severity of different types of issues. These are not exact rules. Depending on their severity, bugs may have different attributes, which can affect payouts.
Again, all reward amounts are at our discretion, but we strive to be fair. Some researchers will disagree with some of our decisions, but we pay out according to our ethical obligations and trust that most will consider their rewards fair and in many cases generous. The program will be tailored as it continues.
We try our best to cycle bounty payouts on Fridays.
| Severity | Bounty Range |
|---|---|
| Critical | $3,000 - $30,000 |
| High | $1,500 - $3,000 |
| Medium | $300 - $1,500 |
| Low | $50 - $300 |
Scope
| Asset Name | Severity |
|---|---|
| *.jup.ag | Critical |
| *.meteora.ag | Critical |
| Jupiter Android App | Critical |
| Jupiter iOS App | Critical |
Out of Scope Vulnerabilities
The following issues are excluded from the bounty program due to their low security impact, malicious nature, or redundancy. Reports containing these will be marked as invalid.
Web - Out of Scope
- Descriptive error messages (e.g. stack traces, application/server errors)
- Host header issues without a working proof-of-concept
- Leakage of non-sensitive query parameters to trusted third parties
- Open redirects without severe impact (e.g. stealing authorization tokens)
- Login panels accessible without evidence of exploitation
- Reports of outdated/vulnerable software without a working PoC
- Broken links or public file/directory listings (e.g. robots.txt)
- Fingerprinting, banner disclosure, or software version disclosure
- Clickjacking/tapjacking on pages with no sensitive actions
- CSV injection without demonstrating a vulnerability
- CSRF on unauthenticated or non-sensitive forms
- Login & Logout CSRF
- Autocomplete/password saving functionality
- Lack of Secure/HTTPOnly flags on non-sensitive cookies
- Brute force/account lockout not enforced on login/forgot password pages
- Content injection issues without security impact
- Content spoofing/text injection without attack vector or ability to modify HTML/CSS
- Self-XSS (including requiring user to paste JS in console)
- Reflected File Download (RFD)
- XSS issues affecting only outdated browsers
- Flash-based XSS (XSF)
- Best practices concerns or missing best practices in SSL/TLS/Content Security Policy/email
- window.opener related issues
- Reports from automated tools or scans
- Spam vulnerabilities, mail spoofing, mail bomb, etc.
- Use of known-vulnerable library/component without PoC
- Clickjacking on pages with no sensitive actions
- Attacks requiring MITM or physical access to a user's device
- Any activity that could lead to service disruption (DoS)
- Rate limiting/brute-force issues on non-authentication endpoints
- Vulnerabilities only affecting outdated/unpatched browsers
- Public zero-day vulnerabilities patched less than 1 month ago (case by case)
- Tabnabbing
- Issues requiring unlikely user interaction
- Vulnerabilities already known (e.g. discovered by internal team)
- Best practice reports (not eligible for bounties but appreciated)
- Reports bypassing rate limiting via IP/device changes
- Address bar/URL/domain spoofing in dApp browser
- Sensitive data exposure on social media accounts
- Internal domain takeovers not related to inscope domains
- Vulnerabilities within performance testing, unit test, or staging environments
- Physical or social engineering attempts (including phishing attacks against employees)
- Microsites with little to no user data
Mobile - Out of Scope
- Attacks requiring physical access to a user's device
- Vulnerabilities that require root/jailbreak
- Vulnerabilities requiring extensive user interaction
- Exposure of non-sensitive data on the device
- Reports from static analysis of the binary without PoC impacting business logic
- Lack of obfuscation/binary protection/root (jailbreak) detection
- Bypass certificate pinning on rooted devices
- Lack of exploit mitigations (e.g. PIE, ARC, Stack Canaries)
- Sensitive data in URLs/request bodies when protected by TLS
- Path disclosure in binary
- OAuth & app secret hard-coded/recoverable in IPA, APK
- Sensitive information retained as plaintext in device memory
- Crashes due to malformed URL schemes or intents sent to exported Activity/Service/Broadcast Receiver
- Any kind of sensitive data stored in-app private directory
- Runtime hacking exploits using tools like Frida/Appmon (only possible in jailbroken environment)
- Shared links leaked through the system clipboard
- Any URIs leaked because a malicious app has permission to view URIs opened
- Exposure of API keys with no security impact (e.g. Google Maps API keys)
- Address bar/URL/domain spoofing in dApp browser
- Reports with mobile versions not downloaded from official sites listed in scope
Known Issues
Please note that the Raccoons Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates. We seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made.
FAQ
How do I submit a vulnerability?
Use our secure submission form to report vulnerabilities...
When can I expect a response?
We aim to acknowledge receipt of your report within 24-48 hours and provide an initial assessment within 5 business days.
How are bounties determined?
Bounties are determined based on the severity and impact of the vulnerability. Our security team evaluates each report individually, considering factors like exploitability, affected users, and potential business impact.
Can I disclose the vulnerability after it's fixed?
We ask that you coordinate disclosure with our security team. Generally, we're open to public disclosure after the vulnerability has been fixed and our users have had sufficient time to update.
Ready to Submit?
Help us improve our security and earn rewards.