Our Commitment to You

• We will acknowledge your report within a reasonable timeframe and keep you informed about its progress.
• We respect Safe Harbor protections for researchers who act in good faith within these guidelines.
• We are happy to answer questions—please use the contact button at the top right of the platform.

Your Commitment to Us

• Provide detailed, well-structured reports with clear impact analysis and reproduction steps.
• Avoid submitting low-quality reports—quality matters more than quantity.
• Do not disclose or discuss vulnerabilities publicly (including Proof-of-Concepts on YouTube, Vimeo, or other platforms) without our explicit consent.
• Do not use automated vulnerability scanners—we only accept manually verified findings.
• Do not exploit vulnerabilities beyond what is necessary to prove impact.

Responsible Testing Guidelines

• Do not disrupt Uphold’s services—Denial of Service (DoS) or any form of service degradation testing is strictly prohibited.
• Do not attempt to brute-force credentials or perform password spraying, credential stuffing, or phishing attacks.
• Do not test against real user accounts—use sandbox accounts for testing.
• Do not access, modify, or delete user data—if unintended access occurs, stop immediately and report the issue.
• Do not attempt social engineering, physical security attacks, or compromise Uphold employees or third-party services.

Issue Reporting Template

A high-quality report must follow this format to ensure effective triage and resolution:

• Title
  Use the format:
  [ASSET] - VULNERABILITY on FIELD/FUNCTION
  Example:
  [api.topperpay.com] - SQL Injection leading to user details exfiltration on getUserDetails
• Impact Analysis
  • Clearly explain why this is a security risk.
  • Describe the business and compliance impact (e.g., data exposure, financial manipulation, account takeover).
  • Include real-world scenarios where this could be exploited at scale.
• Reproduction Steps
  Provide step-by-step instructions on how to reproduce the issue:
  • Describe the environment (e.g., endpoint, affected function, required permissions).
  • Provide exact requests or payloads that demonstrate the vulnerability.
  • Include screenshots, logs, or proof-of-concept (PoC) code to verify impact.
• Suggested Fixes (if applicable)
  • Provide specific technical recommendations on how to mitigate the vulnerability, avoid generic and AI generated solutions.
  • Reference resources or how-tos relevant to the issue.

We invite researchers to help us identify high-impact security vulnerabilities that could affect user security, financial integrity, or the confidentiality of our systems. The following categories are our top priorities:

1 - Bulk Data Exposure

Any method that allows unauthorized access to large volumes of user data is considered critical. This includes:

✔ Personally Identifiable Information (PII) (e.g., names, emails, phone numbers, KYC data).
✔ Transaction history, balances, or account details beyond intended visibility.
✔ API misconfigurations that allow mass data retrieval through enumeration or unauthenticated access.
✔ Improper access controls on dashboards, logs, or internal tools leading to bulk data exposure.

🚫 Out of Scope: Simple email/username enumeration, verbose error messages, or data exposure without a direct impact.

2 - Horizontal Privilege Escalation (Sandbox Only)

Vulnerabilities that allow unauthorized access to another user’s account, data, or transactions are critical security concerns. This includes:
✔ Viewing another user’s personal details, transaction history, balances, or payment methods.
✔ Modifying another user’s account settings, stored assets, or performing actions on their behalf.
✔ Gaining unauthorized access to restricted admin or privileged functions.

⚠️ IMPORTANT: Horizontal privilege escalation testing is only allowed in the Sandbox environment.Unauthorized access to real user accounts in production is strictly prohibited.

3 - Trading & Balance Manipulation

Our financial systems must maintain transaction integrity. We are interested in any method that artificially alters balances or transactions. Key concerns include:
✔ Artificially inflating wallet balances (e.g., receiving more funds than transferred).
✔ Duplicating transactions or executing unintended reversals.
✔ Altering exchange rates to gain an unfair advantage (e.g., slippage manipulation, front-running attacks).
✔ Bypassing deposit, withdrawal, or transaction limits.
✔ Any issue affecting Uphold’s balance sheet, reserves, or trade settlement process.

🚫 Out of Scope: Minor rounding errors, delayed balance updates without financial impact, speculative scenarios without a reproducible exploit.

Our ‘Unicorn’ Bounty Bonus Program

Uphold is committed to fairly compensating security researchers for high-impact discoveries.

