CVE-2025-12781
base64.b64decode() always accepts "+/" characters, despite setting altchars
Public exploit available. Not confirmed exploited in the wild yet. A vendor fix is available.
What to do
The vendor has published a fix. Version details are below where the sources state them.
What it is
From the CVE record
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.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
1 source with a proof of concept or module.
Exploit links, PoCs and Metasploit modules after sign-in- EPSS
0.6% chance of exploitation activity in the next 30 days, which ranks it in the 45th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
The patch came 32 days before any public exploit.
- OpenVAS check added
- Public exploit / PoCsource: github-poc
- Patch availablerecord updated
- Publishedweakness classified
Affected products
Technical detail
CVSS 3.1 vector
Open in the CVSS calculatorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Scored 5.3 by NVD.
How it is reached
- Attack Vector NetworkExploitable remotely over the network without any special conditions
- Attack Complexity LowNo special conditions — the attack can be reliably reproduced
- Privileges Required NoneNo authentication required — anyone can exploit this
- User Interaction NoneNo user interaction needed — fully automated exploitation
Scope
- Scope UnchangedImpact is limited to the vulnerable component itself
Impact if exploited
- Confidentiality NoneNo confidentiality impact
- Integrity LowData modification is possible but limited in scope or consequence
- Availability NoneNo availability impact
Weaknesses
Sources
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Red Hat Enterprise Linux, not every advisory. This one: public exploit.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI