submit bug report: https://curl.se

No technology is perfect, and curl believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our products, we encourage you to notify us. We welcome working with you to resolve the issue promptly.
Disclosure Policy
Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
Exclusions
While researching, we'd like to ask you to refrain from:
Denial of service
Spamming
Social engineering (including phishing) of curl developers
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Valid issues
Security problems present in the latest released curl/libcurl version that haven't already been reported/fixed and haven't otherwise been made public, in full or in part, may be subject for a bounty. Responsible disclosure must be followed for a vulnerability to be subject for a bounty.
Exclusions from the bounty program
Experiments
Vulnerabilities in features which are off by default and documented as experimental, are not eligible for a reward.
Issues with our infrastructure
Any infrastructure issue that you may find is out of the policy unless it affects the source packaging/distribution. This includes but is not limited to DNS config for our domains, our email setup details and website configurations or hosting details. Not in scope!
The wiki is world editable
It is on purpose. It is a wiki. If you change or add non-curl related contents to prove a point, we consider that abuse.
Thank you for helping keep curl and our users safe!

submit bug report: https://clario.co/

Policy

1 Intro
Clario Tech DMCC (hereinafter - Clario) invites security professionals to participate in our bounty program to ensure security of our products and safety of our customers’ data.
Please read carefully this program policy before proceeding any further testing activities on the company assets.
2 Program Scope
The program scope includes in-scope assets and in-scope vulnerabilities. Please note, that you are not allowed to test any Clario assets, which are not included in the program scope. Clario will pay no rewards for any discovered vulnerabilities, which are defined as out of vulnerability scope in this program.
2.1 In-Scope Assets
2.1.1 Web services and applications
Web services and applications, directly bound to the domains specified bellow, are in scope of the program. Any other domains, subdomains, services and applications are out of scope.
Tier 1
https://account.mackeeper.com
https://kbill.mackeeper.com
https://mkapi.mackeeper.com
https://crm.clario.co
https://chat.clario.co
https://chat-crm.clario.co
https://yapi.clario.co
https://api.account.clario.co
Tier 2
https://dl.clario.co
https://clario.co
https://webapi.clario.co
https://inapp.clario.co
https://mackeeper.com
Tier 3
https://api-ne.mackeeper.com
https://updatetracker.clario.co
https://updater.clario.co
https://dcs.clario.co
https://event.clario.co
https://adblocking.clario.co
https://inapp.clario.co
https://static-cdn.clario.co
https://updater.clario.co
2.1.2 Desktop and mobile applications
The next applications are in scope:
Mackeeper app
version 6.3 or higher. We will update this number upon changes in our production releases
Note: for short period of time, we still accept High and Critical vulnerability reports for older versions of Mackeeper (5.14.1 and higher)
This application belongs to Tier 1 resources.
Please note, only defined in this table versions of applications are in scope. We do not accept reports on outdated version of applications.
2.2 Vulnerability Scope
While you are allowed to test any technologies within of the specified scope of resources, please consider the next limitations:
2.2.1 Social engineering
We will reward only the reports on purely technical vulnerabilities. Any kind of social engineering activities during your testing within this program are strictly prohibited and might be illegal.
Particularly, you are not allowed:
contact to our customers for testing purposes
contact to Clario Customer Support with manipulative aims
contact to Clario personnel (except contacts via Hacker One platform to dedicated Clario team)
2.2.2 Service disruption
You must not disrupt Clario services. Especially,
DDOS attacks are strictly prohibited.
Please avoid any activity that could lead to the disruption of our service (DoS). Intentional service disruption is prohibited.
You should always enable throttling on your web-scanners and set it to “one request per second”. Unthrottled automated scanning reports could be qualified as N/A.
2.2.3 Customer data access restriction
You must not compromise or disclosure any customer data. Please immediately stop your research and notify Clario in case you have got access to any customer account or data (except your own or those you have explicit written permission from their owners)
2.3 Vulnerabilities out-of-scope
We are not interested and will not reward reports for vulnerabilities specified in this section
2.3.1 Common vulnerabilities excluded from the scope
Missing best practices in SSL/TLS configuration
Missing SPF/DMARC/DKIM settings
Missing best practices in Content Security Policy
Server/Application error message with no sensitive information leakage
Previously known vulnerable libraries without a working Proof of Concept
Theoretical security issues with no realistic exploit scenario
Issues that would require complex end-user interactions to be exploited
Vulnerabilities that require root-level physical access to the targeted device to be exploited
Open ports scanning, banner grabbing, software version disclosure
MITM attacks (except the reports on VPN vulnerabilities)
Clickjacking on pages with no severe impact
Implausible bruteforce attacks
Rate limiting or bruteforce issues on non-authentication endpoints
Vulnerabilities which could not be reproduced on the latest versions (by the day of your report) of the browsers Safari, Chrome, Firefox
2.3.2 Common vulnerabilities excluded from the scope if the potential impact is not proven
The next vulnerabilities are usually excluded from scope as “not self-sufficient”. However, you may show them as a part of your attack chain. In this case we will reward your report according the maximum proven vulnerability in your report.
Content spoofing and text injection in client side only
Stack traces, path disclosure, and directory listings
“Mixed Content” issues
HTTP Options header
Missing HttpOnly or Secure flags on cookies
Comma Separated Values (CSV) injection
2.3.3 Out of Scope bugs for Android apps
Lack of rooting detection
Runtime hacking exploits (exploits only possible in a rooted environment)
Lack of binary protection control in android app
Shared links leaked through the system clipboard
Any URIs leaked because a malicious app has permission to view URIs opened
Lack of obfuscation third-party libraries
User data stored unencrypted on external storage
OAuth and App secret hard-coded/recoverable in APK
Any kind of sensitive data stored in app private directory
2.3.4 Out of Scope bugs for iOS apps
Lack of jailbreak detection is out of scope
Runtime hacking exploits (exploits only possible in a jailbroken environment)
Lack of binary protection (anti-debugging) controls
Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries
Path disclosure in the binary
Lack of obfuscation third-party libraries
OAuth and App secret hard-coded/recoverable in APK
Snapshot/Pasteboard leakage
3 Rewards (bounty)
The reward is calculated based on the target tier (see the Program Scope section of this document) and severity of the vulnerability.
Clario defines severity level based on our self-calculated CVSS score for each specific vulnerability.
Please note, that Clario may use additional factors unrelated to CVSS score to determine the severity level of a vulnerability. This approach is supported by the CVSS v3.1 specification:
"Consumers may use CVSS information as input to an organizational vulnerability management process that also considers factors that are not part of CVSS in order to rank the threats to their technology infrastructure and make informed remediation decisions. Such factors may include: number of customers on a product line, monetary losses due to a breach, life or property threatened, or public sentiment on highly publicized vulnerabilities. These are outside the scope of CVSS".
For example, CVSS methodology uses Confidentiality, Integrity, and Availability as equal factors for the calculations. Clario always emphasises our customer data protection. So, we will rate vulnerabilities related to personal data protection as more critical, than similar vulnerabilities affecting availability only. Our rule of thumb is: “the more likely vulnerability will affect our customers data and the more easily is to reproduce the attack, the higher severity level and the higher reward”.
Another example is attack vector. Clario will not reward vulnerabilities, which requires physical access to customer device to be exploited. These vulnerabilities are explicitly defiled out of scope, while it is still possible calculate CVSS score for such vulnerabilities.
Usually, we also decrease criticality level of vulnerabilities, which do not harm our assets directly, but rather “might be potentially used” as a part of some more complex attack chain. For example, reflected XSS in most cases will be evaluated as “Low”, except you provided PoC for full attack chain with more significant impact.
Please note, that our priority is TECHNICAL issues. The more “social engineering” activities assume your scenario, the less reward you will get.
Bounty calculation table:
TIER 1
Critical - 5000
High - 3000
Medium - 1000
Low - 250
TIER 2
Critical - 3000
High - 1500
Medium - 400
Low - 150
TIER 3
Critical - 1000
High - 750
Medium - 250
Low - 100
Please note, this table specifies the maximum amount paid by Clario as reward. The actual amount will depend also on the report quality. Reports lacking necessary information to enable Clario to efficiently reproduce the issue will not be rewarded. Please read Report Eligibility section for more details.
Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
4 Report Eligibility
4.1 In order your report to be eligible, you must:
Be the first party to report the issue
Provide a clear report, containing steps to reproduce issue and Proof of Concept (PoC)
Not disclose the issue publicly before Clario approval
Follow this program policy and do not violate the rules
4.2 Eligible report should include:
A detailed description of the issue, inclusive potential impact
Any conditions, prerequisites and steps to reproduce the issue
Any other supporting documentations (codes, screenshots, references) required to explain the vulnerability and the relevant attack scenario
Please submit one vulnerability per a report, unless you need to chain vulnerabilities to provide impact.
4.3 Please DO NOT report:
purely theoretical and best-practice issues without real impact description and PoC
unvalidated reports from automated vulnerability scanners
issues out-of-scope Such reports most likely be closed as "N/A". Submitting multiple N/A reports may result in you being excluded from participating in our program.
5 Response Targets (SLA)
Clario will make the best effort to meet the following SLAs for hackers participating in our program:
SLA (in business days):
First Response (from report submit) - 2
Time to Triage (from first response) - 2
Time to Bounty (from triage) - 14
Time to Resolution depends on severity and complexity.
We will keep you informed about our progress throughout the process.
6 Disclosure Policy
You must not discuss any vulnerabilities (inclusive the resolved ones) outside of the program without express consent from Clario.
Public disclosure of the vulnerability prior to resolution may cancel a pending reward. We reserve the right to not disclose the report or to disclose it only partially.
Please follow HackerOne Disclosure Guidelines.
7 Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered as authorized conduct and we will not initiate any legal actions against you.
If legal actions is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Still, you must comply with all applicable laws, including local laws of the country or region in which you reside or in which you download or use Clario software or services.
8 Feedback
If you have any suggestions or feedback, please let us know at bugbounty@weareclario.com

