Semrush

#Program Policy Play by the rules. This includes following this policy ("Policy"), HackerOne’s Disclosure Guidelines and any other relevant agreements.

Test only with your own account(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.

Provide us a reasonable amount of time to resolve the issue. We usually set the following terms for fixes: Low impact - 3 months, Medium impact - 1 month, High/Critical impact - up to 2 weeks for a fully functional fix. However, sometimes it could take more time. Please be patient, you will receive updates when, and if, there will be anything to share.

You have to avoid privacy violations, destruction of data, and interruption or degradation of our service. We only accept the latest version of browsers for Google Chrome, Mozilla Firefox, Opera, Safari, and Edge.

While researching, we'd like to ask you to refrain from:

• Denial of service.
• Spamming.
• Social engineering (including phishing) of Semrush staff or contractors.
• Any physical attempts against Semrush property or data centers.

We do not accept the following types of bugs:

• CSRF without clear impact.
• Any issues related to software not under Semrush’s control.
• Spam or Social Engineering techniques, including SPF/DMARC/DKIM issues.
• SSL/TLS best practices that do not contain a fully functional proof of concept.
• Broken links. Except links to social accounts of Semrush employees - ineligible for bounty
• Bugs that do not represent any security risk - these should be reported to [email protected].

The following bugs are unlikely to be eligible for a bounty:

• Missing DNSSEC settings.
• Attacks requiring physical access to a user's device.
• Issues without clearly identified security impact, such as clickjacking on a static website, missing security headers, HTTP methods, cookie flags, or descriptive error messages.
• Brute Force attacks.
• Issues related to Password Policy - strength, length, lockouts.
• Reports relating to the execution of CSV content by a third-party client application due to special treatment of certain characters in the exported CSV. Reflected file download attacks (RFD).
• Tab nabbing and window.opener-related issues
• Vulnerabilities affecting users of outdated browsers, plugins, or platforms.
• Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or JavaScript code to be injected.
• Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e. Self-XSS). IDN homograph attacks.
• Semrush user’s API-keys and credentials found on any third party services.
• Issues found in third party software used by Semrush with the exception of misconfigured 3rd party services.
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case-by-case basis
• Public Zero-day vulnerabilities that have been publicly disclosed for less than 72 hours

#@wearehackerone.com email and custom header Whenever possible, please use your @wearehackerone.com account (this may stop our fraud team from blocking your account and our Security team may set a bonus for a valid and detailed report), and set a header with your HackerOne username in your requests: ==X-hackerone: ==. You can do that with Burp addon or through Match and Replace option:

1. Go to Proxy -> Options -> Match and Replace -> Add
2. Change Type to Request Header
3. As the default text says in Match 'leave blank to add a new header'
4. Put the new header in Replace

#Legal Terms and Safe Harbor In connection with your participation in this program, you agree to comply with Semrush’s Terms of Service ("Terms") and Semrush’s Privacy Policy.

Semrush employees and contractors are not eligible to receive bounties or rewards of any kind.

When conducting vulnerability research according to this Policy, we consider this research conducted under this Policy to be:

• Authorized by Semrush and authorized in view of any applicable anti-hacking laws;
• Authorized in view of relevant anti-circumvention laws; and
• Lawful, helpful to the overall security of the Internet, and conducted in good faith.

Within the framework of the program described in this Policy, we will take reasonable steps not to initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability provided that the researcher fully complies with this Policy, HackerOne’s Disclosure Guidelines and with all applicable laws and regulations.

You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law. This is not a competition, but rather an experimental and discretionary reward program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion. Your testing must not violate any law, or disrupt or compromise any data that is not your own.

If at any time you have concerns or are uncertain whether your security research is consistent with this Policy, please submit a report through one of our Official Channels (HackerOne or via [email protected]) before going any further.

#Rewards When duplicates occur, we award the first report that we can completely reproduce.

We allow our hackers to split the bounty.

Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

We award bounties at the time of validation and will keep you posted as we work to resolve them. Although sometimes it can take more time to investigate the vulnerability severity and the bounty may be paid later.

We will reward reports according to the severity of their impact (calculated with CVSS v3.0 Calculator) on a case-by-case basis as determined by our security team. We may pay more for unique, hard-to-find bugs, or for high-quality reports; we may also pay less for bugs with complex prerequisites that lower the risk of exploitation.

#Disclosure Policy Vulnerabilities must be disclosed only according to HackerOne’s Disclosure Guidelines. Requests for vulnerability disclosure must be submitted via the HackerOne report interface. We will discuss internally if we need to make a limited disclosure. Usually, we make a full disclosure, after redacting sensitive information, therefore if you need to make a limited disclosure for some reasons please drop us a line.

#Report "Scanner output" or scanner-generated reports will not be accepted. Please follow the report template that we provided to minimize the response time and increase your chance to get a worthy reward. If you are going to submit a subdomain takeover report: to make sure that you have a full domain takeover (as h1 recommends) we have to get a screenshot with our domain (for ex. *.semrush.com) and custom HTTP content (for example h1 username) to be sure it's possible.

#Promo-code Since a large part of our product is paid, we give researchers who proved themselves a promo-code for a paid Semrush functionality. If you want to dive deeper into testing our product, write to us in an existing valid report and we will give you a promo-code. To decide whether to issue it or not we will look at the quality of reports you previously sent us. The promo code can not be issued more than once every three months. The final decision on issuing a promo-code rests with the Semrush security team.

#WAF and reactive protection Your requests can be blocked by the WAF solution we use. So if you get error 445, but you feel that you have found a vulnerability and you have serious reasons to believe that the vulnerability really exists - you can write to us about it on the report, we will investigate your case and maybe temporarily add your IP to the white list.

We believe monitoring and protecting processes must not be impacted by bug bounty. Automated security scans and tests may trigger our security systems and result in reactive measures being enforced, e.g. account or IP may be blocked.

#API/API key related bugs When you test requests to API or with API key - be careful - to test auth issues change API key, not cookies.

Please note that API key’s security and confidentiality are the user's responsibility as stated in our Terms.

#Leaked/compromised Employee accounts (Main Scope) If you discover credentials associated with our employee or service accounts that appear to be compromised, please notify us immediately.

Reports will be considered if they meet the following criteria:

• Account Validity: The account must belong to a current and active employee of our company.
• Non-Duplication: The report must involve a unique incident that has not been previously submitted.
• Severity Assessment: Accepted reports will typically be classified with a Low to Medium severity level, based on factors such as account configuration, data accessibility, and the relevant environment.

To assist in our investigation, please provide as much information as possible about the compromised credentials, such as the date of compromise, associated hostname, and any relevant identifiers. If you encounter credentials but are unsure about the severity level or account type, please report the details for our evaluation.

Please be aware of the following restrictions:

• Customer Accounts: Investigating or targeting customer accounts is strictly prohibited.
• Targeting employees: Any kind of direct or indirect communication with our employees is not allowed, in line with the Platform Code Of Conduct.

#Other Semrush Related Asset (Second Scope) Please use this Asset tag for any High and **Critical ** report that does not relate directly to another Semrush asset listed in scope, and is also NOT listed under the "Out of Scope" section. Please note, that Semrush will only accept and review valid high and critical severity reports within that specific scope.