Policies

By participating in this program, you agree to:

• Respect the Community Code of Conduct.
• Respect the Intigriti Terms and Conditions.
• Respect the scope of the program.
• Do not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube, Vimeo and other video platforms).

General Rules

• If there is unintended access to data, limit access to the minimum required for your PoC.
• Set the request headers according to Intigriti’s guidelines so that we are able to distinguish your traffic from malicious traffic.
• Adhere to the rate limitations according to Intigriti’s guidelines.
• We will not reimburse any costs related to proof of concepts (or else) created by the researcher.
• Rewards may be denied if there is evidence of program policy violations.

Please do NOT:

• Use, delete, alter or destroy any data that you have accessed or may be able to access in relation to the vulnerability.
• Disclose details of this program or vulnerabilities (even resolved ones) to the public or any third party without the explicit consent of the BMW Group.
• Perform any testing that causes degradation to BMW's services e.g., denial of service, or heavy automated scanning.
• Access or alter customer accounts.
• Perform social engineering attacks, including phishing.
• Perform any physical attacks.
• Perform any lateral movement or post-exploitation past the initial exploitation.

Reporter Eligibility Criteria

To be eligible to participate in our program, you must NOT be:

• (Former) employee or contract partner of BMW, its subsidiaries and associated companies.
• Family or household member of a (former) employee or contract partner of BMW, its subsidiaries and associated companies.
• Resident of a country against which Germany has issued export sanctions or other trade restrictions.
  If you do not meet the above criteria or you violate any of our program terms, we may deny any rewards. We may also exclude you from our program and reclaim any paid bounties or bonus.

Report Criteria

• Always submit proof regarding the exploitability of your finding.
• Only submit one vulnerability per report, unless you need to chain the vulnerabilities for successful exploitation.
• Submit your report immediately if you encounter any user credentials or user data such as PII.
• Answer all mandatory questions in the submission form to the best of your knowledge and belief.
• We might award an additional bonus for particularly well-detailed reports.

Mandatory Content

1. Affected Endpoint
   a) Description: Describe what endpoint is affected by your vulnerability.
   b) Ownership: If this endpoint is not in scope, describe why you assume it belongs to BMW.

2. Proof of Concept
   a) Completeness: Provide all relevant information in your initial submission.
   b) Step by step instructions: Clearly demonstrate how your proof of concept can be replicated step by step. The PoC must include proof how the vulnerability can be exploited.
   c) Make sure the screenshots provided match your finding (and the corresponding asset / URL) and they are reflecting the steps in your step by step instructions.

3. Impact
   a) Severity: Indicate what kind of data is affected and how this will affect confidentiality, integrity and availability of the asset.
   b) PII Data: Highlight if PII data is affected. Submit your report immediately if you encounter any user credentials or user data (such as PII).

4. Submission Questions
   a) IP: Provide the IP you used to test your proof of concept.
   b) Timeframe: Provide the timeframe when you performed your tests. Please also include your time zone.

Recommended Content

1. Affected Endpoint
   a) Description: Describe what endpoint is affected by your vulnerability.
   b) Ownership: If this endpoint is not in scope, describe why you assume it belongs to BMW.
2. Proof of Concept
   a) Completeness: Provide all relevant information in your initial submission.
   b) Step by step instructions: Clearly demonstrate how your proof of concept can be replicated step by step. The PoC must include proof how the vulnerability can be exploited.
   c) Make sure the screenshots provided match your finding (and the corresponding asset / URL) and they are reflecting the steps in your step by step instructions.
3. Impact
   a) Severity: Indicate what kind of data is affected and how this will affect confidentiality, integrity and availability of the asset.
   b) PII Data: Highlight if PII data is affected. Submit your report immediately if you encounter any user credentials or user data (such as PII).
   c) CVSS: Provide CVSS score and vector.
4. Submission Questions
   a) IP: Provide the IP you used to test your proof of concept.
   b) Timeframe: Provide the timeframe when you performed your tests. Please also include your time zone.
   c) Timeframe Format: Use ISO 8601 time format to describe the timeframe.
   Example: "2024-10-01T13:00:00+01:00/2024-10-01T15:30:00+01:00".
   d) Effort: Describe your required effort to identify the related vulnerability (can be simply in hours).
5. Recommended Solution
   a) Mitigation steps: Describe how the found vulnerability can be mitigated.

Validation times

Please note that No bounty findings may take significantly longer to validate.

Check our fix

We offer up to €50 bonus to verify a resolved issue for us (when requested).
This remains at the discretion of the BMW Group to award.