submit bug report: https://bi.owox.com

Policy

No technology is perfect, and OWOX believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.
Disclosure Policy
Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
Exclusions
While researching, we'd like to ask you to refrain from:
Denial of service
Spamming
Social engineering (including phishing) of OWOX staff or contractors
Any physical attempts against OWOX property or data centers
Thank you for helping keep OWOX and our users safe!

submit bug report: http://olx.com

At OLX, we take security issues seriously. If you believe you've detected a vulnerability within our products we'd like to hear about it. We'll investigate all reports and do our best to fix these issues as soon as possible.
Important Information
At the moment our program managed by HackerOne is paused, for more information visit security.olx.com.
Scope
You can review OLX sites in the scope by visiting security.olx.com. Vulnerabilities need to be documented in a way that they can be reproduced. Send screen-shots, code, video to helps to understand it.
What about public disclosure?
We're more than happy to publicly disclose your bug once it has been fixed by our developers.
Exceptions & Rules
Any activity that would disrupt, damage or adversely affect any third-party data or account is not allowed. Please do not mass create accounts to perform testing. Also do not perform brute force testing to determine whether rate limiting is in place for particular APIs or pieces of functionality.
The following are strictly prohibited:
Denial of Service attacks.
Physical attacks against offices and data centers.
Social engineering of our service desk, employees or contractors.
Compromise of a OLX users or employees account.
Automated tools or scans, botnet, compromised site, end-clients or any other means of large automated exploitation or use of a tool that generates a significant volume of traffic.
Out of Scope/Non-qualifying vulnerabilities
This vulnerabilities are out of scope since we're currently aware of these vulnerabilities in some of our products and actively working on them.
WordPress/CPanel vulnerabilities
Software version disclosure
HttpOnly and Secure cookie flags
SSL/TLS scan reports (this means output from sites such as SSL Labs)
Password strength policies
Session timeout
Session Hijacking (cookie reuse)
Missing security headers
Autocomplete
Account enumeration
Rate-limiting (for none authentication flow)
Self XSS attacks
Self-exploitation (i.e. password reset links or cookie reuse)
Tabnabbing with partner links
Use of a known-vulnerable library (without proof of exploitability)
Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue
Directory listing
Open redirects
Content Spoofing
Missing SPF/DKIM/DMARC records
Rewards
At this time, we are not awarding bounties or cash rewards for reported vulnerabilities.
At OLX, we take security issues seriously. If you believe you've detected a vulnerability within our products we'd like to hear about it. We'll investigate all reports and do our best to fix these issues as soon as possible.

