Fivetran

Description

Fivetran, the global leader in data movement, helps customers use their data to power everything from AI applications and ML models, to predictive analytics and operational workloads. The Fivetran platform reliably and securely centralizes and transforms data from hundreds of SaaS applications and databases into any cloud destination — whether deployed on-premises, in the cloud or in a hybrid environment. Thousands of global brands, including Autodesk, Condé Nast, JetBlue and Morgan Stanley, trust Fivetran to move their most valuable data assets to fuel analytics, drive operational efficiencies and power innovation. No technology is perfect and Fivetran believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. We are excited for you to participate as a security researcher to help us identify vulnerabilities in our assets. Good luck, and happy hunting! How we rate and pay for bugs We use the Bugcrowd bug rating guide to decide how serious a bug is at first. Sometimes we raise or lower that rating based on how likely the bug is to be used within Fivetran+dbtLab’s context, and how much harm it could do from a business POV for our customers. Not all vulnerabilities carry the same business impact and business impact is how we determine severity. We pay for critical (P1), severe (P2), and moderate (P3) bugs. Points may also be distributed to all other submissions. Rules of Engagement must be followed. If you don’t follow the rules of engagement, we will not reward your submission. Who can take part To take part, all of these must be true: You are 18 or older. You do not live in, and are not based in, a country under full U.S. trade bans (sanctions). You are not on any U.S. government list of banned people or companies. This includes the Treasury Department's SDN List and the Commerce Department's Entity List, Unverified List, and Military End-User List. You are not owned or controlled by anyone on those lists. You are not in a country under full U.S. trade bans when you send us a report. You do not work for Fivetran+dbtLabs, or for a company that runs Fivetran+dbtLabs's systems. No one in your immediate family does either. You have not worked for Fivetran+dbtLabs in the last year from your separation. Getting access Anyone on the internet can reach the products you will test. You test the live products that real customers use. We do not give you any inside information or special access. You need a Bugcrowd account. When you sign up for our products, use only your @bugcrowdninja.com email address. Do not use your personal email. Learn about your @bugcrowdninja.com address. Need a second account? Add +1 to your email address. For example: [email protected]. Sign-up links for each product are listed under Scope Groups. Rules of Engagement Tag your web traffic Add this line (called a header) to every web request you send. It tells us the traffic is yours, so we do not block you by mistake: X-Bug-Bounty: Failure to identify yourself (or failure of your collaborators to follow the same rules) and provide the emails in your submission will invalidate your submission. This is how we identify and validate your submission. **How to test **Only test the products we list as allowed. Only use accounts you created yourself. You are testing the real, live product. Do not break anything. Do not delete or change parts of a site. Do not change settings. Do not leave behind any hidden way back in. Go slow. Send fewer than 300 requests per minute. Do not slow down the product for other people or set off our security alarms. Never try to get into another customer's account or data. If you need two users for a test, make a second account of your own. Follow the testing rules of Amazon Web Services, Google Cloud, and Microsoft Azure. Our products run on these services, and that can change at any time. If you find private data If you can see or change customer data or other private data, stop right away and send us a report. Do not dig any deeper. If you think a bug could let someone change or destroy data, stop and send us a report. We will work with you to measure how bad it is and pay you based on the full impact. Only look at or download the smallest amount of data needed to prove the bug. Do not use or share anything you find. After you send your report, delete every copy. When you finish testing, delete all accounts and data you made. Talking to us and others Do not disclose bugs publicly. If you have a problem or question, contact Bugcrowd Support . Do not contact us directly about your reports. If you do, you may lose points or be removed from the program. All communication will be through the Bugcrowd submission. What is not allowed or not paid Never do these Try to overload or crash our products, or flood anyone with email. Trick or fool our employees, support staff, or users. This includes fake emails, fake websites, fake login pages, look-alike links, and stealing login cookies. Break into our offices, our employees' property, or our data centers. Guess passwords over and over, or try lists of stolen passwords. Buy, sell, or use stolen passwords. Attack or contact our customers in any way. How to write a report Write in English at the 10th grade formal technical level. Follow our exact report format below, otherwise we may reject your submission. Put one bug in each report. If you need to combine several bugs to show the harm, put them in one report and explain how they connect. If the same bug shows up in many places, send only one report. We count copies as the same bug unless the harm or the way it works is very different. This includes our test versions and live versions. Do not send reports that only paste results from a scanning tool. Do not send "what if" ideas. You must show that the bug really works. Every report must include the four parts below: ### 1. Account and traffic details - The account ID of each account you used: - Attacker account - Victim account - The @bugcrowdninja.com email of every teammate (if you worked as a team) - Your IP address(es) used while testing - UTC timestamps each time you started and stopped testing - Bulleted list of affected endpoints, hosts, components, and impact for each. ### 2. Business impact summary - Two sentences at most, in plain 10th-grade technical English. - Tell us what an attacker could actually do to our business or customers. Bugs of the same type can have very different impact. For example, an SSRF bug may: - Only show that a cloud metadata service exists, with no data returned. - Return basic, non-secret metadata. - Return working passwords or keys. The first is P3 . The last is a P1. ### 3. Technical summary - Three to five sentences explaining how the attack works and why it works. - For your submision, three to five sentences explaining your thought process in identifying this weakness. ### 4. Steps to reproduce Manual steps Write sequentional step-by-step instructions. Do not make assumptions what about what is know. 1. Prerequisite Setup needed before you start: - What accounts are needed? - What other systems are needed (for example, Okta, Snowflake, or a git repository)? - How to set up each one 2. The steps, in order. Label each step with who does it: the "attacker" or the "victim." Automated scripts Also include scripts that run the whole attack on their own, from setup to the final step. These scripts should not use any of your infrastructure, keys, accounts. - You may need several scripts, one for each stage and each role (attacker or victim). - Write scripts in Python or Bash. - Use clear names for variables and functions, and organize the code into small, focused functions (Clean Code style)." Newly announced bugs When a bug in common software is announced to the public, we wait 30 days before we accept reports about it. For example, a bug announced on January 1 can be reported starting January 31. Leaked passwords and data You can tell us about our data or passwords that were leaked online, such as on hacker forums or leak websites. We give points for these reports, but not money. Legal protection | Safe Harbor If you follow these rules and act honestly, we see your testing as: Allowed under U.S. computer crime law (the Computer Fraud and Abuse Act) and similar state laws. We will not take legal action against you, or help anyone else do so, for honest mistakes. Allowed under U.S. copyright law (the Digital Millennium Copyright Act). We will not bring a claim against you for getting around our security controls. Allowed under our Terms and Conditions. We set aside the parts that would stop security testing, but only for testing done under these rules. Legal, helpful to everyone's online safety, and done honestly. You must still follow all laws. If you are ever unsure whether something is allowed, ask Bugcrowd Support before you go any further.