The BMW Group values the work of security researchers in improving the security of our products and services and encourages the community to participate in its bug bounty program. We are committed to working with you to verify, reproduce, and respond to legitimate reported vulnerabilities covered by this policy. Within this program bounties can be received by reporting vulnerabilities that are in the scope of program.

Critical and exceptional findings can earn you a place in our BMW Security Hall of Fame.

Targets

Only the targets listed above are in scope.

Browsers

The used browser has to be up to date (latest released, stable version) on the day of submission. Vulnerabilities which require certain plugins are out of scope.

Feedback

Would you like to help us improve our program or have some feedback to share, please send your anonymous feedback here:
Program feedback link
Please note this form will be checked periodically and should not be used for submission or support queries.

General

• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited.
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts.
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty.
• Reports that state that software is out of date/vulnerable without a proof-of-concept.

Duplicates

• Vulnerabilities that were already known to the BMW Group through our own testing or have already been reported to the BMW Group will be flagged as duplicate.
• Some sites rely on shared resources or assets. If a specific issue has already been found in a shared resource, it will be treated as duplicate.
• If there are multiple submissions regarding the same vulnerability on the same base domain URL / service or the same vulnerability on different staging environments of the same service reported by the same researcher, only the first submission will get the full bonus rewarded. Subsequent submissions will be accepted but with a lower bonus.
• If there are multiple submissions regarding the same vulnerability on different staging environments of the same service, only the first submission will be accepted. Subsequent submissions will be closed as duplicates.

Assets

• Everything not explicitly listed as in scope
• All subdomains of the domains in scope
• Pages redirecting to non-BMW domains

Vulnerabilities

• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Self-XSS that can't be used to exploit other users
• Verbose messages/files/directory listings without disclosing any sensitive information
• CORS misconfiguration on non-sensitive endpoints
• Missing cookie flags
• Missing security headers
• Cross-site Request Forgery with no or low impact
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing
• Bypassing rate-limits or the non-existence of rate-limits.
• Best practices violations (password complexity, expiration, re-use, etc.)
• Vulnerabilities that only work on software that no longer receive security updates
• Clickjacking without proven impact/unrealistic user interaction
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Anything related to email spoofing, SPF, DMARC or DKIM
• Content injection without being able to modify the HTML
• Username/email enumeration
• Email bombing
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Banner grabbing/Version disclosure
• Not stripping metadata of files
• Same-site scripting
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without proof of the existence of the uploaded file
• Blind SSRF without proven business impact (pingbacks aren't sufficient)
• API key disclosure without proven business impact
• Disclosed/misconfigured Google Maps API keys
• Host header injection without proven business impact
• CSRF logout
• Self-exploitation (e.g., token or cookie reuse)
• Vulnerabilities in third-party integrations
• Broken links to third-party social media web pages (e.g., independent BMW Dealers, Resellers or Fanclubs)
• Blind XSS that cannot be verified: Blind XSS Triggers must be fired within a week after setting them up. If they cannot be verified by the triage team, the severity of the report will be decreased or the report will be rejected.

Post-exploitation

All post-exploitation is out of scope, except the minimum to prove that the exploit is working:

• In case of an RCE or injection attack, you may issue commands stating the version of the database, the system name or the local IP address.
• All post exploitation that will risk the stability or integrity of the system is out of scope.

Domains from independent BMW Dealers, Resellers or Fanclubs

We would like to point out that not every asset that has BMW (or one of its brands) in its name necessarily belongs to the BMW Group. The systems in question may include retailers, importers, service providers, fan clubs, or others. However, in many of these cases, we have limited or no influence on the actual owner of these systems. In these cases, the reports will be closed by the triage team or by us with a corresponding note. These systems are not eligible for bounty or bonus.

No Bounty Domains

While not being covered by the safe harbor clause, vulnerabilities related to domains that are not in scope of this program can be reported by choosing the respective “Other BMW Domains” asset. Please consider that these assets are not eligible for any bounty. However, they may be eligible for a bonus.

This program follows Intigriti's triage standards.

Where can I get test credentials?

We currently do not offer any credentials to test user roles. If an account is needed, you can attempt to self-register with your @intigriti.me email address. Submissions with accounts registered with other email addresses will not be eligible for a bounty.

I believe I have found a vulnerable asset related to BMW but I am not sure if the asset actually belongs to BMW. Can I still report it?

Yes! If you are unsure if the vulnerable asset you found belongs to BMW and you believe that it is not owned by an independent retailer, importer, service provider, fan club, etc. please use the "Other BMW Domains" asset to report this vulnerability. Note that these assets are not eligible for bounty but we may award a bonus for high, critical and exceptional severity findings.