Notice: While JavaScript is not essential for this website, your interaction with the content will be limited. Please turn JavaScript on for the full experience.

Python Security

Reporting security issues with PyPI or a project hosted on PyPI

See the security issue information for pypi.org here

Reporting security issues in Python, cPython, or python.org

The Python Software Foundation and the Python developer community take security vulnerabilities very seriously. A Python Security Response Team has been formed that does triage on all reported vulnerabilities and recommends appropriate countermeasures. To reach the response team, send email to security at python dot org. Only the response team members will see your email, and it will be treated confidentially.

The PSRT mailing list is tightly controlled, so you can have confidence that your security issue will only be read by a highly trusted cabal of Python developers. If for some reason you wish to further encrypt your message to this mailing list (for example, if your mail system does not use TLS), you can use our shared OpenPGP key which is also available on the public keyservers. Key fingerprint:

pub   2048R/D067453C 2010-09-08
      Key fingerprint = F314 452F E3F9 BF87 0435  7732 D273 E0FF D067 453C
uid                  Python Security Response Team <security@python.org>
sub   2048R/0953421B 2010-09-08

Key data:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mQENBEyH8KIBCADLe9mczGnhhLFBbxWDgxHzzr/eExGuVQb+VYsa0WDZG4z/y+Kx
KsZ8da/adKaiig2soQJiZtYb6w1JDtugwy8+ySDY8ECAB7qdGK6gB17P1UFsI93d
IAe25DdEybbi0sMPbw0Q5Ka+ihI1ZnPifyG0oLK901QfTutOYAk42J7V/p6fHzK+
pCeOri+aSGlWxVtC03iPNIiL5InfKPCEvZ5ih8/98hCqccp6teDaGxhnab+5GYZq
wDknmK230r5UWd/VlGSiC4DJCuE+GY1r1DXx+E/ANjeMZOXQ4kBMxp8aFz7k1vFX
Mbqv+TWD+BZzgu6Fa4KCgWW7Jn1syKpwA7ahABEBAAG0M1B5dGhvbiBTZWN1cml0
eSBSZXNwb25zZSBUZWFtIDxzZWN1cml0eUBweXRob24ub3JnPokBOAQTAQIAIgUC
TIfwogIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ0nPg/9BnRTwRowf+
IN0rG5Gj/quhfhS0CyqoYYu3H9I8WDSw9I7GjVQY0KZAbYEmNbZ/Kmwa59opXoIG
Kfo2KEDVwADf17vpdIER9bcpFF0fPFnAGI1XWQKkZX8uckB4TkEQvxZpLjD14XX8
eFMXwLBc3IGMYRJUIgEC5C2/TkaCc5qgTw0P8tCd7JNgey+Ogf1KE0ks34MKsXD4
xV4WS2Kfu2HjoAURhqQHr3Ug5kFKIHAeKY7EAVUvGp6r4uMCsAWKKUWUZfYSpH7+
UAWOtxEbDpDt5IrmOI2V60X3qGaNMxF+wQc/MpM+L1BN4bdf6dlB3u6gHkixdoMl
Yh6/T7NZMZ3HKV3RC5hf6IkCHAQQAQgABgUCTIf47gAKCRASbrVjp0sGv5+9D/wI
aR0a/S5lin5FfNUCLL528+aJlV0XHMrugPrwB8jOdM3367ORgHxx3qHcgLJuoBRn
zQ1v1SaqvN4TvQ1tDtS5+lsCSBjCpzMQxcZY6VMm59ulZ80PHsOqYVj5ev8KHq/h
pDAHSCvnE52MUKNm33+SJ2q6KLGs0hb3HL2RBEX9f9+3XCLdOlbETPiQIipN2jx3
QFhcIZTAlVOY7R3ENrFNx8pmK5Dpsu7vchPEDl4ssfnQom9mTU5en9Ix7UDSTNLC
XmMxvaoafRYgBH9rzXJgHvHO/37uE/2PstTF0h40Vl0UoNSqr2aKN1fR0DJgr4A4
aiOyaHCXvPanVuNcW4FJYiO9QlYQfZvjvGtazqRSc+WzuKDYfKYpRgcYsSAUz1DI
0voJ/oaaQ8XcTeW5l8P6AlFfYCJ/yqKOL4lQ5qM64So4MuQyplos/LvqKTt9MYPt
2MjEwa7n5++YWKIYMywb2A7KXymav6yf+kMLRpymQweH5f8ZHoR1mSs4Ac5HpZ1M
COtGrHRY6iWw/5SLkm+INm6jqo1bU0Vzm/2ju4omie68jVkv9byoGcrty9xookfA
+fHCVx8LV4hBFWcCKmH7NFWY8Iq3UgrbpHYal4vuOJlmEMZayHRJ4dtEZTD/kGul
gQL/xmVVGLtNGCvodmcx5VU8QAUBr0p0dWX79yVlCLkBDQRMh/CiAQgAsWKEEJTn
D+pf0zZc1bt0fHNLEk36G+aHMK77LzhPpeAOCm3296vjjoKy99OAKuyKMVFY59nK
zZ3lXvP89yuxgJwWJM7uf0iZ0njo1DPxyZ1jldPiZEiXhShwDNAQR3EkP8IvilsV
3BKcWO/E6wCiMLQFpWDlPdTw7v3LwGnDNk6AmU6Jiy0tbraNyq7USIu+80yUcJ/K
HYXPgx0ZEZIWhQKonekN+AhpJaSOUPVeYdxMwj3ZSHOTfzORXVnjbscPnfStz5F6
fVnikDnSZYgOauaJCEwqVEpdxM9O7wuRsZf4UGN13wMMbRnEDnmt2VBsNK2NNqvQ
UcimMcbO9y2V5wARAQABiQEfBBgBAgAJBQJMh/CiAhsMAAoJENJz4P/QZ0U8KaMI
AIukbpQFcoVVzA/DbQhkCYkCdYYWXacC71xoq45mnM/gSDMGBaitZIX/ngvDLH7I
7tf+fOcIo0w+mPBuGQZfGHyYZ2Qv1DHgdYJC4U8ccftnzv6GxYxiwB6elVFgOrS8
8B5Y9GdUDzjO8ZF3zzdq0Hy4AN/cn+ybkDWDxwLncdM9FX39cHnEEmZE+u9qaacK
r/uhVveqbNOH9N6iwrp0Oc0D6Ktq9uU+sGC+6XBRhZlUT0yExyxEG1abpIIC1Kby
tQvO+Ejsx6fV55784qypqDyp7dtPHWCXD7mwI3zneYZbnV0nZvznBhNE4DqHuqvI
8C7KT7DjqaL3FVHdMtyrcPk=
=Z6PM
-----END PGP PUBLIC KEY BLOCK-----

Bug bounties

While we sincerely appreciate and encourage reports of suspected security problems in supported Python releases and the PSF web infrastructure, please note that the Python Software Foundation does not run any bug bounty programs. We are a nonprofit organization, depending on donation and support from the community.

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).