HubSpot

Instructions for creating a HubSpot trial portal:

• Anyone may create a trial portal by navigating to: https://offers.hubspot.com/free-trial. When signing up, please use your @WEAREHACKERONE.COM email address. If you need more than one portal for testing cross portal findings, please create additional trial portals tied to your @WEAREHACKERONE.COM address using email aliases. For example, Portal A - [email protected], Portal B - [email protected], and so on. Testing from portals that aren't tied to a HackerOne address can't be attributed to the program, so traffic will likely be flagged as malicious and the portal may be suspended.
• All available functionality may be tested with the exception of email sends to email addresses you do not own. Please note, sending phishing attacks or spam from a portal will be grounds for permanent disqualification.
• With a trial account, it is possible to create an API key to send API requests. Follow these instructions for creating an API key. API requests should fall within these API usage guidelines.
• Information about HubSpot APIs, including example requests, is available at: https://developers.hubspot.com/docs/api/overview

Beta Features:

We encourage researchers to test and submit any bugs or vulnerabilities you may identify within beta features. To learn more about opting your account into beta features, check out our KB reference here.

Focus Areas

Authentication flows

We highly encourage researchers to test various authentication flows including but not limited to:

• Signup (with email, Google, Apple, Microsoft)
• Login (with email, SSO, Google, Apple, Microsoft)
• MFA
• Account recovery / password reset
• OAuth

Researchers should approach these areas with a creative and critical mindset, exploring potential vulnerabilities that may lead to user account takeover and/or unauthorized access of data. Our goal is to ensure that our authentication mechanisms not only comply with industry standards but also demonstrate strong resilience against emerging threats and sophisticated attack techniques.

High impact findings

Overall, we are most interested in critical vulnerabilities that allow access to customer CRM records and sensitive (PHI and PII) data, HubSpot’s corporate data, and our internal network. We highly encourage researchers to look for:

• Vulnerabilities (like cross-site scripting) that may lead to user account takeover
• Cross-portal data leakage and access; i.e. if you are authenticated and authorized to access portal A, you should not be able to read/modify data in portal B, unless you have also been authorized to that portal
• Server-side code execution vulnerabilities
• Sensitive data exposure

Ratings and Rewards

For the initial prioritization/rating of findings, this program will use the the Common Vulnerability Scoring System (CVSS). However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood and impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher.

To maximize your reward and minimize the payout time frame, please make sure to include the following in your report:

• An attack scenario: Provides context and demonstrates how the vulnerability can be exploited in real-world conditions.
• Clear reproduction steps: Helps ensure that the vulnerability can be consistently and reliably demonstrated.
• Recommended fix: Speeds up the mitigation process and reduces the time that the system remains exposed. Providing a practical solution also showcases the researcher’s understanding of the issue which enhances the credibility of the report.

Critical Severity - Reward Tiers

Every finding that meets the Critical severity bar is assigned to one of the reward tiers below, based on the blast radius and demonstrated impact of the vulnerability. These tiers apply the same impact-and-likelihood logic used in our XSS Severity Guidelines. Tier assignment is based on the impact actually demonstrated in the report; theoretical or unproven escalation is rated on the impact shown. A single root cause is rewarded once.

We reserve the right to grade a finding above or below these tiers at our discretion where we deem it necessary. In any case where we do, a full, detailed explanation will be provided to the researcher. We will otherwise strive to follow these tiers in as many cases as possible, in order to be transparent about how we reward Critical findings.

For Elevated Criticals. Please ensure you do not access or alter internal systems or data belonging to other clients. Use a minimally disruptive proof-of-concept (PoC) to demonstrate the vulnerability. Chained findings. Where a report chains multiple issues to reach Critical impact, the tier reflects the impact of the full chain, not the individual components.

In Scope Features

Customer portal

(1) The customer portal feature is in scope. However, testing on live customer portals is prohibited without explicit customer authorisation. Please set up your own instance in your test HubSpot account. For instructions, navigate to: https://knowledge.hubspot.com/inbox/set-up-a-customer-portal

Customer connected domain

(2) HubSpot Marketing and CMS customers often host content on the HubSpot platform. Customer connected domains are in scope and CNAME'd to a subdomain like:

• groupXX.sites.hscoscdnYY.net, where XX and YY are the numeric identifiers for the content path.

In Scope Vulnerabilities

In general, vulnerabilities thought to be introduced by HubSpot's hosting platform, and therefore may affect multiple HubSpot customers, are in-scope for this program. Please report those here. Vulnerabilities that are not HubSpot-introduced will still be investigated and will be reported to the affected customer, but they are not rewardable.

