EUVD-2026-50450Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/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
AC:H captures the non-default deny-list architecture required; PR:L reflects that a valid token must already be held; only integrity bypass applies with no confidentiality or availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. in versions 1.7.1 and prior, joserfc accepts JWTs with trailing padding (==) which are not conforming to the JOSE specifications. This leads to malleability of the JWTs when consumed by joserfc. Depending on this application this might or not be an issue. This could lead to bypass of token revocation or anti-replay protection when implemented as a deny list of tokens or a deny list of token hashes. Note that ECDSA JWS are always malleable because of the malleability of ECDSA signatures (first test case in the code bellow). This makes a scheme which assumes that JWTs are not malleable brittle. However for other signatures (or MAC) schemes it might make sense to assume non malleability of the token. This issue has been fixed in version 1.7.2.
AnalysisAI
JWT malleability in joserfc versions 1.7.1 and prior allows a low-privileged user holding a valid token to craft alternate byte-distinct representations by exploiting the library's acceptance of non-conforming trailing Base64 padding (==), which violates the JOSE specification. Applications using deny-list-based token revocation or anti-replay protection are at risk of bypass, since a padding-modified token hashes to a different value that will not match the stored revoked-token record. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the vendor-released fix is joserfc 1.7.2.
Technical ContextAI
joserfc (CPE: cpe:2.3:a:authlib:joserfc:*:*:*:*:*:*:*:*) is a Python library implementing JOSE standards - JWS, JWT, JWE, and related specifications - published under the authlib organization on PyPI. The JOSE/JWT specification (RFC 7515, RFC 7519) mandates that Base64url-encoded values MUST omit padding characters (=). By accepting JWTs that include trailing == padding, joserfc violates this canonicalization requirement, producing token malleability: the same logical credential can be encoded in multiple byte-distinct forms, all of which the library considers valid. CWE-345 (Insufficient Verification of Data Authenticity) classifies the root cause - the library does not enforce the canonical encoding form required by the standard before verifying or consuming the token. The advisory further notes that ECDSA-signed JWTs are inherently malleable due to the nature of ECDSA signatures regardless of this bug; the padding malleability is most dangerous for HMAC- and RSA-signed tokens, where non-malleability is otherwise a reasonable security assumption that applications may legitimately rely upon.
RemediationAI
Upgrade joserfc to version 1.7.2, which resolves this issue by rejecting JWTs containing non-conforming trailing Base64 padding, as confirmed by the vendor advisory at https://github.com/authlib/joserfc/security/advisories/GHSA-5jhw-7jv7-qcqq. For deployments unable to upgrade immediately, a compensating control is to normalize JWT strings before computing deny-list lookups: strip any trailing = padding characters from all Base64url-encoded segments before hashing or comparing tokens against the revocation store. This control must be applied consistently at every JWT comparison point in the application - a single unguarded code path is sufficient to reintroduce the bypass. Note that this workaround does not address the inherent ECDSA malleability cited in the advisory; applications relying on ECDSA-signed token non-malleability require architectural changes beyond this fix.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today