CVE-2025-12781
published 2026-01-21CVE-2025-12781: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be…
PriorityP429medium5.3CVSS 3.1
AVNACLPRNUINSUCNILAN
EPSS
0.51%
40.3th percentile
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 the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64
alphabet they are expecting or verify that their application would not be
affected if the b64decode() functions accepted "+" or "/" outside of altchars.
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | pypy3 | — | — |
| debian | python3.11 | — | — |
| debian | python3.13 | — | — |
| debian | python3.14 | — | — |
| debian | python3.9 | — | — |
| python | python | < 3.13.10 | 3.13.10 |
| python | python | — | — |
| python | python | >= 3.14.0 < 3.14.1 | 3.14.1 |
| python_software_foundation | cpython | < 3.13.10 | 3.13.10 |
| python_software_foundation | cpython | >= 3.14.0 < 3.14.1 | 3.14.1 |
| python_software_foundation | cpython | >= 3.15.0a1 < 3.15.0a2 | 3.15.0a2 |
CVSS provenance
nvdv3.15.3MEDIUMCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
nvdv4.06.3MEDIUMCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
osv6.3MEDIUM
vendor_debian6.3MEDIUM
vendor_redhat6.3MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
vendor_redhat·2026-01-21·CVSS 6.3
CVE-2025-12781 [MEDIUM] CWE-20 cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
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" parame
Debian
CVE-2025-12781: pypy3 - When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decod...
vendor_debian·2025·CVSS 6.3
CVE-2025-12781 [MEDIUM] CVE-2025-12781: pypy3 - When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decod...
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 alterna
OSV
CVE-2025-12781: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always b
osv·2026-01-21·CVSS 6.3
CVE-2025-12781 [MEDIUM] CVE-2025-12781: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always b
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 alterna
GHSA
GHSA-hfpw-x3fg-wmmg: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always b
ghsa_unreviewed·2026-01-21
CVE-2025-12781 [MEDIUM] CWE-704 GHSA-hfpw-x3fg-wmmg: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always b
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 alter
No detection rules found.
No public exploits indexed.
Wiz
CVE-2025-12781 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 6.3
CVE-2025-12781 [MEDIUM] CVE-2025-12781 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2025-12781 :
Python Interpreter vulnerability analysis and mitigation
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
Bugzilla
CVE-2025-12781 cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
bugzilla·2026-01-21·CVSS 5.3
CVE-2025-12781 [MEDIUM] CVE-2025-12781 cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
CVE-2025-12781 cpython: base64.b64decode() always accepts "+/" characters, despite setting altchars
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
https://github.com/python/cpython/commit/13360efd385d1a7d0659beba03787ea3d063ef9bhttps://github.com/python/cpython/commit/1be80bec7960f5ccd059e75f3dfbd45fca302947https://github.com/python/cpython/commit/9060b4abbe475591b6230b23c2afefeff26fcca5https://github.com/python/cpython/commit/e95e783dff443b68e8179fdb57737025bf02ba76https://github.com/python/cpython/commit/fd17ee026fa9b67f6288cbafe374a3e479fe03a5https://github.com/python/cpython/issues/125346https://github.com/python/cpython/pull/141128https://mail.python.org/archives/list/[email protected]/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/
2026-01-21
Published