submit bug report: https://www.mapbox.com/security

Mapbox appreciates the effort of software security researchers who work to make the Internet more secure. Our security vulnerability bounty system exists to reward the work of security researchers who find issues with our software and web services.
If you have questions about our bug bounty program or are unable to properly access/test an in-scope asset please email security@mapbox.com.
SLAs
Mapbox attempts to meet the following SLAs for hackers participating in our program:
Response Target   Time (in business days)
Time to first response (from report submit)   2 days
Time to triage (from report submit)   2 days
Time to bounty (from triage)   10 days
Time to resolution   Depends on severity and complexity
Rules
Do not publicly disclose the bug until Mapbox has confirmed the bug is fixed.
Do not subject our website or web services to DoS, DDoS, scraping, brute force, or other type of automated attack.
Do not spam our contact form or support inboxes.
Do not use security scanners or tools which may cause DoS, DDoS or scraping-like behavior against our web services or website.
Do not try to gain access to another user's account or data - please use test accounts.
Eligibility for a bounty
To qualify for a bounty:
You must be the first reporter of the vulnerability and it must not be a duplicate or known issue
Your report must be within scope and not on our list of ineligible reports and known issues
You must not be a minor
You must not be a resident of or be located in a country on any U.S. sanctions lists
Public disclosure of the issue before its resolution will result in disqualification from the Mapbox HackerOne program. Evidence of abuse or accessing another user's data or account without their permission will also result in disqualification from the program.
Reporting
All bug reports should include the following information to be considered for a bounty. Reports missing the information below will be marked as "Needs More Information," resulting in a minor loss of reputation points.
Vulnerable URL(s) and any affected parameters
Your browser and operating system
Detailed, step-by-step explanation of how to replicate the issue
Screenshots or videos of the vulnerability are highly encouraged and will result in quicker triage of the issue and possibly a higher bounty at Mapbox's discretion.
Eligible reports
Here is an incomplete list of reports we are interested in:
Cross-site scripting (XSS)
Directory traversal
Privilege escalation
Server-side remote code execution or command injection
SQL or NoSQL injection
Access control bypass
Disclosure of secret access tokens (sk.*) by Mapbox systems other than when they are instantly generated on mapbox.com. Note that reports about the disclosure of public access tokens (pk.*) are ineligible.
Presence of Mapbox staff secret tokens (sk.*) on the public internet, as determined by Mapbox. Presence of Mapbox customer secret tokens on the public internet are ineligible.
Ineligible reports or known issues
The following reports are ineligible to receive bounties or reputation points. Any submitted reports related to them will be closed as N/A.
Social engineering of Mapbox staff, contractors, or customers
Session management issues
Reports from automated tools or scans
Issues related to software or protocols not under Mapbox's control
Denial of Service attacks, including mass requests against password reset, login, account creation, or other endpoints. We have monitoring and mitigation against brute force attacks which we believe are adequate. Please do not conduct brute force attacks.
HTML or CSS injection in map markers or map features - this is by design so that our users can have rich, styled maps. We sanitize JavaScript and arbitrary code using sanitize-caja. We are interested in reports about the execution of JavaScript though!
Presence of autocomplete on form fields, including username and password fields
SPF, DKIM, or DMARC settings
Password and account recovery policies, including password reset emails and password reset links
Reports noting the lack of or suggesting the institution of a password policy, including account lockout settings
email spoofing
DNSSEC settings
Presence of public (pk.*) access tokens in web pages or URLs - due to their use in client-side JavaScript these are public by design.
Presence of sk.* access tokens with non-staff and non-admin privileges in web pages or URLs or in deleted or archived GitHub repo's.
Username enumeration, including an oracle that discloses whether a given username or email address is associated an account
Reports of CSRF or reports of a lack of CSRF tokens on wwww.mapbox.com, unless accompanied by a detailed proof of concept exploit. We have alternative CSRF mitigation in place.
Missing HTTP security headers, unless accompanied by a detailed proof of concept exploit that leverages their absence
Existence of access-controlled administrative pages
Reports related to the SSL/TLS certificate for www.mapbox.com. Please report instead to the Fastly security team.
Open redirects
Use of a library with known vulnerabilities (without evidence of further exploitation)
Vulnerabilities only affecting older browsers. Please see our documentation on browser support. Any reports related to Internet Explorer 7 will be marked as ineligible.
HSTS or CSP headers
Clickjacking or UI redressing on maps or features intended to be embedded in other pages such as those from the api.tiles.mapbox.com or api.mapbox.com domains. Mapbox customers often embed their maps on their pages using the iframe element.
Content spoofing or HTML injection, unless accompanied by a proof of concept that demonstrates a security risk beyond injecting plain text
Reports of insecure SSL/TLS ciphers or weak signature algorithms, unless accompanied by a working proof of concept of an exploit
Any resources which happen to contain mapbox in their name but are not owned Mapbox. For example, if an S3 bucket named mapbox-test was discovered and reported with a vulnerability, and we determine it is not owned by Mapbox, it would be considered ineligible.
Issues related to buying subscription without paying is currently out of scope from our bug bounty program.
Ineligible for monetary bounty, but appreciated
The following reports are ineligible for a monetary bounty due to their low severity though they may be available for reputation points. If accompanied by a detailed proof of concept of an exploit leveraging their existence they may be eligible for a cash bounty at Mapbox's discretion.
Mixed content
Self-XSS