For severe vulnerabilities that could result in major financial, operational, or reputational damage, we may offer a discretionary bonus of up to €25,000. Rewards are assessed based on the Severity assessment chapter metrics explained below. Multi-step attacks combining multiple vulnerabilities may qualify for higher payouts.

Disclaimer

Please note that we are unable to issue rewards to jurisdictions where the Uphold platform is not generally made available to users. A list of unsupported jurisdictions is available here.

Out of scope details

Third Parties

Third-party services are out of scope unless an issue is caused by an explicit misconfiguration by Uphold. This includes:

• Credential disclosures or leaks on third-party services (e.g., VirusTotal, Pastebin, GitHub, public repositories) that are not under Uphold’s control.
• Exposed API keys, OAuth credentials, or Client IDs on external platforms that do not lead to unauthorized access to Uphold systems.

Application

• API key disclosure without proven business impact.
• WordPress username disclosure.
• Pre-auth account takeover / OAuth squatting.
• Self-XSS that cannot be used to exploit other users.
• Verbose messages, files, or directory listings without exposing sensitive information.
• CORS misconfiguration on non-sensitive endpoints.
• Missing cookie flags or security headers.
• Cross-site request forgery (CSRF) with no or low impact.
• Presence of the autocomplete attribute on web forms.
• Reverse tabnabbing.
• Bypassing rate limits or reporting non-existent rate limits.
• Best practice violations (e.g., weak password complexity, expiration, or reuse).
• Clickjacking without proven impact or requiring unrealistic user interaction.
• CSV injection.
• Sessions not being invalidated (logout, enabling 2FA, etc.).
• Tokens leaked to third parties (e.g., referrer headers) without proven security risk.
• Issues related to email spoofing, SPF, DMARC, or DKIM misconfigurations.
• Content injection without the ability to modify HTML or execute scripts.
• Username/email enumeration.
• Email bombing.
• HTTP request smuggling without proven impact.
• Homograph attacks.
• XMLRPC enabled.
• Banner grabbing/version disclosure.
• Not stripping metadata from files.
• Same-site scripting.
• Subdomain takeover without taking over the subdomain or exploiting it.
• Arbitrary file upload without proof of execution or access.
• Blind SSRF without proven business impact (e.g., pingbacks are insufficient).
• Disclosed/misconfigured Google Maps API keys.
• Host header injection without proven business impact.
• Creating apps in the sandbox environment is allowed. However, if this is possible in production, it is considered a valid issue.

General

• Previously known vulnerabilities reported through internal testing will be flagged as duplicates.
• Theoretical security issues without a realistic exploit scenario.
• Spam, social engineering, and physical intrusion.
• DoS, DDoS attacks, or brute-force attacks.
• Vulnerabilities affecting outdated software that is no longer supported.
• Broken links in blog posts or outdated content that Uphold does not control.
• Attacks requiring physical access to a victim’s device (e.g., MitM, compromised accounts).
• Recently disclosed zero-day vulnerabilities in third-party software within 14 days of a patch release are generally not eligible for rewards.
• Reports stating that software is outdated or vulnerable without a proof-of-concept (PoC).

AWS Specific

• Publicly readable S3 buckets – Some of Uphold’s S3 buckets are intentionally public for caching static content.
• Exceptions: If the S3 bucket contains personal data, private company files, or sensitive credentials, please report it.

Mobile

• Shared links leaked via the system clipboard.
• URIs leaked because a malicious app has permissions to view opened URIs.
• Lack of certificate pinning.
• Sensitive data in URLs/request bodies when protected by TLS.
• Lack of obfuscation.
• Path disclosure in binaries.
• Self-XSS that cannot be used to exploit other users.
• Lack of jailbreak & root detection.
• Crashes due to malformed URL schemes.
• Lack of binary protection (anti-debugging, SSL pinning, etc.).
• Snapshot/Pasteboard leakage.
• Exploits only possible in a jailbroken/rooted environment.
• API key leakage used for non-sensitive actions.
• Attacks requiring physical access to a victim’s device.
• Attacks requiring the installation of malicious applications onto a victim’s device.
• Attacks exploiting OS vulnerabilities (e.g., an attack specific to a certain Android/iOS version).

Known Issues

These issues were previously accepted but have been reported multiple times and are now considered duplicates. Future submissions of these issues will likely be marked as duplicate unless new impactful variations are demonstrated.

GraphQL Issues

