The security of our operations is our highest priority for many reasons:
We're dealing with our clients' money.
We must protect our partners' privacy.
We have our reputation at stake.
Whether you are a professional security researcher or a beginner, we welcome your security reports. However, we'd love them to be valuable and actionable. That's why we have specific recommendations in their regard.

Security report guidelines
Please provide the information on how the vulnerability you've discovered might be used theoretically and practically, its impact, and all the pertinent details.
Please provide the exact steps on how the vulnerability can be exploited and how we can reproduce the issue ourselves. We'd love to see the demonstration of the attack, which will not affect our existing users. You may create as many test user accounts as you need.
Please submit the bug report via our support channels (email or web site widget) only after you've verified that the bug exists.
Use whatever language you prefer if you don't feel comfortable writing in English.
Please remember that we don't reward you for the already known vulnerabilities listed below. We are leaving the monetary reward you'll get for your report to our discretion. The reward will be paid in bitcoins.
"Vulnerabilities" that affect or are present on other major websites will not be rewarded.

Also, suppose you're a security researcher reading this information. In that case, we'd like to draw your attention to the fact that our SPF record is valid, and we do not deem account deletion a security vulnerability.

We welcome you to help us find flaws in our code by clicking the "Report a bug" button at the bottom of our website.

Known and other issues we will not reward for:
A missing DNS CAA record
HTTP security headers-related issues (unless there is a way to exploit them)
Plain text passwords are sent to our users via email
Most of the information about our publishers' sites and advertisers' campaigns is public
Some IPs of our servers are exposed to the internet
There is a way to terminate a browser session of another user
Ticket Trick vulnerability
The presence of JPEG EXIF metadata
You can press the back button in your browser after logging off and continue to see your logged in user pages
Software versions being exposed unless this could lead to a working exploit against our infrastructure
Rate limit for APIs
HTTP headers injections/forgery - we use SSL for all critical servers
It is possible to find out if a particular email address is already signed up
Our blog config.yml is publicly accessible

Hall of fame

2022-05-12 It's possible for the attacker to lock the user out of their session for several hours by brute forcing the user password. The fix is pending. We were first notified about the issue more than a year ago but we forgot to mention it here since it's not trivial to exploit: you need to know the victim's email address. The reward is yet to be determined and sent.

2022-04-06 Foysal Ahmed reported an XSS vulnerability which we thought we had already fixed but it resurfaced again due to massive code changes. We're now fixing the vulnerability, the reward is yet to be determined and paid.

2022-03-02 Google CAPTCHA protection could be circumvented under certain conditions. Google fixed the issue on their side.

2022-02-12 Tushar Sharma reported that rate-limiting of certain user actions wasn't enforced under special conditions. The vulnerability is being fixed ($100).

2021-11-05 A security researcher discovered that we are not properly utilizing CSRF headers under some conditions ($150).

2021-11-05 Koutrouss Naddara found an A-ADS server which is available via HTTP as opposed to HTTPS. The fix is pending ($40).

2021-09-03 Khan Mamun (@mamunwhh) found out that we expose the NGINX version ($20).

2021-09-02 Muhammad Julfikar Hyder reported that some of our internal technical data is publicly available.

2021-07-08 badcracker reporteded two webpages which allowed to bypass CAPTCHA protection under special conditions ($50 + $50).

2021-04-06 Murimi M. reported a vulnerability that allowed to log into a user account with an access code or BTC address without solving a CAPTCHA ($30).

2021-03-11 An anonymous researcher reported a vulnerability that allowed a possible takeover of an unused A-ADS subdomain ($30).

2021-03-09 Ardyan Vicky Ramadhan reported a bug that allowed to edit other users' unlinked advertisements ($30).

2021-02-16 Ardyan Vicky Ramadhan reported a bug that allowed to edit other users' campaigns ($300).

2021-01-08 Ardyan Vicky Ramadhan reported that we don't rate limit certain actions which could be performed by the user ($50).

2021-01-08 Ardyan Vicky Ramadhan reported a Ticket Trick vulnerability ($50).

2020-11-23 Ardyan Vicky Ramadhan reported a Formula/CSV injection vulnerability which could only exploited if the attacker gains unauthorized access to our advertisers ($50). This attack is difficult to mitigate, and explicitly disallowed from quite a few bug bounty programs.

2020-10-02 Ardyan Vicky Ramadhan re-reported a tab open vulnerability first discovered two years prior ($25). It resurfaced after a major website redesign. We've adjusted our development guidelines to avoid it in the future.

2020-09-01 Shiraz Ali Khan reported a minor configuration issue with our email server DNS record ($20).

2020-03-27 Abir Khan Hridoy reported a possible DoS vulnerability in the user email confirmation routine ($25).

2019-10-24 Agung Saputra (r00t-geek) found out that some of our servers are directly exposed to the Internet ($20).

2018-05-06 Ch Chakradhar (Spi3er) reported a catalog CSRF vulnerability ($30).

2018-03-02 Waqar Vicky reported a number of issues and received a $100 bounty:
Password reset requests are not rate limited and can be used to perform a DoS attack
Our jQuery library is outdated and might be insecure
We allow extremely weak password at user registration
After logging off you can use a web browser back button to see previously opened web pages
After changing an email address or password other open sessions and existing password reset tokens are not invalidated

2017-12-10 Anonymous researcher reported a session termination vulnerability and earned $50.

2017-11-22 Anonymous researcher reported a self XSS protection vulnerability - we don't consider it to be our vulnerability, but we may take measures to mitigate it in the future.

2017-11-22 Anonymous researcher reported a tab open vulnerability and earned ~$100.

2017-11-22 Anonymous researcher reported an SSL cookie vulnerability (investigating).

2017-11-21 Anonymous researcher reported a minor issue related to the email change and earned a reward of ~$30.

2017-11-16 Ch Chakradhar (Spi3er) reported a minor issue which made it possible to check the existence of a user by email and earned a reward of ~$30.

2017-11-08 Anonymous researcher reported a vulnerability which gave him access to our staging database and to a third-party server which we used for monitoring and control. Thus he earned a reward of ~$500.

2017-11-05 Ankit Bharathan reported a low-impact XSS issue in ad preview page and earned a reward of ~$50.

2017-07-04 Jens Mueller (@jensvoid) responsibly reported a CORS misconfiguration vulnerability and earned a reward of ~$240.

Addendum, our stance on the Google CAPTCHA 2.0 Vulnerability

We've been notified that it's possible to programmatically solve Google CAPTCHA 2.0. We are reluctant to address this issue for several reasons:

The provided attack is as difficult and time-consuming to carry as solving it, IOW it still serves its purpose.
Literally millions of websites including Google itself still use this version of CAPTCHA.
Google doesn't consider it to be vulnerable. No CVE, nothing. The original researcher couldn't make Google accept this as a vulnerability.
We cannot reward for the vulnerability in the third party service. That would mean that anyone can start claiming rewards for a multitude of bugs in the Open Source software stack that we use.

Keywords: security, vulnerabilities, report, reward, bug bounty.
Was this article helpful?
Cancel
Thank you!