Lightspeed Hospitality

Description

Introduction Welcome to Lightspeed Hospitality. Help us fortify and pressure-test the scalable point-of-sale engines, tableside ordering pipelines, guest management systems, and back-office orchestration layers driving hospitality merchants worldwide. The Lightspeed Bug Bounty Program is a cornerstone of our commitment to platform resilience, and we actively value collaboration with the global security research community to harden our ecosystem. This page is designed exclusively for security researchers. For general information regarding our corporate security practices, please visit our Main Security Portal . Public Disclosure Policy This program operates under a strict Coordinated Disclosure model. To protect the transactional integrity of our hospitality venues and guests, you must not discuss, publish, or leak any vulnerabilities (including fully remediated or closed findings) outside of this program without explicit, prior written consent from the Lightspeed Security Team. Failure to comply with these boundaries constitutes a severe policy violation and will result in immediate program disqualification and potential legal escalation. This program adheres fundamentally to Bugcrowd’s Standard Disclosure Terms . Ratings and Rewards Policy For the initial prioritization and rating of findings, this program utilizes the Bugcrowd Vulnerability Rating Taxonomy (VRT) . 💡 Triage Transparency: In certain cases, a vulnerability's priority level may be modified due to its real-world likelihood or unique architectural business impact. In any instance where an issue is downgraded, a full, detailed technical explanation will be provided to the researcher—along with an open opportunity to appeal the ticket and present a technical case for a higher priority level. Testing Rules of Engagement To protect the integrity of our staging infrastructure and avoid accidental IP blocks by our automated defense systems, all testing traffic must be clearly identifiable .

1. Unauthenticated Testing Guardrails Unauthenticated testing must focus on publicly exposed endpoints, login gateways, and public APIs to identify logical flaws, injection vectors, or authentication bypasses. Traffic Attribution (Mandatory): Because these tests are performed without an active user session, researchers must append a custom header to all HTTP traffic containing their unique Bugcrowd identifier (e.g., X-Bugcrowd-Ninja: [Your_Username] ). Infrastructure Exclusions: Generic infrastructure probing, port scanning, banner grabbing, and volume-based network directory brute-forcing are strictly out of scope and will trigger automated blocking.
2. Authenticated Testing Guidance Authenticated testing must focus on deep business logic flaws, multi-tenant boundaries, data isolation, and authorization states within the hospitality management layers. Credentials & Environments: These tests must be performed exclusively using the pre-provisioned testing credentials or designated test store environments provided to you at the bottom of this brief. Accessing, interacting with, or modifying data on any live, operational production customer hospitality venues is strictly prohibited.

Targets

