Skip to main content
search

Leadership Connect Bug Bounty Program

Program Rules

Leadership Connect offers a bounty for reporting certain qualifying security vulnerabilities. Please make sure you review the following program rules before you report a vulnerability. By participating in this program, you agree to be bound by these rules.

Rewards 

  • Leadership Connect may, at its sole discretion, provide rewards to eligible reporters of qualifying vulnerabilities.
  • Issue severity is calculated by an internal risk matrix based on specific data and use cases. Severity is considered a combination of Impact and Likelihood, each assigned a value of Informative, Low, Medium, High, or Critical.
You must comply with all applicable laws in connection with your participation in this program. You are also responsible for any applicable taxes associated with any reward you receive. We may modify the terms of this program or terminate this program at any time. We won’t apply any changes we make to these program terms retroactively.

Rules of Engagement

Performing actions that may negatively affect Leadership Connect users (e.g., spam, denial of service), or sending reports from automated tools without verifying them will immediately disqualify the report and may result in additional steps being taken.

Submission Guidelines

To submit a report, please email bugbounty@leadershipconnect.io  When submitting a vulnerability, we request that you:
  1. Provide detailed steps to reproduce the issue, including any supporting materials.
  2. Avoid publicly disclosing the vulnerability until we have had sufficient time to investigate and address it.
  3. If sending videos, please only send videos via YouTube (Videos should be marked as private).

Report Eligibility

  • You must be the first reporter of the vulnerability
  • The vulnerability must demonstrate security impact to a site or application in scope
  • You must not have compromised the privacy of our users or otherwise violated our terms of service
  • You must not have publicly disclosed the vulnerability prior to the report being closed
  • We must not be legally prohibited from rewarding you

Ineligible Issues

The following issues are outside the scope of our vulnerability rewards program (either ineligible or false positives): 
  • Attacks requiring physical access to a user's device
  • Any physical attacks against Leadership Connect property or data centers
  • Forms missing CSRF tokens (we require evidence of actual CSRF vulnerability)
  • Logout CSRF
  • Password and account recovery policies, such as reset link expiration or password complexity
  • Invalid or missing SPF (Sender Policy Framework) records
  • Content spoofing / text injection
  • Issues related to software or protocols not under X control
  • Reports of SPAM
  • Bypass of URL malware detection
  • Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
  • Social engineering of Leadership Connect staff or contractors
  • Issues without clearly identified security impact, such as clickjacking on a static website, missing security headers, or descriptive error messages
  • Issues that result in Denial of Service (DoS) to X's servers at the network or application layer.
  • Cache poisoning techniques that impact service availability for other users.
  • Reports of broken hyperlinks from  blog posts, press releases, or support articles.
  • Open redirects unless they can demonstrate a higher security risk than phishing.

Report Disclosures

We currently don't disclose reports marked as Informative. Exceptional reports may be considered for disclosure on a case-by-case basis.

Ineligible Findings

When reporting potential vulnerabilities, please consider (1) realistic attack scenarios and (2) the security impact of the behavior. Below, you will find the most common false positives we encounter. The following issues will be closed as invalid except in rare circumstances demonstrating clear security impact. 
  1. Theoretical vulnerabilities that require unlikely user interaction or circumstances. For example: 
    • Vulnerabilities only affecting users of unsupported or end-of-life browsers or operating systems 
    • Broken link hijacking Tabnabbing 
    • Content spoofing and text injection issues 
    • Attacks requiring physical access to a device (unless explicitly in scope) 
    • Self-exploitation, such as self-XSS or self-DoS (unless it can be used to attack a different account) 
  2. Theoretical vulnerabilities that do not demonstrate real-world security impact. For example: 
    • Clickjacking on pages with no sensitive actions 
    • Cross-Site Request Forgery (CSRF) on forms with no sensitive actions (e.g., Logout) 
    • Permissive CORS configurations without demonstrated security impact 
    • Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors) 
    • Comma Separated Values (CSV) injection 
    • Open redirects (unless you can demonstrate additional security impact) 
  3. Optional security hardening steps / Missing best practices. For example: 
    • SSL/TLS Configurations 
    • Lack of SSL Pinning 
    • Lack of jailbreak detection in mobile apps 
    • Cookie handling (e.g., missing HttpOnly/Secure flags) 
    • Content-Security-Policy configuration opinions 
    • Optional email security features (e.g., SPF/DKIM/DMARC configurations) 
    • Most issues related to rate limiting 
  4. Vulnerabilities that may require hazardous testing. This type of testing must never be attempted unless explicitly authorized: 
    • Issues relating to excessive traffic/requests (e.g., DoS, DDoS) 
    • Any other issues where testing may affect the availability of systems 
    • Social engineering attacks (e.g., phishing, opening support requests) 
    • Attacks that are noisy to users or admins (e.g., spamming notifications or forms) 
    • Attacks against physical facilities