Bountytalk Launched

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Angelina

Pages: [1] 2 3 ... 15
Bug bounty programs / Practo Bug Bounty
« on: May 16, 2023, 06:52:29 PM »
submit bug report:

At Practo, we take safety and security of our customers’ data very seriously and stand guard to the trust put in us by our users.

We understand the importance and value of the role played by security researchers and ethical hackers in keeping the internet safe. Therefore, we support their responsible efforts in not only identifying potential vulnerabilities but also reporting them responsibly.

We urge you to review the Responsible Disclosure Policy before you test and/or report an issue with any of our applications. We assure you that Practo will never pursue any legal action against users who report the issues, as long as they follow these guidelines.

Who can participate in the program?
Anyone who doesn't work for Practo or partners of Practo who reports a unique security issue in scope and does not disclose it to a third party before we have patched and updated will be eligible to take part in this program.

Responsible Disclosure policy:
- Report your finding by writing to us directly at [email protected] without making any information public.
- We will respond as quickly as possible, generally takes 24-48 hours.
- In best interest of our customers and their data, please do not publicly disclose the issue until it has been addressed by Practo within a reasonable timeframe.
- In order to keep everyone safe, please act in good faith towards our users' privacy and data during your disclosure. We won't take legal action against you or administrative action against your account if you act accordingly.
- Make every effort to avoid privacy violations, disruption to production systems, degradation of user experience and destruction of data during security testing. This would include Brute Force, DoS, Spamming, Scraping, Social Engineering etc.
Reporting guidelines
Please include the following information when sending us the details:

- Operating System name and version.
- Client name and version.
- Plugin names and version installed in the client.
- Steps necessary to reproduce the vulnerability including any specific settings required to be reproduced (If this contains more than a few steps, please create a video so we can attempt to perform the same steps).
- A copy of the source code following your successful test.
- What is the impact of the issue.
- What are some scenarios where an attacker would be able to leverage this vulnerability?
- What would be your suggested fix?
- All subdomains of i.e. *
- Practo mobile apps -- Android, iOS
Not in Scope
Phishing attacks
Wordpress Users Disclosure
Wordpress DoS CVE-2018-6389
Wordpress CORS in wp-json
SPF Misconfiguration
Our responsibility
Once we receive the details from you, we will ensure to acknowledge the issue within 24-48 hours. We’ll assess the issue and provide you with an estimated timeframe for addressing the reported vulnerability. We will notify you once the vulnerability is fixed. And last but not least, our gratitude and sincerest thanks to you for helping us keep user data and services safe and secure by featuring you in our security hall of fame 🗗.

Legal terms
By participating in Practo’s Responsible Disclosure program (the “Program”), you acknowledge that you have read and agree to Practo’s Terms of Service as well as the following:

- Your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.

- You are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments when we run bug bounty programs in the future.

- Practo reserves the right to terminate or discontinue the Program at its discretion.

Bug bounty programs / Prezi Bug Bounty
« on: May 16, 2023, 06:50:00 PM »
submit bug report:

Prezi Responsible Disclosure
At Prezi, we take security of our users’ data very seriously and we believe in harnessing the power of the security researcher community to help keep our users safe. We encourage the responsible disclosure of security vulnerabilities.

This brief ("brief") covers your participation in the Prezi Responsible Disclosure Program (the "Program"). It sets out terms between you and Prezi ("Prezi," "us" or "we"). By submitting any vulnerabilities to Prezi or otherwise participating in the Program in any manner, you accept these terms, the Prezi Privacy Policy, and the BugCrowd Standard Disclosure Terms, Code of Conduct, Disclosure Policy, and Terms of Service.

To join the program, you should read this entire brief, and only proceed if you accept all the terms within.

Thank you for making Prezi better for everyone!

Discovering security vulnerabilities
We encourage and allow you to conduct security research and vulnerability testing on Prezi services and products to which you have authorized access on the “” domain.
Please always keep the following rules in mind:

