Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data["alg"] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.
CVE-2026-9779 is a high-severity vulnerability in ATEN Unizon version 2.6.253.001 involving improper verification of cryptographic signatures in the updateWar method. This flaw allows authenticated remote attackers to execute arbitrary code with SYSTEM privileges. The vulnerability stems from incorrect implementation of signature verification, enabling code execution in a highly privileged context.
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, Rocket.Chat's SAML service provider implementation silently skips both SAML Response and Assertion signature validation when the configured IdP certificate field is empty. The verifySignatures routine performs an early return when serviceProviderOptions.cert is falsy, which is the default state of the setting. Because provider registration only gates on the SAML "enabled" toggle and not on the presence of a certificate, an administrator who enables SAML without pasting an IdP certificate obtains a fully wired, publicly reachable SAML login endpoint that accepts unsigned or attacker-supplied assertions. This is a default-configuration authentication-bypass class: the fail-open branch is reached with no misconfiguration beyond leaving a field at its shipped default. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.
Relyra is a strict-by-default SAML 2.0 Service Provider library for Elixir and Phoenix. Versions 1.0.0 and 1.1.0 accept forged SAML signatures because SignatureValue was not cryptographically verified before the library returned a successful authentication result. The XMLDSig trust boundary was incomplete as :public_key.verify over the exclusive-C14N canonicalized SignedInfo was not performed against the configured IdP certificate's public key, DigestValue was not recomputed over the canonicalized referenced element, and canonicalize/2 remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes. A forged SignatureValue carrying an attacker-controlled NameID could be accepted as {:ok}. This issue has been fixed in version 1.2.0.
CVE-2026-50634 is a medium severity vulnerability in Apache CXF affecting the JwsJsonContainerRequestFilter component. It allows processing of metadata that was not authenticated by the accepted cryptographic signature, potentially bypassing the application's trust assumptions about signed HTTP headers or content types. This could affect downstream entity parsing or signed-header consistency checks. Fixed versions include Apache CXF 4.2.2, 4.1.7, and 3.6.12.
Cloud Foundry UAA incorrectly treated XML encryption to the Service Provider (confidentiality) as a substitute for XML signatures from the Identity Provider (authenticity) in two SAML flows: the OAuth 2.0 SAML2 bearer grant (token endpoint) and browser SSO (ACS) when wantAssertionSigned is set to false. Assertions or responses that were unsigned but contained encrypted content could still be accepted. Encryption uses the SP's public key from published metadata, therefore, any party, not only a trusted IdP, can produce ciphertext UAA can decrypt; successful decryption therefore does not prove the IdP issued the message.
Affected versions:
Cloud Foundry UAA (uaa_release) 2.0.0 through 78.13.0.
Cloud Foundry CF Deployment all versions through 56.1.0.
The UpdraftPlus: WP Backup & Migration Plugin plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.26.4 via the UpdraftPlus_Remote_Communications_V2::wp_loaded function. This is due to insufficient validation of the remote communications message format, where signature verification can be bypassed and unchecked decryption return values collapse to a predictable all-zero encryption key. This makes it possible for unauthenticated attackers to forge arbitrary RPC commands and run them as the connected administrator, such as uploading and activating a malicious plugin, which ultimately leads to remote code execution.
Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Prior to versions 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3, an attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received. Versions 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3 fix the issue.
Since Spring Security SAML decrypts SAML Responses as well as elements of SAML LogoutRequests and LogoutResponses without requiring a valid signature, attackers may be able to craft these SAML payloads and use the Service Provider as a decryption oracle.
Affected versions:
Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.
CVE-2026-8863 is a vulnerability in OracleLinux(7.2) shim version 0.9 involving improper verification of cryptographic signatures. This flaw allows an attacker with administrative privileges or the ability to modify the boot process to bypass Secure Boot protections by exploiting Microsoft-signed UEFI SHIM bootloaders. Successful exploitation could enable arbitrary code execution before the operating system loads. No official patch or remediation guidance is currently provided, but a specific UEFI DBX update is required to block the vulnerable boot loaders.
CVE-2026-44748 is a critical vulnerability in SAP NetWeaver AS ABAP and ABAP Platform involving improper verification of cryptographic signatures. An authenticated attacker with normal privileges can obtain a valid signed message and send modified signed XML documents to the verifier. This flaw may cause the system to accept tampered identity information, potentially leading to unauthorized access to sensitive user data and disruption of normal system operations. The vulnerability impacts confidentiality, integrity, and availability of the affected application.
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Prior to version 4.11.0, on many of the ECDH shared secret paths, the public key isn't verified to be a point on the correct curve. By passing approximately 30-40 crafted public keys to OP-TEE, the private key can be reconstructed by a normal world attacker. When calling TEE_DeriveKey the public key is provided with full X and Y values, but the (X, Y) point might not satisfy the `Y^2 == X^3 + aX + b mod P` math for the specific curve that is used. When those public keys aren't rejected, the attacker can select public keys such that each DeriveKey call will leak `d % r` where `d` is the private key and `r` comes from the relationship between the correct curve and the attacker selected curve. With enough leaked data the Chinese remainder theorem can be used to recover the full private key. Version 4.11.0 fixes the issue.
CVE-2026-6873 is a low-severity vulnerability in Django versions 6.0 and 5.2 where the get_signed_cookie function uses a non-injective salt derivation method. This flaw allows an attacker to reuse a signed cookie in a different context by exploiting distinct (name, salt) pairs that produce the same concatenation. The issue affects Django 6.0 before 6.0.6 and 5.2 before 5.2.15, with earlier unsupported versions possibly also affected. No official patch or remediation level has been confirmed yet.
> [!NOTE]
> Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.
PyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.
### Summary
PyJWT's `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.
In affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller's `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.
This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header advertises an allowed algorithm. This affects the documented `PyJWKClient` usage flow and does not require any non-default flags or unsafe configuration.
### Details
In `jwt/api_jws.py` in `2.12.1`, `_verify_signature()` treats `PyJWK` keys differently from normal PEM/public-key inputs:
```python
if algorithms is None and isinstance(key, PyJWK):
algorithms = [key.algorithm_name]
...
if not alg or (algorithms is not None and alg not in algorithms):
raise InvalidAlgorithmError("The specified alg value is not allowed")
if isinstance(key, PyJWK):
alg_obj = key.Algorithm
prepared_key = key.key
else:
alg_obj = self.get_algorithm_by_name(alg)
prepared_key = alg_obj.prepare_key(key)
```
This logic means:
1. The JWT header `alg` is checked only as a string against the caller-supplied allow-list.
2. If the key is a `PyJWK`, the actual verifier is not selected from the header algorithm.
3. Instead, PyJWT always verifies with `key.Algorithm`, which is fixed when the `PyJWK` object is created.
`PyJWK` binds its algorithm in `jwt/api_jwk.py` from the JWK's `alg` field or from key-type defaults:
```python
if not algorithm and isinstance(self._jwk_data, dict):
algorithm = self._jwk_data.get("alg", None)
...
self.algorithm_name = algorithm
self.Algorithm = get_default_algorithms()[algorithm]
self.key = self.Algorithm.from_jwk(self._jwk_data)
```
So once a `PyJWK` is constructed, the verifier uses the `PyJWK`'s bound algorithm, not the JWT header algorithm.
The issue is reachable through the documented JWKS flow. In `docs/usage.rst`, the project documents:
```python
signing_key = jwks_client.get_signing_key_from_jwt(token)
jwt.decode(
token,
signing_key,
audience="https://expenses-api",
options={"verify_exp": False},
algorithms=["RS256"],
)
```
`PyJWKClient.get_signing_key_from_jwt()` returns a `PyJWK`, so this documented path is affected.
This is not a "no-key forgery" issue. The attacker still needs control of an accepted JWK/JWKS private key. However, that is realistic in deployments such as:
- self-service OAuth client assertions
- multi-tenant key registration
- federation / BYO-JWKS trust models
- any system where external parties sign JWTs with their own registered keys
In those cases, the attacker can bypass verifier-side algorithm policy. For example, if the server intends to only accept `PS256`, an attacker controlling an accepted RSA JWK can sign with `RS256`, set `alg=PS256` in the JWT header, and still be accepted through the `PyJWK` path.
The same forged token is rejected through the normal PEM/public-key verification path, which shows the bug is specific to `PyJWK` verification rather than expected JWT behavior.
This behavior was introduced by commit `ab8176abe21e550dbc1c9a6bb7e78ad80853bfb1` (`Decode with PyJWK (#886)`), which is present in tagged releases `2.9.0`, `2.10.0`, `2.10.1`, `2.11.0`, `2.12.0`, and `2.12.1`.
### PoC
Tested locally against PyJWT `2.12.1` on Python `3.12.10` with `cryptography 45.0.6`.
Install dependencies:
```bash
python -m pip install pyjwt==2.12.1 cryptography
```
Run the following script:
```python
import json
import jwt
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
from jwt.api_jwk import PyJWK
from jwt.algorithms import RSAAlgorithm
from jwt.utils import base64url_encode
# Generate an RSA keypair controlled by the attacker.
priv = rsa.generate_p
PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.
A flaw was found in Keycloak. When a JSON Web Encryption (JWE) encrypted request object is submitted, Keycloak may incorrectly process unsigned claims if the decrypted content is raw JSON, bypassing the configured signature policy. This allows a remote attacker to submit unauthorized claims, leading to a compromise of data integrity within the OpenID Connect (OIDC) authorization flow. While a redirect URI allowlist acts as a compensating control, this vulnerability violates OIDC Core and Financial-grade API (FAPI) signing requirements.
OpenLearnX is an open-source, decentralized learning and assessment platform. Prior to 2.0.4, a critical authentication vulnerability was identified in OpenLearnX that could allow unauthorized access to user accounts under specific conditions. This vulnerability is fixed in 2.0.4.
The Web-based Management allows a remote low privileged Engineer user to install additional APPs on the device downloaded from the PLCnext Store without implementing any data verification mechanism, leading to the capability for an Engineer user to reach arbitrary code execution with root privileges on the PLC device. A successful exploitation may allow to install a manipulated APP package, potentially impacting integrity and availability of the PLCnext Control.