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.

Bounty Qualification

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.

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.

Submission Process

• Disclose a previously unknown security vulnerability directly to the project maintainers.
• Follow the disclosure process established by the project maintainers.
• Clearly demonstrate the security vulnerability. Respect the time of the project volunteers as they cannot invest significant effort into incomplete reports. Low-quality reports may be disqualified.
• Once a public security advisory has been issued, please submit a report here. You must not send us the details of the vulnerability until it has been validated, accepted, and publicly disclosed by the project maintainers.

When should you report to security@python.org?

Depending on the risk of the issue, sometimes security@python.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.

Public disclosure preferred

In issue #27863, several problems such as use-after-free, and out-of-bound memory access in module elementtree were 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.

Private disclosure preferred

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 expat and elementtree. 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).