[{"id":3772498,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n- We do not consider it a vulnerability when the victim must deliver the attacker's payload themselves (e.g., importing a file, pasting input). This is self-XSS regardless of the resulting impact.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Hardcoded keys, tokens, or debug endpoints extracted from mobile app binaries (APK/IPA) that enable developer tools or internal features, unless chained with a demonstrated cross-user impact that does not require physical device access\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps\n**Note**: Fizzy is not eligible for bounties as it's a free app. \n\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- ONCE Campfire: our open-source, self-hosted group chat system. \n- ONCE Writebook: our open-source, self-hosted book publishing app.  \n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our paid in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-04-11T17:27:45.927Z"},{"id":3771748,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n- We do not consider it a vulnerability when the victim must deliver the attacker's payload themselves (e.g., importing a file, pasting input). This is self-XSS regardless of the resulting impact.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps\n**Note**: Fizzy is not eligible for bounties as it's a free app. \n\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- ONCE Campfire: our open-source, self-hosted group chat system. \n- ONCE Writebook: our open-source, self-hosted book publishing app.  \n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our paid in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-26T19:56:29.093Z"},{"id":3771224,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps\n**Note**: Fizzy is not eligible for bounties as it's a free app. \n\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- ONCE Campfire: our open-source, self-hosted group chat system. \n- ONCE Writebook: our open-source, self-hosted book publishing app.  \n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our paid in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-17T11:14:21.453Z"},{"id":3771214,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps\n**Note**: Fizzy is not eligibile for bounties as it's a free app. \n\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- ONCE Campfire: our open-source, self-hosted group chat system. \n- ONCE Writebook: our open-source, self-hosted book publishing app.  \n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our paid in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-17T09:33:52.676Z"},{"id":3771213,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps\n**Note**: Fizzy is not eligibile for bounties as it's a free app. \n\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our paid in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-17T09:22:49.633Z"},{"id":3770913,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n\n## Fizzy websites and native apps.\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO-based attacks in URLs, IDN homograph attacks, etc. \n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-11T20:43:38.391Z"},{"id":3770912,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\nAccepting an invitation with an email address different from the one the invitation was sent to. \n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n## Fizzy websites and native apps.\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- A board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Mass assignments of time-related fields (`created_at`, `last_active_at`) in cards. This is intentional for the JSON API to support imports and data preservation. \n\n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-11T20:39:16.176Z"},{"id":3770071,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n## Fizzy websites and native apps.\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- In **Fizzy**, board member able to read, edit and publish another member's draft cards. [This is intentional](https://github.com/basecamp/fizzy/pull/2197). \n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-02-23T16:48:11.833Z"},{"id":3770049,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers our staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for an account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n## Fizzy websites and native apps.\n### In scope\n- Web: https://app.fizzy.do\n- Your own Fizzy accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n## Open source\n\n### In scope\n- Fizzy: our open-source Kanban app. Used by the Fizzy SaaS app.\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@37signals.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-02-23T07:32:04.491Z"},{"id":3769409,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\nIn general, vulnerabilities in our open-source projects that don't translate into a vulnerability in our in-scope apps won't be eligible for a bounty. \n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information, but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-02-09T18:01:13.048Z"},{"id":3768871,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n- Accepting an invitation with an email address different from the one the invitation was sent to. \n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-01-28T09:26:39.328Z"},{"id":3758852,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n- Clickjacking / UI redress (overlay or framing tricks)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-07-10T13:05:39.784Z"},{"id":3756630,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We’ll award between 35% and 70% of the original bounty, depending on the impact, and quality of your report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-05-30T15:32:49.657Z"},{"id":3756624,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Bypasses of previously fixed vulnerabilities\nIf you discover a valid bypass of a previously resolved report:\n- We'll award 50% of the original bounty, scaled based on the impact and quality of the new report.\n- The bypass must be a genuine circumvention of the fix, not a minor variation of the original.\n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-05-30T15:08:34.474Z"},{"id":3751224,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-03-05T08:52:32.076Z"},{"id":3748957,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## Note about reports with dumps of leaked credentials\nWe have mechanisms in place to check for leaked passwords on login, and we won't be awarding any bounties for reports with dumps of leaked credentials obtained from [stealer logs](https://www.troyhunt.com/begging-for-bounties-and-more-info-stealer-logs/) or other kind of data breaches. We'll accept other kinds of credential leaks, such as accidental exposure of tokens, administrative passwords or secrets. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-28T18:52:25.395Z"},{"id":3748077,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":["LEAKED_CREDENTIALS"],"scope_exclusions":[],"timestamp":"2025-01-15T09:12:21.976Z"},{"id":3747034,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\nWhere possible, use a `@wearehackerone.com` email address to create accounts and only test against accounts you create. Read the sections below carefully to avoid having your report closed as N/A. \n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery, MFA)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## General eligibility\nThe scope of the bug bounty program is limited to the apps and domains listed [on our scope page](https://hackerone.com/basecamp/policy_scopes?type=team). Valid vulnerabilities on any domain or app not explicitly listed in scope may be accepted but are ineligible for a reward. \nAs a general rule:\n- Reports that do not demonstrate a relevant CVSS impact on any of the apps in scope will be closed as N/A. \n- In cases where multiple reports share _the same root cause_, these will be closed as Duplicate.\n- We will only award and triage reports when the root cause is under our control.\n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Existing sessions not being invalidated when 2FA is enabled\n- Enabling 2FA without verifying email address to prevent someone from signing up\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp. This includes race conditions that lead to bypassing the limits of your current plan\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Any issue in a mobile application that can only be exploited on a rooted or jailbroken device, that depends on debug access being enabled, or that depends on a vulnerability in the operating system\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address or use a `@wearehackerone.com` address. \n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-12-20T19:56:00.342Z"},{"id":3744868,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Basecamp access controls provided by the [Admin Pro Pack](https://3.basecamp-help.com/article/687-admin-pro-pack).\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulnerabilities that presume users on the same account are untrusted. For example, uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, modifying projects and member lists, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-19T17:50:25.793Z"},{"id":3713949,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical or console access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS targeting other users on the same account, e.g. using malformed inputs or crafted file uploads\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-11T16:49:26.581Z"},{"id":3713088,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- DoS vulnerabilities based on lack of pagination or lots of user content slowing response times\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-02-21T21:55:58.950Z"},{"id":3712468,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within the browser's PDF viewer, where the attack surface is locked down (for example, [JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-02-11T12:13:41.265Z"},{"id":3708666,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n- JavaScript code executed from a PDF within Chrome's PDF viewer, where the attack surface is locked down ([JavaScript support in PDF in Chrome's PDF viewer is an intentional feature](https://bugs.chromium.org/p/chromium/issues/detail?id=511295), so so long as it can't be used to mount an attack)\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-12-06T09:34:50.217Z"},{"id":3700644,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts or accessing other customers' accounts and data unless it's completely unintentional and accidental. \n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp/HEY staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n- If you include any secrets or confidential information in your report, partially mask it, as far as possible, so you can still convey the severity of your findings without accidentally leaking information. \n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-30T10:45:30.066Z"},{"id":3666033,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- DoS vulnerabilities based on unlimited password length (hint: the password length is not unlimited)\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-02-02T17:24:16.079Z"},{"id":3658416,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Broken links\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-17T04:14:57.870Z"},{"id":3658074,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com`, `stats.world.hey.com` and `stats.hey.science`.\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-09T13:23:57.665Z"},{"id":3657103,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- Username/email address enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com` and `stats.world.hey.com`\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-08-19T10:33:50.217Z"},{"id":3657084,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- User enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n- Unrestricted file upload without a clear attack scenario or PoC\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com` and `stats.world.hey.com`\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Username/email address enumeration on https://launchpad.37signals.com.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-08-18T20:45:36.470Z"},{"id":3657057,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and publicly share our appreciation.\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n## Our focus is on\n- Strong auth (sign-in, sessions, OAuth, account recovery)\n- Access control (bypasses, faults, CSRF, etc)\n- Injection prevention (SQL, XSS, method args, etc)\n- For HEY only: potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \nConcatenating bugs to increase the attack scenario is encouraged. \n\n## This is out of scope for all our apps\n- Hyperlink injection on emails\n- Rate limiting\n- Best practices concerns (we require evidence of a security vulnerability)\n- Sessions not being invalidated when 2FA is enabled\n- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms\n- Race conditions that don't compromise the security of any user or Basecamp\n- Reports about theoretical damage without a real risk\n- The output of automated scanners without explanation\n- CSRF with no security implications (like Login/logout/unauthenticated CSRF)\n- Missing cookie flags on non-security sensitive cookies\n- Attacks requiring physical access to a user's device\n- Missing security headers not related to a security vulnerability\n- Reports of insecure SSL/TLS ciphers unless you have a working proof of concept\n- Banner grabbing issues to figure out the stack we use or software version disclosure\n- Open ports without a vulnerability\n- Password and account recovery policies, such as reset link expiration or password complexity\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Reports of spam\n- User enumeration\n- Presence of autocomplete attribute on web forms\n- DNSSEC and DANE\n- HSTS or CSP headers\n- Host header injection unless you can show how a third-party can exploit it\n- Reflected File Download (RFD)\n- EXIF information not stripped from uploaded images\n- Existing sessions not being invalidated when 2FA is enabled\n- DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error\n- Using product features like invitation/signup/forgot-password to deliver messages to any email address\n\nThese apply to all our in-scope assets. See each app below for more specific out-of-scope reports. \n\n## Disqualifiers\n- Attempting access to other customers' accounts.\n- Denial of service: disrupting other customers' access to their own accounts.\n- Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n- Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n- Physical intrusion.\n- Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.\n- Leaking, manipulating, or destroying any user data.\n\n## Guidelines\n- All reports **should include** a detailed step-by-step explanation of how to replicate the issue and an attack scenario to demonstrate the risk.\n- Practice responsible disclosure. That's a responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n- If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s task-specific email addresses feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## HEY\n### In scope\n- HEY websites and native apps\n- Web: https://*.hey.com\n- Email: hey.com and custom domains hosted with HEY\n- Your own HEY accounts only\n\n### Out of scope\n- Enabling 2FA without verifying email address to prevent someone from signing up.\n- `stats.hey.com` and `stats.world.hey.com`\n\n## Basecamp websites and native apps.\n### In scope\n- Web: https://3.basecamp.com and https://basecamp.com.\n- API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n- Authentication: https://launchpad.37signals.com.\n- Your own Basecamp accounts only.\n\n### Out of scope\n- Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is in scope for HEY.\n- Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n- Username/email address enumeration on https://launchpad.37signals.com.\n- Enabling 2FA without verifying email addresses to prevent someone from signing up.\n- Password not required to update the existing password or email address, switch to/from Google Sign In, or enable 2FA.\n\n## Open source\n\n### In scope\n- Trix: our rich-text editor. Used in HEY and Basecamp 3.\n- Stimulus: our client-side JavaScript framework. Used in HEY and Basecamp 3.\n- Other first-party open-source projects under the Basecamp org on GitHub.\n\n### Out of scope\n- Editable wiki pages in GitHub in open source projects\n- \"Leak\" of test and fixture data that appears to be personal identifiable information but it's just test data\n\n## Questions?\nThis works because we work together.\nContact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-08-18T15:54:09.123Z"},{"id":3655033,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc). For HEY, we are also interested in potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \n\n**Your focus** is completely up to you.\n\n## HEY\n\n### In scope\n* HEY websites and native apps.\n* Web: https://\\*.hey.com.\n* Email: hey.com and custom domains hosted with HEY.\n* Your own HEY accounts only.\n\n### Out of scope\n* Rate limiting.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n* `stats.hey.com` and `stats.world.hey.com`\n\n## Basecamp\n\n### In scope\n* Basecamp websites and native apps.\n* Web: https://3.basecamp.com and https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Your own Basecamp accounts only.\n\n### Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n\n## Open source\n\n### In scope\n* [Trix](https://github.com/basecamp/trix): our rich-text editor. Used in HEY and Basecamp 3.\n* [Stimulus](https://stimulusjs.org): our client-side JavaScript framework. Used in HEY and Basecamp 3.\n* Other first-party open-source projects under [the Basecamp org on GitHub](https://github.com/basecamp).\n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* Practice responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-16T17:16:17.064Z"},{"id":3652572,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc). For HEY, we are also interested in potential privacy leaks, such as bypasses of our spy pixel blocking features or any other leak enabled by any of the HEY features. \n\n**Your focus** is completely up to you.\n\n## HEY\n\n### In scope\n* HEY websites and native apps.\n* Web: https://\\*.hey.com.\n* Email: hey.com and custom domains hosted with HEY.\n* Your own HEY accounts only.\n\n### Out of scope\n* Rate limiting.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n\n## Basecamp\n\n### In scope\n* Basecamp websites and native apps.\n* Web: https://3.basecamp.com and https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Your own Basecamp accounts only.\n\n### Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n\n## Open source\n\n### In scope\n* [Trix](https://github.com/basecamp/trix): our rich-text editor. Used in HEY and Basecamp 3.\n* [Stimulus](https://stimulusjs.org): our client-side JavaScript framework. Used in HEY and Basecamp 3.\n* Other first-party open-source projects under [the Basecamp org on GitHub](https://github.com/basecamp).\n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* Practice responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-20T20:01:31.919Z"},{"id":3649290,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## HEY\n\n### In scope\n* HEY websites and native apps.\n* Web: https://\\*.hey.com.\n* Email: hey.com and custom domains hosted with HEY.\n* Your own HEY accounts only.\n\n### Out of scope\n* Rate limiting.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n\n## Basecamp\n\n### In scope\n* Basecamp websites and native apps.\n* Web: https://3.basecamp.com and https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Your own Basecamp accounts only.\n\n### Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD).\n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled.\n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up.\n\n## Open source\n\n### In scope\n* [Trix](https://github.com/basecamp/trix): our rich-text editor. Used in HEY and Basecamp 3.\n* [Stimulus](https://stimulusjs.org): our client-side JavaScript framework. Used in HEY and Basecamp 3.\n* Other first-party open-source projects under [the Basecamp org on GitHub](https://github.com/basecamp).\n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* Practice responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs in a timely manner.\n\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-01T18:21:03.974Z"},{"id":3646750,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## In scope\n* HEY and Basecamp web sites, iOS apps, and Android apps.\n* Web: https://\\*.hey.com, https://3.basecamp.com, https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Libraries and frameworks: [Trix](https://github.com/basecamp/trix) and [Stimulus](https://stimulusjs.org).\n* Your own HEY and Basecamp accounts only, please.\n* Responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs immediately.\n\n## Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD). \n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled. \n* EXIF information not stripped from uploaded images.\n* Enabling 2FA without verifying email address to prevent someone from signing up. \n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-12-11T20:15:14.679Z"},{"id":3646725,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## In scope\n* HEY and Basecamp web sites, iOS apps, and Android apps.\n* Web: https://\\*.hey.com, https://3.basecamp.com, https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Libraries and frameworks: [Trix](https://github.com/basecamp/trix) and [Stimulus](https://stimulusjs.org).\n* Your own HEY and Basecamp accounts only, please.\n* Responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs immediately.\n\n## Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD). \n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled. \n* EXIF information not stripped from uploaded images.\n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-12-11T09:18:32.918Z"},{"id":3646621,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## In scope\n* HEY and Basecamp web sites, iOS apps, and Android apps.\n* Web: https://\\*.hey.com, https://3.basecamp.com, https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Libraries and frameworks: [Trix](https://github.com/basecamp/trix) and [Stimulus](https://stimulusjs.org).\n* Your own HEY and Basecamp accounts only, please.\n* Responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs immediately.\n\n## Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD). \n* Username/email address enumeration on https://launchpad.37signals.com.\n* Existing sessions not being invalidated when 2FA is enabled. \n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-12-09T09:58:24.825Z"},{"id":3644224,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## In scope\n* HEY and Basecamp web sites, iOS apps, and Android apps.\n* Web: https://\\*.hey.com, https://3.basecamp.com, https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Libraries and frameworks: [Trix](https://github.com/basecamp/trix) and [Stimulus](https://stimulusjs.org).\n* Your own HEY and Basecamp accounts only, please.\n* Responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs immediately.\n\n## Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD). \n* Username/email address enumeration on https://launchpad.37signals.com.\n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-25T19:14:52.468Z"},{"id":3643710,"new_policy":"**TL;DR** - Your insight and discoveries = our deep \u003c3, and now $.\n\nWe're a small team born and bred on open source, so we look to the security community's lead for exploit patterns, best practices, top vulns, new research—everything. We've learned much and keep adapting. Thank you.\n\nWe push for the best in web security and it's your research that makes the big strides and reveals blind spots. We invite you to pursue and demonstrate your work here. We'll pair closely with you, respond to your findings speedily \u0026 thoroughly, and [publicly share our appreciation](https://hackerone.com/basecamp/thanks).\n\n**Bounties range from USD $100 to $10,000** and scale according to impact and ingenuity, from an unlikely low-sensitivity XSS to a deep, novel RCE. One per bug; first discovery claims it; ties break toward the best report.\n\n**Our focus** is on strong auth (sign-in, sessions, OAuth, account recovery), access control (bypasses, faults, CSRF, etc), and injection prevention (SQL, XSS, method args, etc).\n\n**Your focus** is completely up to you.\n\n## In scope\n* HEY and Basecamp web sites, iOS apps, and Android apps.\n* Web: https://\\*.hey.com, https://3.basecamp.com, https://basecamp.com.\n* API: As described by https://github.com/basecamp/bc3-api and https://github.com/basecamp/api.\n* Authentication: https://launchpad.37signals.com.\n* Libraries and frameworks: [Trix](https://github.com/basecamp/trix) and [Stimulus](https://stimulusjs.org).\n* Your own HEY and Basecamp accounts only, please.\n* Responsible disclosure. That's responsibility to users, not us. We strive to live up to the other end of this by resolving bugs immediately.\n\n## Out of scope\n* Login and logout CSRF.\n* Rate limiting.\n* Email spoofing, including SPF/DKIM/DMARC policies, for Basecamp. Email spoofing is *in* scope for HEY.\n* DNSSEC and DANE.\n* Using product features like invitation/signup/forgot-password to deliver messages to any email address.\n* Vulns that require untrusted users on the same account: uploading malware, embedding phishing URLs in comments, RTLO based attacks in URLs, IDN homograph attacks, etc.\n* Unsupported browsers, rogue extensions, platform vulns.\n* Reflected File Download (RFD). \n\n## Disqualifiers\n* Attempting access to other customers' accounts.\n* Denial of service: disrupting other customers' access to their own accounts.\n* Social engineering of any kind against other customers or Basecamp staff, including spearphishing attempts or contacting our support team.\n* Overwhelming our support team with messages. Don't fuzz Contact Support forms.\n* Physical intrusion.\n* Automated scanning and brute-forcing.\n\n## Guidelines\n* If you sign up for a HEY or Basecamp account for vulnerability testing, please include \"HackerOne\" somewhere in your email address. (For example, you could use Gmail’s [task-specific email addresses](https://support.google.com/a/users/answer/9308648?hl=en) feature.) This helps us filter your account out of business metrics such as conversion rate.\n\n## Questions?\n* This works because we work together.\n* Contact us with any questions: security@basecamp.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-13T13:06:34.950Z"}]