The Internet Bug Bounty Panel is awarding bounties for critical security vulnerabilities in popular, open source programming languages. Thanks to the hard work of the developers of these languages, uncovering vulnerabilities in this software is increasingly challenging. These bounties are our way of saying "Thanks" to the security researchers who take up this challenge.
Only critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically Arbitrary Code Execution or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.
Impact | Amount
High Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved. | $1,500+
Medium Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register). | $1,000
Minimum Demonstrate the presence of a security bug with probable remote exploitation potential. | $500
Only vulnerabilities in the core Python programming language and standard library will be considered for eligibility. Submissions related to python.org and other project websites are explicitly NOT eligible.
The project maintainers have final decision on which issues constitute security vulnerabilities. The Panel will respect their decision, and we ask that you do as well.
It's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.
Depending on the risk of the issue, sometimes firstname.lastname@example.org might not be the best channel to report it.
The risk level is often determined by a product of the impact once exploited, and the probability of exploitation occurring. In other words, if a bug can cause great damage, but it takes highest privilege to exploit the bug, then the bug is not a high risk one. Similarly, if the bug is easily exploitable, but its impact is limited, then it is not a high risk issue either.
There is not any hard and fast rule to determine if a bug is worth reporting. The general rule is any attack worth reporting via the security address must allow an attacker to affect the confidentiality, integrity and availability of the Python application or its system for which the attacker does not already have the capability.
To illustrate the point, here are some examples of past issues and what the Python Security Response Team (PSRT) thinks of them. When in doubt, however, please do send us a report nonetheless. If the responder can't find any relevant exploitable code, the report may be re-posted publicly.
In issue #27863 __, several problems such
as use-after-free, and out-of-bound memory access in module
reported. However, the exploit cannot be provoked by providing it with XML
data. It requires that the attacker be able to provoke the execution of the
__getstate__ method, which is something an attacker would only be able to do
if they had the ability to execute arbitrary Python code, or, if they could
somehow coerce the application to pickle an XML tree. Neither of these are
generally possible from an unprivileged position.
Issue #272829 __is a double-free bug in
a highly critical builtin module
ssl. However, the bug requires an attacker
who can cause
PyWeakref_NewRef to fail, which means the ability to
deterministically exhaust memory at a specific point in C code execution.
While these are clearly important bugs to fix, and may, in some hypothetical situations, have a security impact, the only proof of concept the PSRT can imagine for any of them is to be able to execute arbitrary Python code. If you can already execute Python code, there are far worse things you can do than provoke a use-after-free or an interpreter crash.
Issue #7673 __is a security vulnerability that affect an obscure corner of the standard library but it is appropriate to disclose privately, because the APIs that it affects are ones designed to handle untrusted data, something that an attacker could plausibly get a Python program to consume with the expectation that it would be safe.
Issue #17239 __and #24238
__are similar security vulnerabilities
affecting multiple popular builtin modules such as
They allow an attacker to render a Python application unavailable by feeding
it malicious XML data.
The common theme of these vulnerabilities is they let the attacker escalate
privilege from unprivileged position. Arbitrary python code execution is the
highest level of privilege possible in the python interpreter. There are other
modules (such as
marshal) which explicitly say that all data must be taken
from only trusted sources (and hence privileged).
Contact us if you want more information.