CVE Vulnerability Catalog

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because the raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. When a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path, the public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens.

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because the asymmetric-key guard relies on textual markers that are absent from DER encoding. When an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT is_pem_format is affected because lazy PEM regular expression backtracks extensively. This occurs when a certificate-like input contains repeated BEGIN markers without a matching END marker. As a result, is_pem_format performs unbounded backtracking while searching for a PEM end marker.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments.

PyJWT is a Python implementation of JSON Web Token standards. Prior to version 2.14.0, is_pem_format in jwt/utils.py does not recognize every PEM representation accepted by the cryptography loader. When an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. An attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. When a configured trusted JWKS endpoint returns an attacker-influenced redirect, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because the PyJWK verification path used the decoded key without applying prepare_key validation. When a trusted JWK Set contains an oct entry with an empty k value, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, a forged token can carry arbitrary authenticated claims.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy.

In Wind River VxWorks 7 prior to 26.09, specific system call arguments can result in the process management subsystem failing to properly release allocated kernel memory before terminating the calling application. Fixed in Version 26.09.

In Wind River VxWorks 7 versions 24.03 through 26.03, a memory leak occurs under specific non-default configurations when processing certain service routines, causing the system to terminate operations before releasing allocated memory pools. Fixed in VxWorks 7 26.09.

PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure, potentially leading to HTTP 500 responses on unauthenticated requests. Fixed in version 2.15.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS, allowing attacker traffic to amplify outbound requests to the configured JWKS endpoint. Fixed in version 2.14.0.

@grpc/grpc-js implements the core functionality of gRPC purely in JavaScript, without a C++ addon. Prior to 1.13.6 and 1.14.5, getAuthContext does not distinguish authorized from unauthorized peer certificates when server credentials set requireClientCertificate to false. When applications use the returned authentication context, they can treat an unauthorized certificate as authorized, causing improper authentication. @grpc/grpc-js-xds can reach this condition when RBAC authentication is enabled in affected configurations.

A weakness in Ziroom ZHOME A0101 version 1.0.1.0 affects the function pop_usb_device in the file usr/lib/lua/luci/controller/api/zrUsb.lua of the USB Device Management API component. Manipulation of the argument path causes command injection. The attack can be performed remotely, and the exploit is publicly available.

A security flaw has been discovered in Eleveo Quality Management 9.7.0. The issue affects the function UtilsService.createAndSaveAudit of the file /qm/cz.zoom.scorecard.webui.Scorecard/QMUtilsService of the component GWT RPC Handler. Manipulation results in information disclosure. The attack can be carried out remotely. The exploit has been publicly released and may be used. The vendor was contacted but did not respond.

A vulnerability was identified in Eleveo Call Recording Software 9.7.0. It affects unknown code of the file /callrec/userAddAction.do of the component User Management. Manipulation of the argument Username leads to LDAP injection. The attack can be executed remotely. The exploit is publicly available and might be used. The vendor was contacted but did not respond.

A vulnerability was determined in Eleveo Call Recording Software 9.7.0. It affects an unknown part of the file /callrec/searchAction.do of the component Query Builder. This manipulation causes improper access controls. Remote exploitation is possible. The exploit has been publicly disclosed and may be utilized. The vendor was contacted but did not respond.

InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. In version 1.7.2, Users::form() performs no object-level authorization check on user_id = 1. A Secondary Administrator (user_type = 1, user_id != 1) can rewrite the Primary Administrator's user_type to 2 (Guest / read-only), destroying the root account's privilege and locking the legitimate owner out of the instance. At time of publication, there are no publicly available patches.

InvoicePlane, a self-hosted open source application for managing invoices, clients, and payments, in version 1.7.2 has a vulnerability allowing takeover of the primary administrator account. A previous fix (PR #1638) protected the direct password change but not the user_email attribute. A secondary administrator can edit the primary administrator's account and change their email address, then use the public password recovery flow to receive a reset token and take over user_id=1.

DOMSanitizer is a DOM/SVG/MathML Sanitizer for PHP 7.3+. Prior to version 1.0.15, the isDangerousUrl() method is responsible for rejecting dangerous URL values in the href and xlink:href attributes. The weakness is that "javascript:" is rejected as a scheme, while "data:" is rejected only when the literal substring onload appears in the URL value (/^data:.*onload/i). Because data: payloads are routinely Base64-encoded, the dangerous content is invisible to that substring test. A URL such as data:text/html;base64,… therefore survives in href / xlink:href, even though the decoded payload is active markup. This is an incomplete input-validation / sanitization defect. Patched in version 1.0.15.