• GraphQL Batching attacks leading to DoS (Multiple reports across api.uphold.com and graphql.topperpay.com)
• GraphQL Field Duplication attacks leading to DoS (Reported across different assets but already known and addressed)

Cache Poisoning & Web Exploits

• Cache Poisoning (CPDoS) using X headers (Multiple reports affecting www.uphold.com/* and portal.enterprise.uphold.com)

Authentication & Account Security

• Lack of rate limit on OTP passwordless login (Duplicate across multiple reports, already mitigated)

Information Disclosure

• Transaction details disclosure without proven impact (Accepted once, then duplicated in later submissions)
• Private IP disclosure without proven impact (Multiple duplicate reports found)
• Sensitive Token in URL without proven impact (Duplicate reports received)

API Keys, Client Credentials & Cloud Services

• Firebase details exposed but no proven impact (Reported across multiple assets, marked duplicate after initial acceptance).
• API keys leaked on JS files without proven impact (Duplicate reports across cdn.uphold.com, blog.uphold.com, and wallet.uphold.com).
• Client credentials disclosure in third-party repositories or search engines (e.g., VirusTotal, Pastebin, GitHub) that are not under Uphold’s control.
• OAuth Client IDs exposed without associated secrets (Duplicate reports where no authentication risk was found).

This list is continuously updated to avoid unnecessary duplicates in the future and foster a better relationship with security researchers and ethical hackers. We appreciate your contributions in making our platform more secure and encourage meaningful, high-impact submissions.

Uphold follows an impact-driven approach to vulnerability classification, ensuring consistent and fair evaluation of security reports. The severity of a vulnerability is determined by:

1. Intigriti's triage standards – Used as a baseline for technical risk assessment.
2. Tier Matrix – The affected system’s criticality within Uphold’s architecture.
3. Business Risk – The financial, operational, or reputational impact on Uphold and its users.
4. Compliance Implications – Whether the vulnerability could lead to regulatory or legal consequences (e.g., GDPR, financial compliance issues).

Final severity classification and reward determination (bonus) are made at Uphold’s discretion. For vulnerabilities that require multiple chained exploits to achieve a significant impact, the report will be assessed holistically, and severity may be adjusted accordingly.

1. Can I create sandbox accounts for testing?

Yes, researchers can request sandbox accounts for each application. Contact security@uphold.com to request one and explain the scenarios you are trying to test alongside with your @intigriti.me address.

2. How long does it take to review my report?

We aim to acknowledge reports within 48 hours. Triage and validation typically take up to 10 business days.
Resolution time depends on the severity, complexity of the vulnerability and the number of internal teams to talk to.

3. Can I publicly disclose a vulnerability I found?

No. Public disclosure is only permitted after receiving explicit written approval from the Uphold security team. Unauthorized disclosure may result in disqualification from the program.

4. Can I use automated vulnerability scanners?

No. Automated vulnerability scanning is prohibited in production environments to prevent service disruptions.

5. Are social engineering or phishing attacks allowed?

No. Social engineering, phishing, and other attacks targeting Uphold employees, users, or third-party providers are strictly prohibited.

6. Can I test against Uphold’s production systems?

You may test low-impact vulnerabilities in production to confirm the proof-of-concepts created in sandbox, but all high-risk testing (e.g., privilege escalation, authentication bypass) must be conducted in the sandbox and communicated to the Uphold team.

7. What happens if my report is a duplicate?

If the issue was previously reported, your report will be marked as a duplicate, the previous and no reward will be issued.
Before submitting, check our known issues list in the out-of-scope section to avoid submitting duplicates.

8. What should I do if I accidentally access sensitive data?

Stop all testing immediately.
Do not store, share, or modify the data.
Report the issue immediately via Intigriti.

9. Will I receive a reward for all valid reports?

Only vulnerabilities with demonstrable security impact are eligible for rewards. Best-practice violations, low-risk bugs, and issues that cannot be exploited will not be rewarded.

10. What should I include in my report?

A high-quality report should contain:

• Clear title with [ASSET] - VULNERABILITY on FIELD/FUNCTION template. ([api.topperpay.com] - SQLInjection leading to user details exfiltration on getUserDetails)
• Clear impact analysis – Why is this a security risk and what is the business/compliance impact?
• Step-by-step reproduction steps – Detailed instructions with screenshots, logs, or proof-of-concept code.
• Suggested fixes (if possible).