Never attempt to access someone else’s account or data; please always use your own account(s) for testing.
Never try to modify or destroy any data that does not belong to you.
Do not attempt or launch a denial of service attack. We and our users appreciate reliability.
Do not attempt or execute social engineering attacks (including but not limited to unsolicited or unauthorized emails, spam, or other forms of unsolicited messages).
Do not test third parties that integrate with Prezi services (see the “What we are not interested in” section below for more details).
Do not operate directly or indirectly with malicious or harmful software. We like to keep clean for our users.
Don’t do anything that violates any applicable law.
Your participation in the Program is entirely voluntary. You acknowledge that Prezi has not offered or promised any reward or bounty payment for your participation in the Program. However, Prezi reserves the right to reward participation in the Program in its sole discretion on a case by case basis.
What we are not interested in
In general, please don’t report the following findings, unless you can showcase an actual vulnerability leading to significant impact:

CSRF vulnerabilities where exploitation is not really probable (other random / hard to get value is required for exploitation), CSRF in the authentication function
Missing “HTTP only” flag for cookies, which are not the following ones: auth-sessionid, prezi-auth, sessionid
Missing “Secure” flags for any cookie
Username / user id enumeration
Missing “X-Frame-Options”, “Strict-Transport-Security”, “Nosniff”, “X-Xss-Protection” headers
Phishing by navigating password tabs a.k.a "window.opener" (reason)
Absence of rate limiting
Denial of Service
User password brute force attack
"Leakage" of publicly available information (e.g.: server version info in response header)
Since our list of integrations might change, please always resolve our subdomains before any testing to verify that they are not pointing to some external / 3rd party service.

For example, the following domains and subdomains are pointing to different third-party solutions, which we are not authorized to include in this program:
Reporting security vulnerabilities
If you believe you have discovered a security vulnerability, please share the details with us by completing the form below.

We will acknowledge receipt of your report within five business days and work with you to understand the issue so we can validate it. We will also do our best to give an estimate on the resolution of the vulnerability and notify you when it is fixed.

Bug bounty programs / Puppet Bug Bounty
« on: May 16, 2023, 06:47:51 PM »
submit bug report:

Security Policy
Puppet supports coordinated disclosure of security vulnerabilities and welcomes reports from security researchers on issues found in Puppet products, and Puppet distributed packages or infrastructure.

Software version or banner disclosures
Directory traversal on yum, apt, or where traversal is explicitly desired
Self-XSS or CSRF on unauthenticated web forms (including logout CSRF)
Disclosure or discovery of known public files or directories (for example, robots.txt, simple DNS enumeration)
Brute force attempts (for example, log-in and forgot password pages don’t have lockouts)
Account enumeration (for example, enumerating login or reset fields for valid accounts without lockouts)
Email spoofing possibilities. Suggesting turning on SPF, DMARC, or DKIM isn’t welcome, though specific issues with those configurations are.
To report a vulnerability contact the Puppet security team at [email protected].

Contact the Puppet security team via encrypted communication using our PGP Public key:

Puppet Security Team
Key Long-format ID: 8728524FE21D3FC6
Key Fingerprint: 489C F9E6 BB24 2589 EFF5 BB68 8728 524F E21D 3FC6

The key is available in ASCII encoded format. It can also be retrieved and verified from the MIT Key Server.

We credit security researchers based on the value of the contributions they provide. The Puppet security team reviews each disclosure and assigns a scored value based on the relevance of the disclosure. These scores are calculated quarterly, and the top-scoring individuals are publicly credited on our website. Additional credit will be awarded to individuals who provide code fixes or additional information about how to fix the vulnerability.

Thank you for supporting Puppet’s coordinated disclosure process!

Bug bounty programs / Python Bug Bounty
« on: May 16, 2023, 06:46:27 PM »
submit bug report:

The Python Community
Great software is supported by great people. Our user base is enthusiastic, dedicated to encouraging use of the language, and committed to being diverse and friendly.

Bug bounty programs / QWANT Bug Bounty
« on: May 16, 2023, 06:43:35 PM »
submit bug report:

Program Ten commandments

• First commandment:

We Qwant, reserve us the right to cancel this program at any time and the decision to pay a reward is entirely at our discretion.

• Second commandment:

Thou shalt not disrupt any service or compromise personal data.

• Third commandement:

Thou shalt not publicly disclose a bug before it has been fixed. Thou shalt also be the first person to responsibly disclose the bug.