Program Rules Eligibility Internal Personnel: Current employees, contractors, or individuals with a direct professional relationship with our organization are ineligible to participate. Legal Compliance: Researchers must comply with all applicable local, national, and international laws. Non-compliance results in immediate program disqualification. Profile Requirements: Only public, viewable, and verifiable Bugcrowd profiles are eligible for participation and rewards. Platform Channel: All communication and compensation must go directly through Bugcrowd; internal employees cannot bypass this process. Scope & Target Guidance Strict Target Boundaries: Only security vulnerabilities found within explicitly listed domains and applications are in scope. If an asset or subdomain is not listed in the "In-Scope" targets section, do not test it without explicit written permission from the Lightspeed Security team. Data Privacy: Personal Identifiable Information (PII) or system metadata extraction must be limited to the absolute minimum required to prove impact. If sensitive data is accidentally exposed, stop testing immediately, do not download/cache the information, and submit your report right away. Credential Leaks & OSINT: We welcome submissions regarding exposed customer or employee credentials found via legitimate open-source intelligence (OSINT), such as exposed public repositories or open cloud storage buckets. Valid leaks will be triaged case-by-case based on verified business risk. Exclusion: Credentials surfaced via criminal activity (e.g., dark web forum dumps, malware stealer logs) are strictly out of scope and ineligible for rewards. Strictly Enforced Testing Restrictions Environment Separation: Testing must only be conducted against shops you created or via pre-provisioned accounts against the URLs explicitly in scope. Testing against real, live operational venues other than those you control will result in immediate disqualification. Platform Integrity: Make a good faith effort to avoid privacy violations, data destruction, and interruption or degradation of our services. Only interact with accounts you own or have explicit permission from the account holder to test. Account Manipulation Boundaries: Do not create or add unauthorized secondary users outside the provided testing frameworks. Do not attempt password resets, password modifications, or account lockout brute-forcing on profiles you do not control. Violating this rule will result in immediate removal from the program. Prohibited Actions Any testing that impacts the reliability, availability, or operational uptime of our systems. Physical security testing of corporate facilities, data centers, corporate offices, or equipment. Social engineering, phishing, or vishing attacks against employees, merchants, or guests. Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks. Automated Volume Scanning: Aggressive automated scanning is strictly prohibited (we run these tools internally—do not deploy them against our infrastructure). Testing must be manual and targeted. High-volume scanning will trigger automated IP blocks. Corporate Integration Isolation: Do not test third-party services and integrations utilized by clients (e.g., support.vendhq.com ). Vulnerabilities in third-party dependencies must be reported directly to the responsible platform vendor. Negotiation: Do not attempt to negotiate our program rules, severity evaluations, or reward decisions. Reporting & Triage Single Vulnerability Per Report: Submit one vulnerability per report unless multiple bugs must be chained together to demonstrate a functional exploit path. Platform Exclusive: All findings must be submitted exclusively through Bugcrowd to be eligible for validation and rewards. (Out-of-scope assets demonstrably belonging to Lightspeed may be sent to [email protected] for non-reward coordination). Report Minimums: Reports must include a clear description, vulnerable URL, step-by-step reproduction instructions, and an impact analysis. Minimize the inclusion of unmasked PII or system data in your PoC. Awards & Discretion First-to-Report: In the case of duplicate reports, rewards are granted only to the first reproducible submission received. Underlying Root Cause: Multiple vulnerabilities originating from a single underlying systemic issue will receive a single reward tier. No Impact, No Reward: Vulnerabilities that do not represent a clear, actionable security risk to the organization will be closed without bounty. Program Discretion: We reserve the exclusive right to determine eligibility, severity ratings, and final reward amounts. The program rules may be modified or terminated at any time without prior notice. Areas of Particular Interest We prioritize findings that expose severe backend logic flaws, isolation boundary collapses, or direct server-side compromise. Cross-Tenant Access Control & IDORs: Broken Object Level Authorization (BOLA) or privilege escalation flaws that allow a user from one merchant organization to view, modify, or delete data belonging to a completely separate merchant organization. Vertical Privilege Escalation: Bypassing role-based access controls (RBAC) within a venue environment (e.g., a low-level staff/floor account executing unauthorized administrative or management-level backend actions). API Integrity and Endpoint Manipulation (OWASP API Top 10): Exploiting backend web, mobile, and integration APIs through parameter tampering, mass assignment, or manipulating hidden routing paths to alter server-side data models without using the standard user interface. High-Impact Stored XSS: Stored Cross-Site Scripting payloads that execute within administrative, corporate-facing, or back-office dashboards, or payloads capable of worm-like propagation across accounts (excluding known paths listed below). Account Takeover (ATO) Workflows: Critical flaws in authentication, session management, or business logic that result in full account compromise. Known Issues & Conditional Triage Matrix To prevent systemic blind spots in an era of automated scaling and AI fuzzer deployments, we no longer maintain absolute blanket bans on certain vulnerability classes. Instead, we utilize a "Prove the Business Risk" operational model. The following items are considered Known Issues in baseline environments and will be closed as Informational if reported as a theoretical or low-impact finding. However, if a researcher can demonstrate a unique, functional exploit chain that directly bypasses core application security boundaries, they are conditionally eligible for active triage: Rate Limiting & Brute Force: Submissions will only be triaged if missing on critical business-logic pathways resulting in verified fraud or account compromise (e.g., bypassing Multi-Factor Authentication checks, brute-forcing payment checkouts, or execution of high-impact automated account takeover vectors). Generic site-wide page-load rate limiting or standard endpoint brute-forcing remains out of scope. CSV / Formula Injection: Triaged exclusively if a lower-privilege account user can inject malicious payloads into shared enterprise data tables (such as inventory adjustments or menu matrices) that successfully trigger arbitrary command execution upon a manager or admin's local machine during a CSV/Excel export action. Session Persistence & Invalidation: Triaged exclusively if active, authenticated attacker sessions stubbornly persist and fail to terminate across concurrent endpoints following an explicit password modification, account recovery lifecycle event, profile email update, or explicit account logout sequence. File Upload Limitations: Bypassing standard format or extension content restrictions will only be considered valid if the researcher provides a functional proof of concept demonstrating successful remote server-side code execution (RCE), persistent cross-user script execution, or system payload retrieval. Out of Scope Vulnerabilities The following specific vulnerability types, behaviors, and configuration anomalies are explicitly excluded from financial rewards and triage consideration:

1. Controlled Web Vulnerabilities & Known Paths Reflected & Self-XSS: All Reflected XSS, Self-XSS, or XSS requiring local client-side manipulation (e.g., User-Agent header injection). Known Stored XSS Paths: Stored XSS found specifically within the following transactional entities are already known to our security engineering team and are strictly Out of Scope : /customers /Receipt /Stock Cross-Site Request Forgery (CSRF): CSRF on unauthenticated forms, state-less interactions, or actions with low business impact (e.g., Add/Delete from Cart, Wishlist/Favorites modifications, non-severe user preference toggles, and Log-In/Log-Out CSRF). CSRF is only triaged if it directly facilitates a full, unauthorized Account Takeover (ATO) as determined by Vuln Ops. Open Redirects: Standard URL/Open redirection flaws, unless directly chained to validate token or credential exfiltration. Text Injection: Injection of arbitrary text without HTML, JavaScript, or hyperlink execution capabilities (including Same Site Scripting and generic Content Spoofing).
2. Low-Impact Authentication & Enumeration Noise Enumeration: Account, user, or email enumeration via basic brute-force testing or standard login/forgot-password error responses. (Valid user account enumeration not requiring brute-force or side-channel parsing will be considered on a case-by-case basis). Client-Side Auth: Browser autocomplete features, saved password vulnerabilities, or local application credential storage behaviors. Captchas: Weak Captchas or Captcha bypass vulnerabilities. Password Exclusions: Mail bombing or automated notification flooding via the Password Reset / Forgot Password functionality.
3. Environment & Configuration Best Practices DNS/Email Security: Missing or misconfigured SPF, DKIM, or DMARC records. HTTP Headers & Methods: Missing or weak HTTP security headers (e.g., HSTS, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, CSP configurations) or globally enabled HTTP methods (e.g., OPTIONS enabled) that do not directly expose a functional exploit path. Clickjacking: Clickjacking or UI redressing issues that lack a high-severity secondary impact. SSL/TLS Infrastructure: Weak cipher suites, lack of Forward Secrecy, or theoretical flaws (e.g., BEAST, BREACH, POODLE, Heartbleed) without a functional custom PoC proving server compromise. Lack of SSL or Mixed Content on non-sensitive assets. Verbosity & Information Disclosure: Descriptive error pages, stack traces, application errors, HTTP non-200 codes, and standard software banner/fingerprinting disclosures. Public Documentation: Disclosure of standard public-facing files (e.g., robots.txt ). Third-Party Infrastructure: Generic directory structure enumeration (unless revealing exceptionally sensitive information), IIS Tilde File disclosures, SSH Username enumeration, or Wordpress Username enumeration.
4. Logic & Third-Party Limitations Vulnerable Libraries: Use of a known-vulnerable library that leads to a low-impact vulnerability (e.g., an outdated jQuery version leading to low-impact XSS) without a functional, unique exploit chain. Resource Abuse & Over-billing: Over-billing, quota-exhaustion, or service disruption attacks against integrated third-party tracking or service APIs (e.g., Google Maps API, Azure Application Insights). Network & Cache Abuse: HTTP/DNS cache poisoning or External Service Interaction (HTTP) without actionable impact. Advanced Infrastructure Scaling Restrictions: XXE and SSRF attacks that only provide a localhost/internal host port scan or external port scanning are considered low impact and out of scope. Payouts will be reduced by 50% if proof cannot be provided of further exploitation or system file read capabilities. Duplication: Multiple recurrences of the exact same vulnerability across different domains or application layouts. Report Submission Format When reporting vulnerabilities, please use the format below with detailed information and reproducible steps in the Vulnerability Details field: Description Vulnerable URL/Location Steps to Reproduce Likelihood Analysis Impact Analysis Recommendation Other References (Optional) Credentials Pre-provisioned testing accounts are available for retrieval at the bottom of this brief. Safe Harbor When conducting vulnerability research in accordance with this policy, we consider this research to be: Authorized under the Computer Fraud and Abuse Act (CFAA) (and local equivalents); we will not pursue legal action for accidental, good-faith policy deviations. Exempt from DMCA circumvention restrictions on security controls. Lawful , constructive, and conducted in good faith. For scope clarifications prior to testing, please contact [email protected].