By participating in this program, you agree to:

• Respect the Community Code of Conduct;
• Respect the Researcher Terms & Conditions;
• Respect the scope of the program;
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo);

The following are not eligible to participate:

• Current Capital.com employees;
• Employees of partner companies;
• Former Capital.com employees who left the company less than one year ago;

Check our fix
We offer up to €50 bonus to verify a resolved issue for us (when requested).
This remains at the discretion of Capital.com to award.

Any report that can demonstrate security impact to Capital.com assets and domains listed in the program.

Known Issues (date last updated: 02/03/2026)

• YouTube API token
• Ability to enable 2FA w/o email verification

Issues Without Demonstrable Security Impact

• Reports generated solely by automated vulnerability scanners or tools without manual validation, clear reproduction steps, and demonstrated security impact;
• Information disclosure that does not expose sensitive data (e.g., version banners, metadata, directory listings, usernames, debug messages, /metrics, /status, .htaccess files);
• Disclosure of API keys, tokens, or credentials that:
  • Are not sensitive; or
  • Cannot be used to access, modify, or extract sensitive data or functionality;
• Exposure of third-party API keys (including but not limited to Google API keys or monitoring/analytics service keys such as Sentry) where the key is properly restricted or cannot be used to access sensitive data or perform privileged actions. Abuse scenarios limited to generating logs, analytics events, monitoring traffic, or similar activity (e.g., spamming monitoring services) are not considered a security vulnerability;
• Username or email enumeration without account compromise or meaningful abuse;
• CORS misconfiguration on non-sensitive endpoints and/or without a working proof-of-concept demonstrating the ability to access sensitive data, perform authenticated actions, or otherwise exploit the misconfiguration;
• Clickjacking without proof of sensitive action exploitation;
• CSRF without meaningful state-changing impact (including logout CSRF);
• Open redirects without demonstrable token theft or authentication bypass;
• Host header injection without exploitability;
• HTTP request smuggling without demonstrated impact;
• SSRF vulnerabilities that cannot reach internal systems, metadata services, privileged infrastructure, or otherwise demonstrate meaningful security impact;
• Subdomain takeover reports without proof of the ability to successfully claim the subdomain;
• Content injection that does not modify executable HTML/JavaScript or change application behavior;
• Self-XSS or same-site scripting that cannot impact other users;
• Reflected file download attacks without demonstrated security impact;
• Arbitrary file upload without proof of successful upload and accessibility;
• Accessing undocumented or non-UI API endpoints that are part of intended backend functionality without bypassing authentication or authorization controls;
• Scripting or active content embedded in PDF documents unless it results in demonstrated account compromise, data exfiltration, or remote code execution.

Missing Security Best Practices / Hardening Gaps

• Missing security headers (CSP, X-Frame-Options, etc.);
• Missing CSRF tokens;
• Missing security cookie flags;
• Reverse tabnabbing;
• Autocomplete enabled on forms;
• Password complexity, rotation, or reuse policies;
• Rate limiting absence without demonstrated abuse impact;
• WordPress XML-RPC enabled;
• Version disclosure / banner grabbing;
• Reports based solely on the version of a product, library, or protocol (e.g., TLS version) without a working proof-of-concept demonstrating exploitability in the current configuration and measurable security impact;
• Lack of certificate pinning;
• Lack of obfuscation or binary hardening;
• Lack of jailbreak or root detection;
• Lack of anti-debugging protections.

Abuse, Spam, and Resource Exhaustion

• DDoS attacks;
• Brute-force attacks;
• Email bombing;
• Rate-limit bypass without demonstrated account compromise or data exposure;
• Homograph attacks;
• Broken link hijacking (including news or social content);
• Broken or outdated links in public content;

Email & Domain Configuration Issues

• SPF, DKIM, or DMARC misconfiguration;
• Email spoofing scenarios without platform compromise.

Issues Requiring Unrealistic or Compromised Environments

• Attacks requiring physical access to a device;
• Man-in-the-middle attacks;
• Attacks that require prior unauthorized access to a victim account not obtained through a vulnerability in Capital.com systems;
• Attacks that only work on jailbroken or rooted devices;
• Runtime manipulation in modified environments;
• Vulnerabilities requiring unrealistic user interaction, including but not limited to:
• Manual modification of browser or device security settings;
• Copying and executing JavaScript in the browser console;
• Disabling built-in security protections;
• Installing malicious applications or extensions;
• Granting excessive permissions to untrusted software;
• Attacks based on unproven third-party vulnerabilities as a prerequisite.

Mobile-Specific Exclusions

• Clipboard or pasteboard leakage;
• Shared links copied to clipboard;
• URIs viewable by other applications;
• Snapshot/background leakage;
• Sensitive data transmitted over TLS;
• Crashes due to malformed URL schemes;
• Path disclosure within the application binary.

Administrative Limitations

• Issues previously identified internally, already tracked by Capital.com, publicly disclosed, or reported by another researcher are not eligible for bounty;
• Public 0-day or 1-day vulnerabilities may be considered duplicates for several weeks after publication if Capital.com is aware of the vulnerability from open sources and is actively working to remediate or mitigate it;
• Credentials or secrets disclosed through public third-party data breaches or public leaks (e.g., paste sites, breach forums) without demonstrating a vulnerability in Capital.com systems;
• Reports based on privately purchased, traded, or otherwise acquired leaked credentials, tokens, or access. Purchasing or obtaining leaked data from illicit sources is considered a violation of the program’s code of conduct and will be treated as out of scope.

This program generally complies with Intigriti Triage Standards.

CVSS is used to determine vulnerability severity; however, the final bounty amount is determined based on vulnerability type, asset tier, and demonstrated business impact.

The amounts listed in the reward table represent maximum caps per vulnerability category. CVSS score alone does not determine the final payout.

Where can I get credentials for the app?

You can self-register on the application. However, Capital.com cannot provide extra demo credits on these accounts.