• Forth commandment:

Thou shalt not be an actual or a past employee of QWANT to join the program.

• Fifth commandment:

Thou shalt not use bruteforcing or scanners tools nor performs Denial of Service tentatives on the platform.

• Sixth commandment:

Thou shalt not violate any local, state, national or international law.

• Seventh commandment:

Thou shalt stay in the defined scope.

• Eighth commandment:

Thou shalt not perform physical attacks against Qwant's employees, offices or datacenter.

• Ninth commandment:

Thou shalt have fun and drink some beers while snooping around for vulnerabilities.

• Tenth commendment:

Thy participation to this program will constitute acceptance of these rules.

Any failure to comply with these rules will be sanctioned by the exclusion of the hunter from the bug-bounty program and even worse (legal pursuits, ...).


Qwant will offer a minimum reward of 100€. There is no maximum reward as it will be determined by Qwant security team according to the level of criticity and impact of the reported vulnerability.

Any non-security related issue (bug, wrong interface/API behavior, ...) will not be eligible for a money reward and should be sent to

Qualifying vulnerabilities

• Authentication bypass

• User session compartmentalization issue

• SQL / NoSQL injections

• Remote code execution or information leakage through XML external entities

• Reflected / persistent Cross-site scripting

• Cross-site request forgery

• Server-side request forgery

• Remote code execution on Qwant servers through memory corruption, command injection or other exploitation technique

• Any vulnerability in defined scope that could impact security of the platorm and its users

Non-qualifying issues

• Issues outside of defined scope

• Duplicate issue

• CSRF in login or logout

• Social engineering or shoulder-surfing on Qwant's employees

• Security bugs in third-party websites that integrate with Qwant

• Spam or exploit-kit in search results (URLs that bypasses Qwant's anti-malware solutions)

• Password complexity or any other issue related to account or password policies

• Missing/invalid HTTP headers

• Cookie flags

• Clickjacking

• Denial of service

• Results from pivoting or scanning internals systems

• SSL/TLS issues

• Accounts enumeration

• SPF/DKIM issues

• Issues with no security impact

• Issues impacting protocols or software not developed nor maintained by Qwant

• Rate-limit issues

• Forms missing CSRF tokens

• Text injection

• Content spoofing

• Forms missing Catpcha

• Homograph attacks

• Bypasses of results filters

• Client-side Issues impacting specific browsers

• Any Adobe Flash / SWF related issues

• Account policies related issues (token expiration, reset link, password complexity)

• Self-exploitation

Update 07/11/2016
Non-qualifying issues additions

• += Rate-limit issues
• += Forms missing CSRF tokens
• += Text injection
• += Content spoofing
• += Forms missing Catpcha
• += Homograph attacks
• += Bypasses of results filters
• += Client-side Issues impacting specific browsers
• += Any Adobe Flash /SWF related issues
• += Account policies related issues (token expiration, reset link, password complexity)
• += Self-exploitation

Bug bounty programs / QIWI Bug Bounty
« on: May 16, 2023, 06:42:16 PM »
submit bug report:


Qiwi Bug Bounty Program
We currently do not accept new reports.
• qiwi kiosks
•  Visa Qiwi Wallet mobile apps for iOS, Android
• *
• *
• *
• *
• *
• (only High and Critical severity server-side)
• * ( only High and Critical severity server-side)
• *
• * (except for issues with rate limits)
• * (except for issues with rate limits)
We do not accept/review reports with:
• Rate limits (including lack of captcha, etc) on domains, and their subdomains
• Vulnerability scanners and other automated tools reports
• Reports based on product/protocol version without demonstration of real vulnerability presence, except for vulnerabilities with a CVSS v3 score 7+
• Reports of missed protection mechanism / inconsistent with best practices (e.g. no CSRF token, framing/clickjacking protection) without demonstration of real security impact for user or system
• framing, clickjacking;
• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner);
• Self-XSS;
• Logout CSRF;
• Host header Injection;
• Reports regarding public availability of and
• SPF misconfiguration;
• Text-injection based on server error page;
How do I submit a bug report?
A bug report must give a detailed description of the discovered vulnerability:
• vulnerable hosts;
• the type of vulnerability;
• where exactly;
• security impact;
• steps impact;
• recommendations for fixing.
Reward payment and amounts.
We will pay you a reward if you are the first person to report a given vulnerability.  The amounts mentioned in the table below are approximate and may vary from vulnerability influence.
We are interested  the following  vulnerabilities criteria:
• possible use of the vulnerability
• on what service vulnerability found;
• value of financial, reputational and other risks from vulnerabilities.
Payments will be made through HackerOne.
Number of bug reports by one person of the Program is unlimited.
Also, public 0-day/1-day vulnerabilities may be considered as a duplicate within few days after vulnerability details publication, if vulnerability is known to our team from public sources and we are working to mitigate or patch it.
Qiwi Responsible Disclosure Policy
By submitting a bug report you agree to comply with Qiwi Responsible Disclosure Policy, which forbids public or private disclosure of the details of any vulnerability found on Qiwi within 90 days after vulnerability is fixed and only reciprocal agreement of the parties.
Qiwi employees, the employees in any of Qiwi companies group can't participate in the Qiwi Bug Bounty Program.

