OVHcloud

Rules

OVHcloud

OVHcloud is a leading company in the cloud services sector, providing a comprehensive range of infrastructure and hosting solutions. Specializing in web hosting, dedicated servers, and cloud services, we offer flexible and scalable solutions to meet client's cloud computing needs. Recognized for its extensive global infrastructure, OVHcloud stands out for its reliability, security, and commitment to technological innovation.

While we are doing our best to keep OVHcloud services as safe as possible, we know that some bugs can slip through our scrutiny. We're delighted to be working with skilled cybersecurity researchers to improve the application security of our customers and their data. We intend to respond and resolve reported issues as quickly as possible. This means that you will receive progress updates from us at least every five working days.

Program Rules

Eligible reports

These lists of Qualifying and Non-Qualifying Vulnerabilities are intended to provide general guidance only, and we may consider other factors when determining the eligibility of a report

Leak of confidential data

If you think you found sensitive ovhcloud data in an out-of-scope source, you may report it. The eligibility of the report for a bounty will be discussed internally on a case by case basis.

Important precautions and limitations

As a complement to the Program's rules and testing policy :

• DO NOT alter compromised accounts by creating, deleting or modifying any data
• DO NOT use compromised accounts to search for post-auth vulnerabilities (they won't be eligible anyway)
• DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your Proof of Concept (screenshot, server response, JSON file, etc.) as much as possible.
• In case of exposed credentials or secrets, limit yourself to verifying the credentials' validity
• In case of sensitive information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.

Testing Policy and Responsible Disclosure

Please adhere to the following rules while performing research on this program:

• Denial of service (DoS) attacks on OVHcloud applications, servers, networks or infrastructure are strictly forbidden.
• Avoid tests that could cause degradation or interruption of our services.
• Do not use automated scanners or tools that generate large amount of network traffic.
• Do not leak, manipulate, or destroy any user data or files in any of our applications/servers.
• Do not copy any files from our applications/servers and disclose them.
• No vulnerability disclosure, full, partial or otherwise, is allowed.

Reward Eligibility

We are happy to thank everyone who submits valid reports which help us improve the security of OVHcloud, however only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below).
• The report must contain the following elements:
• Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and OVHcloud, and remediation advice on fixing the vulnerability
• Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
• Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands, etc
• You must not break any of the testing policy rules listed above
• You must not be a former or current employee of OVHCloud or one of its contractors.

Out of scope

• All domains, subdomains or applications not listed in the above list of 'Scopes'
• Vulnerabilities reported on client services
• *.osp.ovh.com

Qualifying vulnerabilities

• SQL Injection (SQLi)
• Cross-Site Scripting (XSS)
• Remote Code Execution (RCE)
• Insecure Direct Object Reference (IDOR)
• Horizontal and vertical privilege escalation
• Authentication bypass & broken authentication
• Business Logic Errors vulnerability with real security impact
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
• Cross-Origin Resource Sharing (CORS) with real security impact
• Cross-site Request Forgery (CSRF) with real security impact
• Open Redirect
• Exposed secrets, credentials or sensitive information on an asset under our control and affecting at least one of our scopes.

Non-qualifying vulnerabilities

• Tabnabbing
• Missing cookie flags
• Content/Text injections
• Mixed content warnings
• Clickjacking/UI redressing
• Denial of Service (DoS) attacks
• Known CVEs without working PoC
• Open ports without real security impact
• Social engineering of staff or contractors
• Presence of autocomplete attribute on web forms
• Vulnerabilities affecting outdated browsers or platforms
• Self-XSS or XSS that cannot be used to impact other users
• Outdated libraries without a demonstrated security impact
• Any hypothetical flaw or best practices without exploitable PoC
• Expired certificate, best practices and other related issues for TLS/SSL certificates
• Unexploitable vulnerabilities (ex: XSS or Open Redirect in HTTP Host Header)
• Reports with attack scenarios requiring MITM or physical access to victim's device
• Missing security-related HTTP headers which do not lead directly to a vulnerability
• Unauthenticated / Logout / Login and other low-severity Cross-Site Request Forgery (CSRF)
• Invalid or missing SPF (Sender Policy Framework), DKIM, DMARC records
• Session expiration policies (no automatic logout, invalidation after a certain time or after a password change)
• Disclosure of information without direct security impact (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets)
• CSV injection
• HTTP Strict Transport Security Header (HSTS)
• Subdomain takeover without a full working PoC
• Blind SSRF without direct impact (e.g. DNS pingback)
• Lack of rate-limiting, brute-forcing or captcha issues
• User enumeration (email, alias, GUID, phone number)
• Password requirements policies (length / complexity / reuse)
• Ability to spam users (email / SMS / direct messages flooding)
• Disclosed / misconfigured Google API key (including Google Maps)
• Recently disclosed 0-day vulnerabilities (less than XX days since patch release)
• Password reset token leak on trusted third-party website via Referer header (eg Google Analytics, Facebook…)
• DKIM/SPF/DMARC issues
• Stolen secrets, credentials or information gathered from a third-party asset that we have no control over