We offer rewards for qualifying security vulnerabilities in Tuple. Testing requires approved staging access.

Before you test

Test only in staging, including when using the native clients or CLI. Request access through this BugBop program and tell us what you’d like to test. Wait for BugBop approval plus the acceptance/setup message confirming your approved testing plan before testing. Together, approval and that message constitute explicit staging authorization for the approved plan; no separate staging application or approval is required.

Read this BugBop program’s scope, exclusions, known issues, research guidelines, and disclosure rules below. Request access through this program.

Reporting a vulnerability

Submit vulnerability reports privately through this BugBop program using Report Bug, with:

• The affected app or service, including the app version and operating system.
• Clear steps to reproduce the issue and a working proof of concept where possible.
• What happened, what you expected, and how the issue could affect security.
• Supporting screenshots or logs, with credentials and personal data removed.

We’ll review your report, respond in a timely manner, and work to fix confirmed vulnerabilities promptly.

Testing scope

In scope:

• staging.tuple.app: the staging website and API.
• Tuple’s native clients: macOS, Windows, and Linux. Testing a client requires the corresponding platform.
• Tuple CLI.

Qualifying vulnerabilities substantially affect the confidentiality or integrity of user data or compromise our systems. Examples include authentication and authorization flaws, permission bypasses, remote code execution, SQL injection, XML external entity attacks, cross-site scripting, cross-site request forgery, and mixed-content scripts. Serious, exploitable vulnerabilities in dependencies used by an in-scope product may also qualify.

Excluded systems and code

Do not test production systems. This includes the web app and API at production.tuple.app and the marketing site at tuple.app. Reports from these systems are not eligible for a bounty. Using accounts you own does not make production testing authorized.

Accessory and optional add-on code is out of scope, including the community-triggers repository and user-installed trigger scripts. A flaw in an in-scope client or API can still qualify if you discover it through a trigger; the exclusion applies to the accessory code itself.

Discontinued software and related artifacts, including the legacy Linux client, are also out of scope.

Excluded findings

Out of scope:

• SPF/DMARC policies, and password, email, or account policies such as email verification, reset-link expiration, or password complexity.
• Logout CSRF, autocomplete on web forms, and missing flags on non-sensitive cookies.
• Attacks requiring physical access, a rooted mobile device, an overlay tool such as tapjacking, or a victim installing non-standard software or otherwise taking steps to make themselves susceptible.
• Vulnerabilities affecting outdated browsers or platforms, and XSS on sites outside the listed scope.
• Social engineering of employees or contractors, and physical attacks against our property or data centers.

For findings that are otherwise in scope, the following require a reproducible exploit with demonstrated security impact. Configuration values, scanner results, and hypothetical attacks alone are insufficient:

• A known-vulnerable library, missing security best practices, or insecure SSL/TLS ciphers.
• Missing security headers or CSRF tokens. For missing CSRF tokens, show a sensitive action that isn’t protected.
• Host-header injection, including spoofing of X-Forwarded-Host or similar headers.
• Findings from automated tools or scans that haven’t been manually validated.
• Exposed banners or version information, unless the version is vulnerable.

Known issues

Reports in these categories are out of scope, including new instances:

• Account or username enumeration.
• Missing SPF, DMARC, CAA, DNSSEC, content security policy, permissions-policy, subresource integrity, or cache-control headers.
• Automatic login after a password change or email verification; no password validation before creating a session on email confirmation.
• Missing two-factor authentication, notifications about password or 2FA changes, or information about security events and sessions.
• Weak password policies, no lockout after failed login attempts, and missing CAPTCHA.
• Missing rate limits, including for actions that send email; IP-based rate limits that can be bypassed by cycling IP addresses.
• Denial of service and missing API-level length limits on some requests or attributes.
• Email-change verification tokens remaining valid after a password change; password-reset tokens remaining valid after use.
• Acceptance of disposable or consumer email addresses, including Gmail and Yahoo.
• Sessions remaining active after an email change; native app sessions remaining active after a password or email change.
• Path disclosure.
• Some paid features being accessible to unpaid users.
• Emailed invitations remaining redeemable after an email change.
• CSRF or replay attacks in identity-provider-initiated SAML sign-in.

Award eligibility

Impact examples: Systemic compromise, such as remote code execution, vertical authentication bypass, or XXE/SQL injection with significant impact. Full access to another user’s private data, such as IDOR, stored XSS, or CSRF with significant impact; internal SSRF or lateral authentication bypass. Limited access to another user’s private data, such as IDOR, reflected XSS, or CSRF with impact. Configuration issues and other vulnerabilities with limited impact, such as limited-impact XSS/CSRF.

Awards are discretionary. Reports must come from approved testing of in-scope systems, demonstrate a security impact, and be reproducible by our engineers. Only the first clear, reproducible report of a vulnerability is eligible.

Award amounts depend on impact and report quality. We may pay more for particularly clever or high-impact findings, or less for issues that require unusual user interaction. We may count one report as several bugs, or several closely related reports as one bug.

You are responsible for applicable taxes, transaction fees, and other withholdings. We can’t award people we’re prohibited by law from paying. We may change the terms or end this program at any time.

Research guidelines

Follow this policy and other relevant agreements, including our Terms of Service:

• Test only in-scope systems. Use accounts you own, or accounts whose owners have explicitly permitted you to use them.
• Report vulnerabilities promptly and keep reports clear and concise.
• Don’t disrupt service, destroy data, violate anyone’s privacy, or harm other users’ experience.
• Don’t view, alter, copy, store, transfer, or otherwise access our data or other users’ data without explicit permission. If you unexpectedly gain access to personal, health, payment, or proprietary data, stop testing and report it immediately.
• Don’t use social engineering, phishing, physical attacks, or extortion.
• Discuss vulnerability details with us in the BugBop report’s comment thread, and follow the disclosure policy below.

Disclosure

Get our explicit permission before sharing vulnerability details with anyone else. Submitting a report or waiting for a fix does not grant permission to publish it.

Safe harbor

When you conduct research in accordance with this policy:

• We consider it authorized under applicable anti-hacking laws. We won’t initiate or support legal action against you for accidental, good-faith violations of this policy.
• We consider it authorized under relevant anti-circumvention laws and won’t bring a claim against you for circumventing technology controls.
• We waive restrictions in our Terms of Service that would interfere with this research, solely for the purpose of research under this policy.
• We consider the research lawful, helpful to Internet security, and conducted in good faith.

You must still comply with applicable laws. If a third party takes legal action against you and you’ve complied with this policy, we’ll take steps to make that compliance known.

If you’re unsure whether your research follows this policy, stop testing until Tuple clarifies. Use an existing BugBop report’s comment thread for report-related questions. Include setup and scope questions in your BugBop access request; a separate pre-report messaging channel has not been verified.