Bug bounty programs / Qmail Bug Bounty
« on: May 16, 2023, 06:39:44 PM »
submit bug report:

The qmail security guarantee
In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account.
My offer still stands. Nobody has found any security holes in qmail.

Of course, ``security hole in qmail'' does not include problems outside of qmail: for example, NFS security problems, TCP/IP security problems, DNS security problems, bugs in scripts run from .forward files, and operating system bugs generally. It's silly to blame a problem on qmail if the system was already vulnerable before qmail was installed! I also specifically disallowed denial-of-service attacks: they are present in every MTA, widely documented, and very hard to fix without a massive overhaul of several major protocols. (UNIX does offer some tools to prevent local denial-of-service attacks; see my resource exhaustion page for more information. See also my page responding to Wietse Venema's slander.)

A group of qmail users offered a $1000 prize for one year under similar rules. The prize was not claimed; the money was donated to the Free Software Foundation.

In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.

Why is qmail secure?
The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:
Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk. Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.
As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.
I followed seven fundamental rules in the design and implementation of qmail:

Programs and files are not addresses. Don't treat them as addresses.
sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

Do as little as possible in setuid programs.
A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

Do as little as possible as root.
The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

Move separate functions into mutually untrusting programs.
Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.

(From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)

Don't parse.
I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.

The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.

When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.

This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.

In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.

All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.

Keep it simple, stupid.
See BLURB in the qmail package for some of the reasons that qmail is so much smaller than sendmail. There's nothing inherently complicated about writing a mailer. (Except RFC 822 support; but that's only in qmail-inject.) Security holes can't show up in features that don't exist.

Write bug-free code.
I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I've been developing for several years for a variety of applications. The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.

Bug bounty programs / Qualcomm Bug Bounty
« on: May 16, 2023, 06:36:33 PM »
submit bug report:

Report a Bug
Qualcomm takes security very seriously and we strive to address any security-related issues quickly and appropriately. If you have found a potential security issue in any Qualcomm product or software, please contact us via email: [email protected]. Or click the button below and use our form to contact us. For encrypted communication, you may use our public key.

Bug bounty programs / Quantstamp Bug Bounty
« on: May 16, 2023, 06:34:38 PM »
submit bug report:

Our Responsible Disclosure Policy
Quantstamp holds deeply the trust that our customers and business partners place in us. Therefore, the security of our platform is of utmost importance to us. If you are a security researcher and have discovered a security vulnerability in one of our services, products, programs, or protocols, we appreciate your help in disclosing it to us in a responsible manner. Quantstamp will engage with security researchers when potential vulnerabilities are reported to us in accordance with this policy. We will validate and remediate vulnerabilities in accordance with this policy. Quantstamp reserves all of its legal rights in the event of any noncompliance.

Quantstamp runs a bug bounty program for many of our services, subject to modification or cancellation at our discretion from time to time. We encourage security researchers to share the details of any suspected vulnerabilities with us by sending an email to [email protected], which will be treated as Submissions via the Site. In reporting any suspected vulnerabilities via email or the Site, please include the following information:

Detailed information with steps for us to reproduce the vulnerability
Your email address
Understand that all valid reports will be taken seriously by our engineering teams
Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of our services (including Denial of Service)
Comply with all applicable laws
We will only reward the first report of a vulnerability. Public disclosure of the vulnerability prior to resolution may cancel a pending reward. We reserve the right to disqualify individuals from the program for disrespectful or disruptive behaviour.
We will not negotiate in response to duress or threats (e.g. we will not negotiate the payout amount under threat of withholding the vulnerability, or of releasing the vulnerability or any exposed data to the public).

Bug bounty programs / Quantopian Bug Bounty
« on: May 16, 2023, 06:33:31 PM »
submit bug report:


What is Quantopian?
Quantopian inspires talented people everywhere to write investment algorithms. Select authors may license their algorithms to us and get paid based on performance.
At the heart of Quantopian is a Python algorithmic trading platform called Zipline. Our members' Python code running on our platform presents a unique security challenge.
Our highest security priority is protecting the private data and intellectual property of our members and the funds the partners who invest money through us.
What to report ... here's your blueprint
IMPORTANT: Any account created at for security testing should have the string "hackerone" somewhere in the local part of its email address, i.e., the part before the "@". On many email platforms you can achieve this by appending "+hackerone" to the end of your username. The reason for this is explained in the description of the scope, below.
Please try to include the following on your reports:
The Basics
Subject line - What type of issue are you reporting, e.g., XSS, CSRF, authentication bypass, etc.?
Is it a known issue in a third-party component, e.g., does it have an assigned CVE number?
What are the specific steps for reproducing the issue?
--> We need more! <--
What is the impact of the issue?
How might an attacker leverage the issue? Show a proof-of-concept exploit or detailed instructions for leveraging the vulnerability to actually compromise the security of our site.
Do you have suggestions on how we should fix the issue? We want to know.
Things NOT to do
DO NOT submit more than 15 requests per minute. If your testing causes downtime, you run the risk of being ineligible to submit to the Quantopian program.
While researching, please refrain from:
Actions which might overwhelm our resources or cause a denial of service to others, for example, flooding our servers with requests or submitting meaningless support inquiries (generally speaking, we discourage the use of automated scanners by researchers, but if you must use automated tools, please ensure that they do not submit more than 15 requests per minute);
Actions which cause emails to be sent to our members (note: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members);
Accessing the private intellectual property or data of Quantopian or its members (e.g., if you are testing account security bypasses, please use test accounts you've created); or
Social engineering (including phishing) of Quantopian employees or users.
How to reach us
You can always email secur[email protected] with questions or concerns about our program.
Testing our algorithm execution environment
Please notify [email protected] in advance if you intend to probe the security of our algorithm code execution environment, so that we can respond appropriately if our monitoring detects and notifies us about your testing or your testing triggers our automated guards.
Please don't submit reports about:
xmlrpc.php on our blog; we know it's enabled and we are not going to disable it;
CSRF on, unless your proof-of-concept is successful when you've removed the CSRF token from both the cookie and the hidden form field in the submission;
attacks requiring physical access to a member's or employee's device;
attacks requiring a member's or employee's device to be compromised by malware, a rootkit, etc;
third-party platforms and services hosting our resources or employed by them;
social engineering;
security vulnerabilities in third-party components made public within the past 14 days;
issues that you have not actually confirmed are present on our site;
issues without a clearly defined security impact; or
other resources outside the scope of this program and not in control of Quantopian.
Rate Limit Exclusions
We are not interested in any issues pertaining to our site's default rate limits unless there is a specific user-facing impact to that limit. We strive to keep our rate limits out of the minds of our users, so we have intentionally made them rather lenient.
The only rate limit related reports we will review must have an impact beyond Denial-of-Service attacks. Examples:
A rate limit that is too low on a function that sends notifications to users
Any sort of intellectual property theft from another user
Any testing of our rate limits should stay within our 15 requests-per-minute guideline. This is below our overall site rate limit, but should be sufficient for testing issues with extra impact (such as the examples above).
Any rate limit testing of site behaviors that send notifications to Quantopian employees must be approved by Quantopian program administrators first.
Bounty Rewards
Our bounties usually range from $100 to $5,000. We rate reported vulnerabilities in five categories; these ratings are combined formulaically to arrive at a bounty amount. In some circumstances, we may find it necessary adjust the bounty amount determined by our formula, but we try to stick with the formula's results whenever possible.
Show greater impact = increase your bounty! Here's how it's done ...
0 = No impact and 4 = Critical
Difficulty of discovery
0 ”cookie-cutter” vulnerability, or one that is tested automatically by widely available tools.
1 easy to stumble across in normal usage of the site
2 easy to find if you are looking for it
3 requires work to discover and in-depth knowledge
4 requires work to discover and in-depth knowledge to understand
Ease of exploitation
0 impossible to exploit in any meaningful way
1 impossible to exploit unless combined with another vulnerability
2 extremely hard to exploit
3 straightforward but not easy to exploit
4 extremely easy to exploit
Impact on members who write, test, and trade algorithms through quantopian
0 no user impact
1 very little likely impact, almost not a security issue
2 compromise user private data but not their intellectual property
3 compromise user intellectual property
4 complete user account takeover
Impact on Quantopian’s money-management business
0 no impact.
1 very little likely impact, almost not a security issue
2 localized compromise of data
3 broad compromise of data
4 compromise of money
0 exploitation would definitely be detected and thwarted quickly without damage or disruption
1 would be detected and thwarted eventually without site disruption
2 could go undetected or site disruption would be necessary to stop it
3 could go undetected and site disruption would be necessary to stop it
4 would likely go undetected for a long time
The rating scales above are provided only for informational purposes. Reported vulnerabilities are rated by us, not by the researchers reporting them. When reporting a vulnerability to us, you should not attempt to rate it according to the scales above. If you believe that we have misunderstood the scope or severity of a vulnerability, we encourage you to explain why; however, its severity rating is solely at our discretion and not up for debate.
Real examples of previous vulnerabilitiesnote: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members
Please check out some of our previous reports to better understand how to explain the impact of your find and earn higher bounties.
World-writable S3 bucket used for deployment of Python wheels to our application servers. A bad actor could have tampered with the wheels in this bucket to introduce malicious code onto our servers. We ranked this report 3 out of 4 on ease of discovery, 2/4 on exploitability, 4/4 on user impact, 4/4 on fund impact, and 3/4 on stealthiness, resulting in a bounty of $3,125.
Authorization not being enforced properly for collaboration. A bad actor could have exploited this vulnerability to gain access to the chat sessions and portions of the algorithm source code of other users' collaboration-enabled algorithms. We ranked this report 4/4 on ease of discovery, 2/4 on exploitability, 3/4 on user impact, 2/4 on fund impact, and 3/4 on stealthiness, resulting in a bounty of $2,425.
Stored XSS in algorithm name when a collaborator attempts to delete the algorithm. A bad actor would have had to insert XSS code into the algorithm title (which would have been visible to the collaborator) and then somehow get the collaborator to attempt to delete the algorithm. We ranked this report 3/4 on ease of discovery, 2/4 on exploitability, 3/4 on user impact, 1/4 on fund impact, and 2/4 on stealthiness, resulting in a bounty of $1,500.
Rate limiting on account confirmation emails not working. A bad actor could have exploited this to flood any email address with emails from Quantopian and in the process run up Quantopian's bill with our email service provider. We ranked this report 2/4 on discoverability, 3/4 on exploitability, 1/4 on user impact, 0/4 on fund impact, and 0/4 on stealthiness, resulting in a bounty of $325.
We usually send an initial response to vulnerability reports within two business days. Feel free to ping us if you don't hear back within two days of submitting a report.
We triage most reports, i.e., reproduce them and determine their severity, before our initial response. If we are unable to do so, our initial response includes either an estimate of when we believe we will be able to triage it, or a request for additional information we need from the reporter.
We try to pay the bounty for a report within 30 days of our severity determination or within 7 days after we have closed the vulnerability, whichever is sooner. If we're late, please let us know.
While we are grateful to everyone who submits vulnerability reports to us, reports must satisfy the following criteria to be eligible for a bounty:
You must follow all of the rules and conditions outlined in the HackerOne disclosure guidelines.
The first report of a vulnerability is always considered for a bounty; subsequent, duplicate reports are considered on a case-by-case basis.
You may not publicly disclose a reported vulnerability prior to us resolving it.
Fine print
Bounties are paid at our sole and complete discretion, and we reserve the right not to pay a bounty for an eligible report, for any reason or no reason.
We may modify the terms of this program or terminate the program at any time without prior notice.
→ Please only submit reports about actual vulnerabilities with a clearly defined security impact. ←
Here is what that means:
Please do not submit reports of the type, "I ran this security scanner on your site and it says your site is vulnerable to X, so it must be vulnerable to X!" Security scanners return false positives all the time.
Please do not submit reports of the type, "I'm reading this script off of the internet which says to check for X in responses from a web server, and your server returns X, so it must be vulnerable."
For a report to be useful to us, it must:
indicate that the reporter fully understands the issue being reported and is not just cribbing it from a scanner or web page; and
include a proof-of-concept exploit or detailed instructions for leveraging the vulnerability to actually compromise the security of our site.
Furthermore, please note that we specifically do not wish to receive reports about:
the fact that you are able to enumerate usernames on our blog. This is not a security vulnerability;
the fact that xmlrpc.php is accessible on our blog. We use it, and we're not going to remove it;
CSRF tokens failing to be checked because you removed the CSRF token from your request and the request was processed anyway; this is because our site embeds the CSRF token in both the request header and the form contents, and you removed it from one of those locations but not the other;
issues related to; it's hosted by, not by us, so if there are any security issues there, report it to them, not us;
attacks requiring physical access to a member's or employee's device;
attacks requiring a member's or employee's device to be compromised by malware, a rootkit, etc;
third-party platforms and services hosting our resources or employed by them;
social engineering;
security vulnerabilities in third-party components made public within the past 14 days; or
to reiterate what is written above, any report without a clearly defined security impact and a proof-of-concept or detailed exploit instructions.
When submitting reports via email:
Please use meaningful subject lines which, for example, mention what kind of vulnerability you are reporting and the affected application component. Please do not use generic subject lines like "security issue" or "bug bounty".
Please do not send us large email messages (>~1MB). If you need to email us a large file, please upload it to a file-sharing service and send us a link.
While researching, please refrain from:
actions which might overwhelm our resources or cause a denial of service to others, for example, flooding our servers with requests or submitting meaningless support inquiries (generally speaking, we discourage the use of automated scanners by researchers, but if you must use automated tools, please ensure that they do not submit more than 15 requests per minute);
actions which cause emails to be sent to our members (note: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members);
accessing the private intellectual property or data of Quantopian or its members (e.g., if you are testing account security bypasses, please use test accounts you've created); or
social engineering (including phishing) of Quantopian employees or users.

Bug bounty programs / Quest Bug Bounty
« on: May 16, 2023, 06:32:22 PM »
submit bug report:

Contact Us

If you are experiencing technical issues with your product create a technical request.
If you would like to purchase additional licenses or for pricing information, please contact your Sales Rep.
If you would like to renew your existing license, please contact Renewals.

Bug bounty programs / RBS Bug Bounty
« on: May 16, 2023, 06:26:44 PM »
submit bug bounty:

Reporting a Security Vulnerability
Our fundamental purpose is to keep our customers safe and secure and that’s why we at Royal Bank of Scotland take the security of our systems seriously.

If you have identified a potential vulnerability, please reach out to us via our Responsible Disclosure Programme – managed by Bugcrowd. Any submissions must be made through Bugcrowd and submitted on their platform.

NatWest Group will not accept submissions that have been found through the use of malignant or illegitimate means - If our Security Operations Centre identify your actions as malicious this will be treated as an attack and not a Responsible Disclosure submission.

Before submitting your finding please read over the terms and scope, and submit here.

Bug bounty programs / RSK DevPortal Bug Bounty
« on: May 16, 2023, 06:24:44 PM »
submit bug report:

Bug Bounty Program
IOVLabs has created this bug bounty program to reward security researchers that dedicate time and effort to improve the IOVLabs platforms.

Bug bounty programs / Rackspace Bug Bounty
« on: May 16, 2023, 06:21:50 PM »
submit bug report:

We've designed our infrastructure and services for security, to protect our customers and their data. But if you discover a security vulnerability with any of our products, control panels, or other infrastructure, we want to know.

Reporting process

Security issues within our product offerings take a very high priority. We want to work with you to understand the scope of the vulnerability and ensure that we correct the problem fully.

1. Report a vulnerability by notifying us at [email protected]. (If needed, you can encrypt your email using our public PGP key.) Please provide detailed information about the following:

The product, control panel, or infrastructure involved.
The steps required to reproduce the issue as well as any scripts or screenshots, if possible.
The impact of the vulnerability and how it can be exploited.
2. Once we receive your report, we will contact you to confirm we have received it within 5 business days.

3. Please do not post or share any information about a potential security vulnerability in any public setting until we have researched, responded to, and addressed the reported vulnerability and informed customers, if needed. Our products are complex, and reported security vulnerabilities will take time to investigate, address, and fix.

4) Rackspace does not have a monetary bug bounty program. For responsibly disclosed, new vulnerabilities, we have a hall of fame that can be found on this page.

Remember to use discretion when reporting issues and respect our customers’ and users’ data and privacy. Note that Rackspace may not be responsible for customer vulnerabilities. If you are unsure, let us know.

Security disclosure and notifications

For the protection of our customers, Rackspace Technology does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches, fixes, or releases are available. Rackspace Technology usually distributes security disclosures and notifications through blog posts and customer support portals.

Keeping our community safe

We would like to acknowledge the following people who have responsibly disclosed security vulnerabilities in the past. Thank you for your help in keeping our community safe.

Tom Maher
Daksh Patel*
Koutrouss Naddara
Kamil Sevi
Osanda Malith Jayathissa*
Rodolfo Godalle, Jr.
Sabari Selvan
Tikarye Ashish B.
Gurjant Singh Sadhra
Ishan Anand
Jayvardhan Singh
Ciaran McNally
Ketan Sirigiri
Sangeetha Rajesh S
Scott Glossop
Yasir Zargar
Joel Parker Henderson
Zeel Chavda
Noman Shaikh
Rishabh Sharma*
Shawar Khan
Zee Shan
Prial Islam
Zika Ds
Piyush Soni
Macall Salugsugan
Vineet Kumar
Andrew Stucki
Ben Leonard-Lagarde
Maksym Bendeberia (Websafety Ninja)
R Atikislam
Robbie Wiggins
Salonee Jaiswal
Pranav Bhandari
Ken Nevers @k3nundrum (Red Sea Information Security)
Aman Deep Singh Chawla
Quang Vu Dinh @vudq16 (NCSC VietNam)
Varun Gupta
John Moss (7 Elements)
Subhasish Mukherjee
Apoorva Jois
Pratik Dabhi LinkedIn / Twitter
K Mohammed Danish Faraz LinkedIn / Twitter
Ibrahim Saud M LinkedIn / Twitter
Wesley Kirkland LinkedIn
Pritam Mukherjee
Sadik Shaikh
Yunus Yıldırım
Shiraz Ali Khan
Ahmed Salah Abdalhfaz
Guillermo Gregorio
Ivan Pellino
Gourab Sadhukhan
Divya Singh
Cameron Walsh
Akash Rajendra Patil
Isa Ghojaria
Shubham Garg
Prince Prafull
Foysal Ahmed Fahim*
Harinder Singh (S1N6H)
Noah Wilcox
Abdullah Mudzakir
Mohammad Sleaman Ahmad (HamaGold)
Marcin Bukowski (
Joao Paulo Figueiredo Guedes
Ramansh Sharma
* Indicates two or more vulnerabilities have been reported

Note: While we sincerely appreciate reports for vulnerabilities of all severity levels, this listing is reserved for people who have reported previously unknown vulnerabilities, which Rackspace Technology has determined to be of a high or critical severity, or in cases where there has been continued research or other contributions made by the person.

Having trouble with an account?

If you’re a Rackspace Technology customer and you’re having difficulty accessing your account, or if you believe your account has been accessed without your authorization, please contact your support team.

Bug bounty programs / Ratelimited Bug Bounty
« on: May 16, 2023, 06:18:19 PM »
submit bug report:

Pages: [1] 2 3 ... 15