CVE-2026-3446: 
Python Interpreter vulnerability analysis and mitigation

CVE-2026-3446 is a base64 decoding flaw in CPython's base64.b64decode() and related functions (including binascii.a2b_base64()) where the decoding process prematurely stops after encountering the first padded quad, silently ignoring any subsequent data. This divergent behavior from RFC 4648 can cause data to be accepted and interpreted differently than by other standard base64 implementations. The vulnerability affects CPython versions prior to 3.13.13, 3.14.0 through 3.14.3, and 3.15.0a1 through 3.15.0a7. It was disclosed on April 10, 2026, and carries a CVSS v4.0 base score of 6.0 (Medium) (GitHub Advisory, ENISA EUVD).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity). In the binascii_a2b_base64_impl() C function within Modules/binascii.c, the decoder used a padding_started flag and a goto done statement that caused parsing to halt immediately upon completing the first padded quad, discarding all remaining input without error in non-strict (default) mode. This violates RFC 4648, Section 3.3, which permits implementations to ignore the pad character = only when present before the end of encoded data — not to stop processing entirely. As a result, crafted inputs like b'ab==cd' would decode to b'i' (only the first segment) instead of the full b'i\xb7\x1d', enabling an attacker to craft base64 strings that decode to different values depending on which implementation processes them (CPython Issue #145264, CPython PR #145267).

The primary impact is on data integrity: applications relying on CPython's base64 decoding for security-sensitive operations — such as validating cryptographic signatures, processing authentication tokens, or parsing encoded configuration data — may accept maliciously crafted inputs that would be rejected or decoded differently by other compliant implementations. This divergent parsing behavior could allow a low-privileged network attacker to bypass validation checks, smuggle hidden data past security controls, or cause applications to misinterpret encoded payloads. Confidentiality and availability are not directly impacted, but integrity of decoded data is at high risk in affected deployments (ENISA EUVD, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (ENISA EUVD). The vulnerability requires an attacker to have low privileges and network access, and exploitation depends on the presence of specific attack conditions (e.g., an application that uses Python's base64 decoding for security validation and also interoperates with other implementations). The EPSS score is approximately 0.05%, reflecting low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Identify a target application: Find a Python application (running CPython < 3.13.13, < 3.14.4, or < 3.15.0a8) that decodes base64-encoded data from user-supplied input using base64.b64decode() or binascii.a2b_base64() without validate=True, and uses the decoded result for a security-sensitive operation (e.g., signature verification, token validation).
2. Craft a malicious base64 payload: Construct a base64 string where the first padded quad decodes to a value that passes the application's validation, followed by additional base64 data that encodes the actual malicious payload. For example: b'ab==cd' — the vulnerable CPython decoder returns only b'i' (from the first quad), while a compliant decoder returns b'i\xb7\x1d'.
3. Submit the crafted input: Send the crafted base64 string to the target application via the relevant input vector (e.g., HTTP request parameter, API field, file upload).
4. Exploit divergent decoding: The Python application decodes only the first segment and processes it as if it were the complete data, potentially bypassing a signature check or validation that a compliant decoder would have caught. If the application forwards the raw (undecoded) base64 string to another system using a different decoder, that system may process the full payload including the hidden trailing data (CPython Issue #145264, CPython PR #145267).

Upgrade to patched CPython versions: 3.13.13 or later, 3.14.4 or later, or 3.15.0a8 or later, which fix the premature termination behavior in binascii.a2b_base64() and base64.b64decode() to conform with RFC 4648 (GitHub Advisory, CPython PR #145267). As an immediate workaround for applications that cannot be patched, pass validate=True to base64.b64decode() calls to enable stricter processing that raises an error on excess data after padding. Audit all application code that decodes base64 data from untrusted sources — particularly where the decoded output is used for authentication, signature verification, or security-critical logic — and consider adding explicit length or content validation after decoding (ENISA EUVD).

The fix was developed by CPython core developer Serhiy Storchaka and reviewed by Gregory P. Smith (gpshead), with the patch merged into main on March 22, 2026, and backported to the 3.13 and 3.14 branches shortly after (CPython PR #145267). The Python Software Foundation issued a security announcement via the security-announce@python.org mailing list, and the issue was also discussed on the oss-security mailing list (oss-sec). Downstream distributions including SUSE/openSUSE and Red Hat have issued security advisories and updated packages (openSUSE Advisory, Red Hat Advisory). A Django project ticket (code.djangoproject.com/ticket/37053) was also filed in relation to this issue, indicating downstream ecosystem awareness.