https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 23:32:23 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-05132 bdu:2026-05132 https://cve.radiocsirt.org/vuln/bdu:2026-05132 https://cve.radiocsirt.org/vuln/bell-cve-2025-12781 <p><strong>Affected:</strong> Alpaquita:23: python3, Alpaquita:25: python3, Alpaquita:stream: python3, BellSoft Hardened Containers:23: python3, BellSoft Hardened Containers:25: python3, BellSoft Hardened Containers:stream: python3</p> <p><strong>Affected:</strong> Alpaquita:23: python3, Alpaquita:25: python3, Alpaquita:stream: python3, BellSoft Hardened Containers:23: python3, BellSoft Hardened Containers:25: python3, BellSoft Hardened Containers:stream: python3</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-12781 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0079 certfr-2026-avi-0079 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0079 https://cve.radiocsirt.org/vuln/euvd-2026-266388 EUVD-2026-266388 https://cve.radiocsirt.org/vuln/euvd-2026-266388 https://cve.radiocsirt.org/vuln/fkie_cve-2025-12781 <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &#34;+/&#34;). If your application does not use the &#34;altchars&#34; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &#34;+/&#34;). If your application does not use the &#34;altchars&#34; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-12781 https://cve.radiocsirt.org/vuln/ghsa-hfpw-x3fg-wmmg <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &#34;+/&#34;). If your application does not use the &#34;altchars&#34; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &#34;+/&#34;). If your application does not use the &#34;altchars&#34; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> https://cve.radiocsirt.org/vuln/ghsa-hfpw-x3fg-wmmg https://cve.radiocsirt.org/vuln/oesa-2026-1356 <p><strong>Affected:</strong> openEuler:24.03-LTS: python3</p> <p>Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems. New built-in modules are easily written in C or C++ (or other languages, depending on the chosen implementation). Python is also usable as an extension language for applications written in other languages that need easy-to-use scripting or automation interfaces. Security Fix(es):</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &amp;quot;base64&amp;quot; module the characters &amp;quot;+/&amp;quot; will always be accepted, regardless of the value of &amp;quot;altchars&amp;quot; parameter, typically used to establish an &amp;quot;alternative base64 alphabet&amp;quot; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &amp;quot;+/&amp;quot;). If your application does not use the &amp;quot;altchars&amp;quot; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>The attached patches DOES NOT make the base64-decode behavior raise an error…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: python3</p> <p>Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems. New built-in modules are easily written in C or C++ (or other languages, depending on the chosen implementation). Python is also usable as an extension language for applications written in other languages that need easy-to-use scripting or automation interfaces. Security Fix(es):</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &amp;quot;base64&amp;quot; module the characters &amp;quot;+/&amp;quot; will always be accepted, regardless of the value of &amp;quot;altchars&amp;quot; parameter, typically used to establish an &amp;quot;alternative base64 alphabet&amp;quot; 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.</p> <p>This behavior can only be insecure if your application uses an alternate base64 alphabet (without &amp;quot;+/&amp;quot;). If your application does not use the &amp;quot;altchars&amp;quot; parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.</p> <p>The attached patches DOES NOT make the base64-decode behavior raise an error…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1356 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10206-1 <p>python314-3.14.3-1.1 on GA media</p> <p>python314-3.14.3-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10206-1 https://cve.radiocsirt.org/vuln/suse-su-2026:20665-1 <p>Security update for python311</p> <p>Security update for python311</p> https://cve.radiocsirt.org/vuln/suse-su-2026:20665-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-12781 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: python2.7, Ubuntu:Pro:14.04:LTS: python3.4, Ubuntu:Pro:14.04:LTS: python3.5, Ubuntu:Pro:16.04:LTS: python2.7, Ubuntu:Pro:16.04:LTS: python3.5, Ubuntu:Pro:18.04:LTS: python2.7, Ubuntu:Pro:18.04:LTS: python3.6, Ubuntu:Pro:18.04:LTS: python3.7, Ubuntu:Pro:18.04:LTS: python3.8, Ubuntu:Pro:20.04:LTS: python3.8 and 14 more</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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 &#34;+/&#34;). If your application does not use the &#34;altchars&#34; 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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: python2.7, Ubuntu:Pro:14.04:LTS: python3.4, Ubuntu:Pro:14.04:LTS: python3.5, Ubuntu:Pro:16.04:LTS: python2.7, Ubuntu:Pro:16.04:LTS: python3.5, Ubuntu:Pro:18.04:LTS: python2.7, Ubuntu:Pro:18.04:LTS: python3.6, Ubuntu:Pro:18.04:LTS: python3.7, Ubuntu:Pro:18.04:LTS: python3.8, Ubuntu:Pro:20.04:LTS: python3.8 and 14 more</p> <p>When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the &#34;base64&#34; module the characters &#34;+/&#34; will always be accepted, regardless of the value of &#34;altchars&#34; parameter, typically used to establish an &#34;alternative base64 alphabet&#34; 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 &#34;+/&#34;). If your application does not use the &#34;altchars&#34; 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 &#34;+&#34; or &#34;/&#34; outside of altchars.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-12781 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0196 <p>Ein Angreifer kann eine Schwachstelle in CPython bezüglich Base64 Daten ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann eine Schwachstelle in CPython bezüglich Base64 Daten ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0196