{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2025-12781", "assignerOrgId": "28c92f92-d60d-412d-b760-e73465c3df22", "state": "PUBLISHED", "assignerShortName": "PSF", "dateReserved": "2025-11-05T22:04:54.230Z", "datePublished": "2026-01-21T19:34:47.979Z", "dateUpdated": "2026-01-22T20:12:56.421Z"}, "containers": {"cna": {"affected": [{"defaultStatus": "unaffected", "modules": ["base64"], "product": "CPython", "repo": "https://github.com/python/cpython", "vendor": "Python Software Foundation", "versions": [{"version": "0", "lessThan": "3.13.10", "status": "affected", "versionType": "python"}, {"version": "3.14.0", "lessThan": "3.14.1", "status": "affected", "versionType": "python"}, {"version": "3.15.0a1", "lessThan": "3.15.0a2", "status": "affected", "versionType": "python"}]}], "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.&nbsp;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.</div>"}], "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.\u00a0Users 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."}], "metrics": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "baseScore": 6.3, "baseSeverity": "MEDIUM", "exploitMaturity": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "LOW", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "providerMetadata": {"orgId": "28c92f92-d60d-412d-b760-e73465c3df22", "shortName": "PSF", "dateUpdated": "2026-01-22T20:12:56.421Z"}, "references": [{"tags": ["patch"], "url": "https://github.com/python/cpython/pull/141128"}, {"tags": ["issue-tracking"], "url": "https://github.com/python/cpython/issues/125346"}, {"tags": ["vendor-advisory"], "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/"}, {"tags": ["patch"], "url": "https://github.com/python/cpython/commit/13360efd385d1a7d0659beba03787ea3d063ef9b"}, {"tags": ["patch"], "url": "https://github.com/python/cpython/commit/1be80bec7960f5ccd059e75f3dfbd45fca302947"}, {"tags": ["patch"], "url": "https://github.com/python/cpython/commit/9060b4abbe475591b6230b23c2afefeff26fcca5"}, {"tags": ["patch"], "url": "https://github.com/python/cpython/commit/e95e783dff443b68e8179fdb57737025bf02ba76"}, {"tags": ["patch"], "url": "https://github.com/python/cpython/commit/fd17ee026fa9b67f6288cbafe374a3e479fe03a5"}], "source": {"discovery": "UNKNOWN"}, "title": "base64.b64decode() always accepts \"+/\" characters, despite setting altchars", "x_generator": {"engine": "Vulnogram 0.5.0"}}, "adp": [{"problemTypes": [{"descriptions": [{"type": "CWE", "cweId": "CWE-704", "lang": "en", "description": "CWE-704 Incorrect Type Conversion or Cast"}]}], "metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-01-22T14:53:47.177224Z", "id": "CVE-2025-12781", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-01-22T14:53:50.663Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2025-12781", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-01-22T14:53:47.177224Z"}}}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-704", "description": "CWE-704 Incorrect Type Conversion or Cast"}]}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-01-22T14:53:14.185Z"}}], "cna": {"title": "base64.b64decode() always accepts \"+/\" characters, despite setting altchars", "source": {"discovery": "UNKNOWN"}, "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 6.3, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "valueDensity": "NOT_DEFINED", "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "LOW", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"repo": "https://github.com/python/cpython", "vendor": "Python Software Foundation", "modules": ["base64"], "product": "CPython", "versions": [{"status": "affected", "version": "0", "lessThan": "3.13.10", "versionType": "python"}, {"status": "affected", "version": "3.14.0", "lessThan": "3.14.1", "versionType": "python"}, {"status": "affected", "version": "3.15.0a1", "lessThan": "3.15.0a2", "versionType": "python"}], "defaultStatus": "unaffected"}], "references": [{"url": "https://github.com/python/cpython/pull/141128", "tags": ["patch"]}, {"url": "https://github.com/python/cpython/issues/125346", "tags": ["issue-tracking"]}, {"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/", "tags": ["vendor-advisory"]}, {"url": "https://github.com/python/cpython/commit/13360efd385d1a7d0659beba03787ea3d063ef9b", "tags": ["patch"]}, {"url": "https://github.com/python/cpython/commit/1be80bec7960f5ccd059e75f3dfbd45fca302947", "tags": ["patch"]}, {"url": "https://github.com/python/cpython/commit/9060b4abbe475591b6230b23c2afefeff26fcca5", "tags": ["patch"]}, {"url": "https://github.com/python/cpython/commit/e95e783dff443b68e8179fdb57737025bf02ba76", "tags": ["patch"]}, {"url": "https://github.com/python/cpython/commit/fd17ee026fa9b67f6288cbafe374a3e479fe03a5", "tags": ["patch"]}], "x_generator": {"engine": "Vulnogram 0.5.0"}, "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.\u00a0Users 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.", "supportingMedia": [{"type": "text/html", "value": "<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.&nbsp;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.</div>", "base64": false}]}], "providerMetadata": {"orgId": "28c92f92-d60d-412d-b760-e73465c3df22", "shortName": "PSF", "dateUpdated": "2026-01-22T20:12:56.421Z"}}}, "cveMetadata": {"cveId": "CVE-2025-12781", "state": "PUBLISHED", "dateUpdated": "2026-01-22T20:12:56.421Z", "dateReserved": "2025-11-05T22:04:54.230Z", "assignerOrgId": "28c92f92-d60d-412d-b760-e73465c3df22", "datePublished": "2026-01-21T19:34:47.979Z", "assignerShortName": "PSF"}, "dataVersion": "5.2"}

{"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.\u00a0Users 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."}], "id": "CVE-2025-12781", "lastModified": "2026-01-22T21:15:49.257", "metrics": {"cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 6.3, "baseSeverity": "MEDIUM", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "LOW", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "cna@python.org", "type": "Secondary"}]}, "published": "2026-01-21T20:16:04.423", "references": [{"source": "cna@python.org", "url": "https://github.com/python/cpython/commit/13360efd385d1a7d0659beba03787ea3d063ef9b"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/commit/1be80bec7960f5ccd059e75f3dfbd45fca302947"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/commit/9060b4abbe475591b6230b23c2afefeff26fcca5"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/commit/e95e783dff443b68e8179fdb57737025bf02ba76"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/commit/fd17ee026fa9b67f6288cbafe374a3e479fe03a5"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/issues/125346"}, {"source": "cna@python.org", "url": "https://github.com/python/cpython/pull/141128"}, {"source": "cna@python.org", "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/"}], "sourceIdentifier": "cna@python.org", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-704"}], "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}]}

{"bugzilla": {"description": "cpython: base64.b64decode() always accepts \"+/\" characters, despite setting altchars", "id": "2431736", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2431736"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.3", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N", "status": "draft"}, "cwe": "CWE-20", "details": ["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.\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.\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.\u00a0Users 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.", "A flaw was found in the base64 module in the Python standard library. The b64decode, standard_b64decode and urlsafe_b64decode functions will always accept the '+' and '/' characters even when an alternative base64 alphabet is specified via the altchars parameter that excludes them. This input validation bypass allows malformed or unexpected data to pass through decoding filters, potentially causing logical errors or data integrity issues in applications relying on strict character sets."], "mitigation": {"lang": "en:us", "value": "To mitigate this issue, implement manual input validation before calling the base64 functions with an alternative alphabet, ensuring to reject any string containing the standard base64 characters, such as '+' and '/', that are not part of the expected alphabet."}, "name": "CVE-2025-12781", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "firefox", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "python3.12", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "python3.14", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Fix deferred", "package_name": "python", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Fix deferred", "package_name": "firefox", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Fix deferred", "package_name": "python", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Fix deferred", "package_name": "python3", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "firefox", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "python3", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "python3.11", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "python3.12", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "python36:3.6/python36", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "python39-devel:3.9/python39", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "firefox", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "python3.11", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "python3.12", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "python3.14", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "python3.9", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "rhelai3/bootc-aws-cuda-rhel9", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "rhelai3/bootc-azure-cuda-rhel9", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "rhelai3/bootc-cuda-rhel9", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "rhelai3/bootc-gcp-cuda-rhel9", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-codeserver-datascience-cpu-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_devspaces:3", "fix_state": "Fix deferred", "package_name": "devspaces/code-rhel9", "product_name": "Red Hat OpenShift Dev Spaces"}, {"cpe": "cpe:/a:redhat:openshift_devspaces:3", "fix_state": "Fix deferred", "package_name": "devspaces/pluginregistry-rhel9", "product_name": "Red Hat OpenShift Dev Spaces"}, {"cpe": "cpe:/a:redhat:openshift_devspaces:3", "fix_state": "Fix deferred", "package_name": "devspaces-tech-preview/idea-rhel9", "product_name": "Red Hat OpenShift Dev Spaces"}], "public_date": "2026-01-21T19:34:47Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2025-12781\nhttps://nvd.nist.gov/vuln/detail/CVE-2025-12781\nhttps://github.com/python/cpython/issues/125346\nhttps://github.com/python/cpython/pull/141128\nhttps://mail.python.org/archives/list/security-announce@python.org/thread/KRI7GC6S27YV5NJ4FPDALS2WI5ENAFJ6/"], "statement": "This issue can only be exploited by Python applications that use the base64 functions to validate if a string is safe for a URL or filename without additional input validation. Additionally, this flaw affects only the base64 functions when an alternative alphabet is specified via the altchars parameter, limiting its exposure. This issue can cause logical errors and integrity issues but it does not allow direct access to system data or critical files, as the exploitation depends on how the application processes the decoded data. Due to these reasons, this vulnerability has been rated with a moderate severity.", "threat_severity": "Moderate"}