Логотип exploitDog
product: "python"
Консоль
Логотип exploitDog

exploitDog

product: "python"
Python

Pythonвысокоуровневый язык программирования общего назначения. Его философия дизайна делает акцент на читаемости кода.

Релизный цикл, информация об уязвимостях

Продукт: Python
Вендор: python

График релизов

3.103.113.123.133.1420212022202320242025202620272028202920302031

Недавние уязвимости Python

Количество 924

suse-cvrf логотип

SUSE-SU-2026:0802-1

21 день назад

Security update for python

EPSS: Низкий
suse-cvrf логотип

SUSE-SU-2026:0774-1

22 дня назад

Security update for python

EPSS: Низкий
rocky логотип

RLSA-2026:2419

около 1 месяца назад

Moderate: python3.12 security update

EPSS: Низкий
rocky логотип

RLSA-2026:1478

около 2 месяцев назад

Moderate: python3.9 security update

EPSS: Низкий
suse-cvrf логотип

SUSE-SU-2026:0337-1

около 2 месяцев назад

Security update for python

EPSS: Низкий
github логотип

GHSA-hfpw-x3fg-wmmg

2 месяца назад

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch dep...

CVSS3: 5.3
EPSS: Низкий
nvd логотип

CVE-2025-12781

2 месяца назад

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprec

CVSS3: 5.3
EPSS: Низкий
debian логотип

CVE-2025-12781

2 месяца назад

When passing data to the b64decode(), standard_b64decode(), and urlsaf ...

CVSS3: 5.3
EPSS: Низкий
ubuntu логотип

CVE-2025-12781

2 месяца назад

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates ...

CVSS3: 5.3
EPSS: Низкий
redhat логотип

CVE-2025-12781

2 месяца назад

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates ...

CVSS3: 5.3
EPSS: Низкий

Уязвимостей на страницу

Уязвимость
CVSS
EPSS
Опубликовано
1
suse-cvrf логотип
SUSE-SU-2026:0802-1

Security update for python

1%
Низкий
21 день назад
suse-cvrf логотип
SUSE-SU-2026:0774-1

Security update for python

1%
Низкий
22 дня назад
rocky логотип
RLSA-2026:2419

Moderate: python3.12 security update

0%
Низкий
около 1 месяца назад
rocky логотип
RLSA-2026:1478

Moderate: python3.9 security update

0%
Низкий
около 2 месяцев назад
suse-cvrf логотип
SUSE-SU-2026:0337-1

Security update for python

0%
Низкий
около 2 месяцев назад
github логотип
GHSA-hfpw-x3fg-wmmg

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch dep...

CVSS3: 5.3
0%
Низкий
2 месяца назад
nvd логотип
CVE-2025-12781

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprec

CVSS3: 5.3
0%
Низкий
2 месяца назад
debian логотип
CVE-2025-12781

When passing data to the b64decode(), standard_b64decode(), and urlsaf ...

CVSS3: 5.3
0%
Низкий
2 месяца назад
ubuntu логотип
CVE-2025-12781

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates ...

CVSS3: 5.3
0%
Низкий
2 месяца назад
redhat логотип
CVE-2025-12781

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues. This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet. The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates ...

CVSS3: 5.3
0%
Низкий
2 месяца назад

Уязвимостей на страницу


Поделиться