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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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.
    (CVE-2025-12781)

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1773323311 advisory.

  - 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.
    (CVE-2025-12781)

  - When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a     malicious file can cause OOM and DoS issues (CVE-2025-13837)

  - If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when     expanding environment variables. (CVE-2025-6075)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1773136115 advisory.

  - 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.
    (CVE-2025-12781)

  - When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a     malicious file can cause OOM and DoS issues (CVE-2025-13837)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:0767-1 advisory.

    - CVE-2025-11468: header injection when folding a long comment in an email header containing exclusively     unfoldable       characters (bsc#1257029).
    - CVE-2025-12781: inadequate parameter check can cause data integrity issues (bsc#1257108).
    - CVE-2025-15282: user-controlled data URLs parsed may allow injecting headers (bsc#1257046).
    - CVE-2025-15366: user-controlled command can allow additional commands injected using newlines     (bsc#1257044).
    - CVE-2025-15367: control characters may allow the injection of additional commands (bsc#1257041).
    - CVE-2026-0672: HTTP header injection via user-controlled cookie values and parameters when using     http.cookies.Morsel       (bsc#1257031).
    - CVE-2026-0865: user-controlled header containing newlines can allow injecting HTTP headers     (bsc#1257042).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:0693-1 advisory.

    - CVE-2025-11468: header injection when folding a long comment in an email header containing exclusively     unfoldable       characters (bsc#1257029).
    - CVE-2025-12781: inadequate parameter check can cause data integrity issues (bsc#1257108).
    - CVE-2025-15282: user-controlled data URLs parsed may allow injecting headers (bsc#1257046).
    - CVE-2025-15366: user-controlled command can allow additional commands injected using newlines     (bsc#1257044).
    - CVE-2025-15367: control characters may allow the injection of additional commands (bsc#1257041).
    - CVE-2026-0672: HTTP header injection via user-controlled cookie values and parameters when using     http.cookies.Morsel       (bsc#1257031).
    - CVE-2026-0865: user-controlled header containing newlines can allow injecting HTTP headers     (bsc#1257042).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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.
    (CVE-2025-12781)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
464172	Echo: python3.13: security update to 3.13.5-2+e10	Tenable Cloud Security	Echo Local Security Checks	Local	medium
464172	Echo: python3.13: security update to 3.13.5-2+e10	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
352967	AlmaLinux 9.2 [TuxCare] Security Update: python3.11 / python3.11-debug / python3.11-devel / python3.11-idle / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1773323311)	Nessus	Alma Linux Local Security Checks	Local	medium
352288	AlmaLinux 9.2 [TuxCare] Security Update: python-unversioned-command / python3 / python3-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1773136115)	Nessus	Alma Linux Local Security Checks	Local	medium
300978	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : python311 (SUSE-SU-2026:0767-1)	Nessus	SuSE Local Security Checks	Local	medium
300804	SUSE SLES15 Security Update : python311 (SUSE-SU-2026:0693-1)	Nessus	SuSE Local Security Checks	Local	medium
295336	Linux Distros Unpatched Vulnerability : CVE-2025-12781	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2025-12781

medium

Tenable Plugins

medium

medium

medium

medium

medium

medium

medium