Cross-site scripting (XSS)

XSS found while authenticated to the app are only eligible for a reward if it executes in the context of hubspot.com. XSS found on default system domains (eg. hs-sites or hubspotpagebuilder) are only eligible for a reward if all of the below criteria are met:

1. XSS also executes on the connected domain
2. The XSS was introduced by HubSpot

We've received XSS submissions on customer sites caused by a vulnerable HubL or JavaScript code written by the customer in the Design Manager. Those are not rewardable.

We will make exceptions to these rules for any XSS submitted with an exploit that shows clear security impact to the HubSpot platform.

XSS Severity Guidelines

The following table outlines the internal guidelines we have established to grade the severity of Cross-Site Scripting (XSS) vulnerabilities submitted to this program. These guidelines apply only to XSS submissions that meet the in-scope eligibility criteria defined above.

We reserve the right to use our discretion to grade above or below these severity levels in cases where we deem it necessary. That said, we will strive to meet these guidelines in as many cases as possible in order to be transparent about how we assess XSS risk on this program.

Subdomain takeovers

HubSpot owns thousands of subdomains. Researchers who submit a valid subdomain takeover will be rewarded at either P2 or P3 level, depending on impact.

Subdomain takeover reports are in scope only if they meet the following criteria:

• You must include proof that the subdomain is owned by HubSpot.
• You must demonstrate proof-of-concept by hosting a simple, nonmalicious html file under the taken-over subdomain.

Insecure direct object references (IDORs)

Cross-portal IDORs or privilege escalation issues that allow unauthorized access to sensitive data, different customer portals, or administrative functions are eligible for rewards and will be prioritized based on their impact.

For same-portal IDORs, the API layer is the relevant enforcement boundary. UI-level restrictions (e.g., a grayed-out button) do not constitute a security control. To be eligible for a reward, a report must demonstrate that the action is not blocked at the backend permission layer and results in meaningful security impact, defined as:

• Unauthorized read access to another user's sensitive data (PII, PHI, financial/billing information, credentials, or records restricted by object-level permissions)
• Unauthorized modification or deletion of another user's data with a meaningful integrity or confidentiality consequence

Reports will be closed as Informational if:

• The behavior is consistent with our backend permission model (e.g., in HubSpot's engagement model, edit access implies delete access by design)
• The owning team confirms the behavior is working as designed
• The low-privileged user holds a scope that legitimately permits the action
• It's a previously accepted and documented risk (e.g., users without User table access can still view a list of users elsewhere in their HubSpot account as documented here)

Note: If modifying another user's settings could result in account takeover, data exposure, or loss of account access, the report may still be eligible.

Higher Priority IDORs (eligible for standard rewards):

• Cross-portal data access or leakage
• Access to sensitive properties or PHI/PII data within the same portal
• Financial, billing, or payment information access within the same portal
• Privilege escalation to Super Admin functions within the same portal
• User account takeover capabilities within the same portal

Lower Priority / Informational IDORs (may be closed without reward):

• Basic CRUD operations on non-sensitive objects within the same portal
• Sharing / permission modifications on non-sensitive content within the same portal
• Feature or setting toggles within the same portal without demonstrated security impact

Note: We reserve the right to mark authorization bypass issues as informational when they involve low-impact administrative functions, even if they represent a technical violation of intended permissions. This allows our team to focus resources on higher-impact security issues while still acknowledging valid findings.

Out Of Scope Vulnerabilities:

The following submission types are excluded from the bounty and therefore not rewardable:

• Reports related to the rate limits applied to an API endpoint
• Login or Forgot Password page brute force
• Denial of service attacks
• Perceived excessive volumes of sent email (e.g., mail flooding)
• Race condition bugs that bypass subscription limits
• Social-engineering of any kind against HubSpot employees or its users
• Vulnerable libraries without a working proof-of-concept
• Clickjacking
• Absent or misconfigured HTTP headers
• Missing best-practice bugs that don't pose a direct/immediate risk to our company or our users (e.g. missing certificate authority authorization)
• XSS that don't execute in the context of *.hubspot.com or customer connected domains, and instead only executes on preview domains like hs-sites.com, hubspotpagebuilder.com, hubspotpreview.com, cdn.hubspot.net, and similar domains. These domains are intentionally designed to host untrusted user-supplied data.

Important Notice:

Participating community members agree that they have appropriate rights for HubSpot to use Community Member Data as contemplated in this Program Policy and such use of Community Member Data by HubSpot will not infringe, misappropriate, or violate a third party's intellectual property rights, or rights of publicity or privacy.