Targets

As of Sept 25th, 2026, effective immediately, we are pausing testing on our Capture the Flag target until further notice. We apologize for the inconvenience and will let you know as soon as we have more information as to when the program will re-open. In the interim, Bugcrowd and Fivetran Inc. will be working together to continue triaging and validating all submissions that have come in to-date. We appreciate your patience. If you have any questions, please create a ticket with Bugcrowd Support (https://bugcrowd-support.freshdesk.com/support/tickets/new) to get them answered. Target Information Fivetran platform documentation is available at: https://fivetran.com/docs/getting-started Focus Areas Access to pipeline data Account authentication Fivetran Connector SDK Excluded Submission Types P4 & P5 vulnerabilities Availability/volumetric testing e.g.: DoS/DDoS/Network DoS Rate limiting Email bombing/flooding Social Engineering For example, attempts to steal cookies, fake login pages to collect credentials. Phishing. Physical attacks against Facilities / Property. Vulnerabilities resulting from compatibility with external services. For example, when sources provide weak/vulnerable auth methods that Fivetran must use to provide a connector. Credential Stuffing / Password Spraying. Any type of brute force attacks. Clickjacking Submissions related to past or present data dumps or leaked credentials. Engaging in the trade of stolen/breached user credentials or use leaked credentials dumps in the testing. Modifying data residing in an account that does not belong to you. Accessing or downloading data beyond the minimum required to demonstrate a vulnerability. Making any changes to the system configurations, files, or data. Introducing a backdoor in any system. Attacking/interacting with our end users in any way. Domains out of scope: trust.fivetran.com Third party platforms under the fivetran.com domain Out of Scope All HVR products are excluded from this reward.

In Scope Targets: Fivetran (in scope)

Fivetran products, excluding Out of Scope assets. Any finding or (sub)subdomain that is not listed in scope but is confirmed owned by Fivetran may be accepted upon review.

In Scope Targets: dbt (in scope)

dbt products, excluding Out of Scope assets. Any finding or (sub)subdomain that is not listed in scope but is confirmed owned by dbt may be accepted upon review. Sign up: https://www.getdbt.com/signup

Out of Scope (out of scope)

Any internal, staging, or development systems. Tricking Fivetran support staff or employees. All HVR products. The Capture the Flag target. Testing is paused as of September 25, 2026, until further notice. P4 and P5 bugs, though we may reward points. Secrets found in repos, though we may reward points. 3rd Party Findings - Bugs in other companies' products, or weak security that comes from another company's product that we must work with. Clickjacking - Tricks that hide our page under a fake button to fool someone into clicking Self-XSS - Harmful code that only runs for the person who typed it . Also harmful code that needs someone's own computer to work, unless you prove an attacker can make it run from outside. CSRF - Tricking a logged-in user's browser into doing something when the form is open to everyone anyway, needs a secret code the attacker would not have, or only logs the user out. Content Spoofing - Showing fake text on our pages. Account Enumeration - Finding out whether a username or email has an account. Not locking accounts after many wrong passwords. Missing optional safety settings in our web pages' headers. Web servers that answer an "OPTIONS" request. SSL/TLS - Weak or outdated website encryption settings. Cache Poisoning - Tricking a server into saving and handing out a bad copy of a page or web address. SPF or DMARC - Missing or wrong email safety records.