Novel-Plus v3.6.2 was discovered to contain a hard-coded JWT key located in the project config file. This vulnerability allows attackers to create a custom user session.

Hardcoded JWT Secret in AgileConfig <1.6.8 Server allows remote attackers to use the generated JWT token to gain administrator access.

A use of hard-coded cryptographic key vulnerability [CWE-321] in FortiDDoS API 5.5.0 through 5.5.1, 5.4.0 through 5.4.2, 5.3.0 through 5.3.1, 5.2.0, 5.1.0 may allow an attacker who managed to retrieve the key from one device to sign JWT tokens for any device.

The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT signature with non Base64URL encoding special characters or number escaped characters may be validated as valid by mistake. Workaround: Validate JWS or JWT signature if it has Base64URL and dot safe string before executing JWS.verify() or JWS.verifyJWT() method.

PyJWT is a Python implementation of RFC 7519. PyJWT supports multiple different JWT signing algorithms. With JWT, an attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify `jwt.algorithms.get_default_algorithms()` to get support for all algorithms, or specify a single algorithm. The issue is not that big as `algorithms=jwt.algorithms.get_default_algorithms()` has to be used. Users should upgrade to v2.4.0 to receive a patch for this issue. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

In APache APISIX before 3.13.1, the jwt-auth plugin has a security issue that leaks the user's secret key because the error message returned from the dependency lua-resty-jwt contains sensitive information.

Gin-vue-admin is a backstage management system based on vue and gin, which separates the front and rear of the full stack. The problem occurs in the following code in server/service/system/sys_auto_code_pgsql.go, which means that PostgreSQL must be used as the database for this vulnerability to occur. Users must: Require JWT login） and be using PostgreSQL to be affected. This issue has been resolved in version 2.5.1. There are no known workarounds.

IBM Sterling Partner Engagement Manager 6.2.0 could allow an attacker to impersonate another user due to missing revocation mechanism for the JWT token. IBM X-Force ID: 219131.

IBM Security Verify Access could allow a user, using man in the middle techniques, to obtain sensitive information or possibly change some information due to improper validiation of JWT tokens.

Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions a crafted request crashes Envoy when a CONNECT request is sent to JWT filter configured with regex match. This provides a denial of service attack vector. The only workaround is to not use regex in the JWT filter. Users are advised to upgrade.

Fresenius Kabi Vigilant Software Suite (Mastermed Dashboard) version 2.0.1.3 issues authentication tokens to authenticated users that are signed with a symmetric encryption key. An attacker in possession of the key can issue valid JWTs and impersonate arbitrary users.

An attacker with physical access to the host can extract the secrets from the registry and create valid JWT tokens for the Fresenius Kabi Vigilant MasterMed version 2.0.1.3 application and impersonate arbitrary users. An attacker could manipulate RabbitMQ queues and messages by impersonating users.

QXIP SIPCAPTURE homer-app before 1.4.28 for HOMER 7.x has the same 167f0db2-f83e-4baa-9736-d56064a5b415 JWT secret key across different customers' installations.

A flaw was found with the JWT token. A self-signed JWT token could be injected into the update manager and bypass the authentication process, thus could escalate privileges. This affects StarWind SAN and NAS build 1578 and StarWind Command Center build 6864.

In Requarks wiki.js, versions 2.0.0-beta.147 to 2.5.255 are affected by Stored XSS vulnerability, where a low privileged (editor) user can upload a SVG file that contains malicious JavaScript while uploading assets in the page. That will send the JWT tokens to the attacker’s server and will lead to account takeover when accessed by the victim.

The Simple JWT Login WordPress plugin before 3.3.0 can be used to create new WordPress user accounts with a randomly generated password. The password is generated using the str_shuffle PHP function that "does not generate cryptographically secure values, and should not be used for cryptographic purposes" according to PHP's documentation.

Dalmark Systems Systeam 2.22.8 build 1724 is vulnerable to Incorrect Access Control. The Systeam application is an ERP system that uses a mixed architecture based on SaaS tenant and user management, and on-premise database and web application counterparts. A broken access control vulnerability has been found while using a temporary generated token in order to consume api resources. The vulnerability allows an unauthenticated attacker to use an api endpoint to generate a temporary JWT token that is designed to reference the correct tenant prior to authentication, to request system configuration parameters using direct api requests. The correct exploitation of this vulnerability causes sensitive information exposure. In case the tenant has an smtp credential set, the full credential information is disclosed.

The Simple JWT Login WordPress plugin before 3.2.1 does not have nonce checks when saving its settings, allowing attackers to make a logged in admin changed them. Settings such as HMAC verification secret, account registering and default user roles can be updated, which could result in site takeover.

A flaw was found in Apache ShenYu Admin. The incorrect use of JWT in ShenyuAdminBootstrap allows an attacker to bypass authentication. This issue affected Apache ShenYu 2.3.0 and 2.4.0

Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header "X-Endpoint-API-UserInfo", the application can use it to do authorization. But if there are two "X-Endpoint-API-UserInfo" headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two "X-Endpoint-API-UserInfo" headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the "X-Endpoint-API-UserInfo" header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag ":1", needs to re-start the container to pick up the new version. The tag ":1" will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. ":1.57". You need to update it to ":1.58" and re-start the container. There are no workaround for this issue.